MCP di osservabilità Cloudflare: dimostra un risultato di zero log

Una risposta vuota dal server MCP Cloudflare Observability non è prova che un lavoratore sia in buona salute. È la prova che una domanda non ha risposto a righe. Prima di trasformarlo in un verdetto, dimostrare che la query ha utilizzato l'account Cloudflare previsto, Worker, finestra temporale, configurazione del registro e set di campi e che lo stesso ambito può recuperare una chiamata di controllo nota. Il default ragionevole è rigoroso: chiamare un risultato di riga zero filtrato healthy empty solo quando sono abilitati i registri dei lavoratori e i registri di invocazione, il tasso di campionamento di testa è 1 , la finestra è all'interno della conservazione, la scoperta del campo riesce, la query viene completata e una query più ampia trova una invocazione nota nello stesso account, Worker e finestra. Se manca una ricevuta, mantenere sconosciuto lo stato o indirizzare il fallimento di configurazione specifico. Ciò è importante perché lo scambio remoto di MCP può avere successo mentre lo strato di prova è incompleto. Il risultato del protocollo risponde ha restituito lo strumento? L'operatore deve ancora rispondere ha questa query coprire gli eventi necessari per questa decisione? Una richiesta di MCP di successo può comunque essere un fallimento delle prove Cloudflare elenca un server di osservabilità gestito per il debugging dei registri delle applicazioni e delle analisi. L'attuale Catalogo dei server MCP di Cloudflare fornisce il suo endpoint remoto, dice che le nuove connessioni utilizzano Streamable HTTP e spiega che l'autorizzazione viene gestita attraverso Cloudflare OAuth. La Repositorio MCP di osservabilità dei lavoratori documenta tre strumenti: query worker observability consultazioni Registri dei lavoratori e metriche; observability keys scopre metadati, campi specifici per il lavoratore e campi personalizzati; observability values trova i valori disponibili per un campo selezionato. Tali strumenti sono sufficienti per indagare su molti incidenti, ma i loro buoni risultati non dimostrano copertura. Il repository dice anche che ogni richiesta ottiene una nuova autorizzazione e un contesto di account. Pertanto, non si supponga che, poiché la richiesta precedente ha utilizzato il conto giusto, la richiesta successiva lo abbia necessariamente fatto. Registrare un riferimento non segreto di conto e un riferimento del lavoratore con ogni ricevuta di richiesta. Esistono diversi modi per ottenere un risultato convincente: 1. OAuth completato, ma il conto selezionato non è il conto di produzione. 2. Il filtro del nome del lavoratore o dell'ambiente non si risolve a nulla. 3. I registri dei lavoratori sono disabilitati per tale distribuzione. 4. I registri delle richieste sono esplicitamente disabilitati. 5. Il campionamento della testa ha omesso l'invocazione che si aspettava di trovare. 6. La finestra richiesta è più antica dei dati conservati. 7. Il filtro utilizza un campo o un valore assente dallo schema corrente. 8. Il risultato filtrato è veramente vuoto. Solo l'ultimo stato sostiene nessun incidente corrispondente, e anche allora solo per il campo di applicazione e la finestra limitata. La collasso dell'elenco in success elimina le prove esatte di cui un operatore ha bisogno. Prova il set di dati prima di interpretare il filtro Inizia dalla raccolta, non dalla ricerca dell'incidente. L'attuale Documentazione dei registri dei lavoratori di Cloudflare dice che un lavoratore deve avere l'osservabilità abilitata per scrivere ai registri dei lavoratori. Essa documenta anche un'impostazione invocation logs = false separata. Un lavoratore può quindi eseguire con successo se la prova di invocazione che si aspetta dall'audit è deliberatamente assente. Il campionamento è un altro limite difficile. head sampling rate varia da 0 a 1 ; a 0.01 , solo una su cento richieste viene registrata. Una query di errore di riga zero sui dati campionati può essere utile per la stima della tendenza, ma non può eliminare deterministicamente una richiesta nota. La stessa documentazione indica che il servizio può applicare un campione dell'1% dopo che un conto supera il suo limite giornaliero di registrazione. Registrare la politica di campionamento efficace, non solo la configurazione prevista. La conservazione rende una vecchia finestra inconoscibile. Il massimo documentato è di tre giorni su Workers Free e di sette giorni su Workers Paid. Se una finestra di incidente si è conclusa prima del limite di ritenzione, classificarla come window expired . L'espansione o la riformulazione della query non può recuperare i dati che non sono più memorizzati. Utilizzare questo ordine per ogni indagine: 1. Pin scope. catturare riferimenti opaci e non segreti per il conto autorizzato, il lavoratore e l'ambiente. Non memorizzare un token OAuth, richiedere l'URL, il corpo del registro o l'identificatore del cliente nella ricevuta di salute. 2. Check collection. Confirm Workers Logs è abilitato per l'ambiente distribuito e se sono abilitati i log di invocazione. 3. Ricordare i limiti di copertura. Ricordare il tasso effettivo di campionamento della testa, i giorni di conservazione e i timestamp di inizio/fine richiesti. 4. Discover prima di filtrare. Utilizzare observability keys per confermare l'esistenza dei campi richiesti, quindi observability values per confermare la presenza del valore Worker o ambiente. Ciò impedisce che un campo errato o obsoleto sembri un risultato pulito. 5. Run una query di controllo. Query abbastanza ampio da trovare una invocazione nota emessa all'interno dello stesso account, Worker e finestra. Utilizzare un marcatore di richiesta hashato tenuto localmente se avete bisogno di correlazione; mai caricare il marcatore grezzo in un registro di monitoraggio. 6. Run il filtro incidente. Solo dopo l'apparizione del controllo un filtro di errore a fila zero dovrebbe essere considerato candidato a healthy empty . Una ricevuta compatta può preservare la decisione senza preservare il contenuto del registro: Il conto e i riferimenti del lavoratore sono chiavi di correlazione, non identificatori segreti. La ricevuta esclude deliberatamente le richieste, i messaggi di registro, le intestazioni, gli URL delle richieste, gli argomenti degli strumenti e il materiale OAuth. La rotta 9 dice invece di rendere un risultato verde L'artefatto che accompagna questo articolo riporta nove casi privi di contenuti. La sua regola di priorità è intenzionalmente conservatrice: Stato Le prove Azione dell'operatore needs auth Il server remoto non è autorizzato Via verso il titolare del conto; non etichettare il lavoratore non raggiungibile scope unresolved Manca un conto o un riferimento al lavoratore Risolvere l'account esatto, la distribuzione e l'ambiente collection disabled Il registro dei lavoratori o dei registri delle invocazioni è disattivato Decidere se consentire la raccolta e il riimpiego window expired La finestra precede i dati conservati Segna il verdetto storico non disponibile query failed Scoperta di schema, timestamp o esecuzione di query è invalida Ripara la query prima di interpretare il numero di righe sampled unknown Fonte zero con campionamento della testa inferiore a 1 Trattare l'assenza come non deterministica coverage unknown Le righe zero e l' invocazione di controllo conosciuta mancano Investigare la portata, il filtro, l'ingestione o il ritardo di raccolta incident found La query filtrata restituisce una o più righe corrispondenti Investigare le prove restituite healthy empty Righe filtrate zero più copertura completa e un controllo trovato Sbarazzare solo questo filtro, campo di applicazione e finestra temporale Il classificatore verifica le condizioni preliminari prima di esaminare filteredRows . Questo ordine impedisce il più comune falso verde: vedere lo zero e fermarsi prima di chiedere se c'era un set di dati valido da cercare. Eseguire il dispositivo localmente: Le nove apparecchiature hanno prodotto un caso in ogni stato e hanno superato tutte e tre le prove: La parte falsificabile è semplice. Prendi il dispositivo sano vuoto e rimuovi la ricevuta di controllo: il suo stato diventa coverage unknown . Il campionamento inferiore da 1 a 0.1 : diventa sampled unknown . Aggiungi tre righe filtrate: diventa incident found . Il numero delle righe ha significato solo dopo che il percorso di prova è stato stabilito. Una finestra di registro vuota verificata non è ancora un risultato di agente healthy empty è intenzionalmente ristretto. Significa che il filtro di registro Cloudflare Workers selezionato non ha restituito file corrispondenti in una finestra coperta. Ciò non significa che il lavoratore abbia prodotto la risposta corretta, che una scrittura a valle sia stata commessa una volta, che un lavoro programmato abbia consegnato il suo artefatto o che il compito più ampio di agente dell'utente abbia avuto successo. Presentazione generale dell'osservabilità dei lavoratori di Cloudflare separa registri, tracce, metriche, analisi e telemetria esportata. Ogni superficie risponde a una domanda diversa. Un filtro di errori pulito può coesistere con un errore di business. Un registro di invocazione di successo può coesistere con un registro di destinazione mancante. Una richiesta di controllo nota può dimostrare la copertura della query senza dire nulla di un consumatore di coda non correlato. Aggiungere una ricevuta di risultato al di fuori della query di registro quando l'incidente comporta un effetto visibile all'utente: un file hash, versione del database, risposta pubblica, conferma di coda o altro controllo deterministico della destinazione. Se l'effetto potrebbe essersi verificato ma la ricevuta non è presente, non riprovare automaticamente al limite degli effetti collaterali. Riconciliati prima. Ci sono anche limiti alla privacy. Una sonda di controllo dovrebbe essere sintetica, limitata e facile da identificare senza inserire un segreto nei registri. Il ricevimento sanitario dovrebbe contenere hash e stati, non richiedere corpi. Cloudflare documenta che i registri di dimensioni eccessive possono essere truncati; una riga presente non è la prova che ogni campo previsto sia sopravvissuto. Ispezionare il confine $cloudflare.truncated quando la diagnosi dipende dal contenuto del registro. Il server MCP Cloudflare Observability è documentato come un lavoro in corso, quindi i nomi degli strumenti e il comportamento possono cambiare. Ripettere la scoperta di campo, inserire la data delle prove nei rapporti di incidenti e trattare le ipotesi degli strumenti obsoleti come un fallimento della query piuttosto che un risultato sano. Sidewisp è attualmente in anteprima privata. Gli adattatori di monitoraggio della produzione e i sistemi di recupero non vengono generalmente spediti. Il metodo qui è un modello operativo locale, non un'affermazione che Sidewisp attualmente si connette a account Cloudflare, consulta i lavoratori in diretta o risolve gli incidenti. La regola utile è più piccola: non promuovere mai le righe zero a salute finché un evento noto non dimostra che l'esatto set di dati, la portata, la finestra e la politica di raccolta erano in grado di restituire le prove. Ciò trasforma una risposta MCP in una decisione verificabile senza pretendere che i registri da soli dimostrino il risultato.