2026-07-31T20:27:17.480Z

Datadog LLM Documentazione sull'osservabilità: Copertura degli strumenti di revisione

Trasformare l'attuale SDK di Datadog e la documentazione di auto-strumentazione in un audit di otto casi per compatibilità, avvio, campionamento, lacune manuali, attese e risultati verificati.

Il modo utile per leggere la documentazione di osservabilità Datadog LLMZ è come un contratto di strumentazione versione, non come prova che ogni importante passo dell'agente è visibile. Prima di fidarsi di una traccia, verificare quattro cose: il tuo framework e tracer versioni sono supportati insieme, esattamente un percorso di configurazione è attivo, campionamento conserva le prove necessarie per le decisioni di salute, e ogni effetto esterno ha un risultato deterministico ricezione. Questa distinzione è importante perché una traccia apparentemente completa può ancora nascondere un database personalizzato, un'integrazione non supportata, un'attesa legittima di approvazione o un prodotto mancante. L'audit di seguito trasforma queste lacune in otto verdetti espliciti. Non utilizza richieste, risposte, chiavi API o dati dei clienti. Inizia con il contratto di supporto, non con il cruscotto. Presentazione generale dell'attività di osservazione dell'agente di Datadog dice che una richiesta di applicazione appare come una traccia e che gli intervalli rappresentano scelte o passaggi di flusso di lavoro. Questo è il modello giusto per indagare la latenza, gli errori, l'uso dei token e il percorso attraverso un agente. Non è una promessa che una domanda arbitraria sia completamente strumentale. La riferimento di strumentazione automatica limita il tracciamento automatico ai framework e alle librerie supportate. Essa indica esplicitamente agli operatori di utilizzare strumenti manuali per altre chiamate API, query di database e funzioni interne. Trattare la documentazione come quattro contratti collegati: Contratto Prove da registrare Un fallimento che una traccia verde può nascondere Compatibilità tempo di esecuzione, versione quadro, versione tracciatrice, modalità modulo il percorso di codice non supportato emette spazi parziali o zero Iniziazione una modalità di impostazione abilitata, sito, nome dell'applicazione, trasporto duplice inizializzazione o dati inviati alla destinazione sbagliata Copertura politica di campionamento e un manifesto delle operazioni che deve essere visibile un evento sanitario richiesto viene prelevato o non viene mai utilizzato Risultato ricevuta di attesa e ricevuta di completamento specifica per la destinazione l'agente segnala il completamento ma l'effetto richiesto è assente Tali contratti dovrebbero essere contrassegnati a un'istantanea di documentazione datata. Il 30 luglio 2026, la tabella Python di Datadog ha elencato LangGraph =0.2.23 con ddtrace =3.10.1 . La stessa pagina elencava diversi minimi per altri quadri e lingue. Abbiamo installato l'ultimo pacchetto è quindi una prova più debole di questa coppia esatta di applicazioni/tracciatori soddisfa la riga di supporto verificata. Il Referenza SDK aggiunge un altro limite: Python line command setup con ddtrace run e in code setup con LLMObs.enable() sono alternative. La sua sezione di codice avverte di non combinarli. Il riferimento espone anche DD LLMOBS SAMPLE RATE , il che significa che la conservazione delle tracce è una decisione dell'operatore piuttosto che una garanzia di salute intrinseca. Eseguire un audit di strumenti in otto casi L'apparecchio di audit fissa una riga di supporto Python, LangGraph 0.2.23 e ddtrace 3.10.1 , quindi modifica un dato operativo per caso. Salvare la struttura di seguito come instrumentation cases.json e estendere la sua matrice cases con le otto condizioni descritte dall'output registrato: Utilizzare questa regola di decisione in audit datadog instrumentation.mjs : Eseguire l' audit: La corsa registrata ha valutato otto partite e ha corrisponduto a tutti gli otto verdetti attesi: L'ordine dei controlli è deliberato. La compatibilità viene prima di tutto perché un intervallo mancante da una coppia non supportata non deve essere diagnosticato come un fallimento dell'applicazione. La startup viene dopo perché due percorsi di configurazione creano uno stato di raccolta ambiguo. La copertura segue perché un tracciatore correttamente iniziato può comunque omettere le prove richieste. L'attesa e il controllo dei risultati sono gli ultimi perché descrivono il lavoro e non il trasporto telemetrico. Si tratta di un controllo delle configurazioni e dei contratti di prova. Si collega Znot a un inquilino Datadog o prova ingestione. Una volta che è passato, inviare una corsa canaria e confermare che la spesa di radice e bambino previsto appare sotto l'applicazione prevista, sito, ambiente e finestra di tempo. Prendere una decisione sulla copertura del campionamento Datadog documenta un tasso di campione di osservabilità dell'agente configurabile. Il campionamento è utile quando le tracce diagnostiche complete sono costose, ma crea una rigorosa conseguenza operativa: l'assenza di una traccia campionata non può dimostrare l'assenza di una corsa, di una chiamata di strumento o di un fallimento. Tenere due percorsi di prova quando le decisioni sanitarie devono coprire ogni corsa: 1. Tracce diagnostiche possono essere prelevate. Conservano dei dettagli per l'indagine. 2. Le ricevute sanitarie obbligatorie rimangono compatte e senza campionamento. Registrano l'identità della corsa, lo stato, la freschezza, la proprietà di attesa, la destinazione attesa e lo stato di verifica dei risultati. Il dispositivo restituisce coverage gap quando sampleRate è inferiore a 1 e non esiste un registro sanitario obbligatorio. Non significa che la corsa sia fallita. La conclusione corretta è più restrittiva: le prove disponibili non possono sostenere un'affermazione di salute universale. Ciò impedisce anche un errore di allarme comune. Una traccia mancante campionata non deve indicare all'operatore un'interruzione. Prima di tutto, confrontate la ricevuta non campionata, il battito cardiaco e la freschezza della raccolta. Escalare solo quando le prove dimostrano un errore rilevante per l'utente o non sono disponibili dopo una scadenza esplicita. Aggiungere intervalli manuali ai confini di effetto L'istrumentazione automatica è il punto di partenza, non una mappa del risultato aziendale. Supponiamo che un agente chiami un modello e uno strumento supportati, quindi esegue una funzione interna chiamata write release manifest . Le estensioni del modello e degli strumenti possono finire normalmente mentre l'ultima funzione fallisce silenziosamente. Creare un piccolo manifesto operativo prima del lancio: L'audit restituisce instrumentation gap quando un'operazione richiesta non è coperta automaticamente o manualmente. Non riparare questo aggiungendo spans a ogni funzione di aiuto. Limiti degli strumenti che modificano la decisione dell'operatore: chiamate tra i servizi, scritture durevoli, controlli di autorizzazione, transizioni di approvazione, ripetizioni con effetti esterni e verifica della destinazione. La ricevuta più forte dovrebbe provenire dalla destinazione. Per un file, verificare il percorso previsto e digerire. Per una richiesta di pull, consultare il servizio di hosting per le relazioni pubbliche e i controlli richiesti. Per un messaggio, conservare l'identificatore accettato del fornitore e conciliare la consegna quando il flusso di lavoro lo richiede. Span terminato senza errore è prova di attività; non è lo stesso che esiste il risultato richiesto. Assicurati di aspettare invece di etichettarlo male come bloccato. Le tracce dell'agente spesso includono lunghe pause. Alcune sono fallimenti; altre sono aspettative corrette di una persona, di un fornitore o di una finestra programmata. La durata da sola non li distingue. Un'attesa legittima ha bisogno di una piccola ricevuta: Senza proprietario, scadenza e identità riproducibile, il dispositivo restituisce ambiguous wait . Non restituisce immediatamente stuck , poiché le prove sono insufficienti. Con una ricevuta valida, il monitoraggio può rimanere silenzioso fino alla scadenza, indirizzare la richiesta alla persona giusta e verificare successivamente che il lavoro sia ripristinato. Questa distinzione impedisce agli operatori di recuperare un lavoro sano riprovandolo. Un tentativo di ripetizione non sicuro al confine dell'effetto esterno può creare biglietti, messaggi, pagamenti o distribuzioni duplicati anche quando la corsa originale stava semplicemente aspettando la conferma. Leggi insieme la traccia di Datadog e la ricevuta del risultato Utilizzare la traccia Datadog per rispondere: Le richieste di quadro e di modello previste sono apparse? Quale periodo ha fallito, rallentato o consumato token insoliti? L'albero delle tracce ha conservato la struttura attesa tra genitore e figlio? Le prove sono fresche e sono associate all'applicazione prevista? Utilizzare la ricevuta sanitaria separata per rispondere: La corsa era prevista in questo momento? Sta funzionando, sta aspettando, è bloccato, incerto o completo? Ogni effetto richiesto si e' verificato una volta? La destinazione contiene il risultato promesso? L'impianto finale è intenzionalmente inconveniente: il percorso di tracciamento è supportato, l'installazione è pulita, il campionamento è completato e non manca alcuna operazionema la corsa richiede complete senza ricevuta di risultato. Il suo verdetto è false green . Questo è il limite da mantenere. Datadog può fornire traccia dettagliata, valutazione, latenza, errore e prove token. La vostra domanda deve comunque definire cosa significa successo e verificarlo dove vive il risultato. Sidewisp applica la stessa distinzione di salute prima nella sua direzione del prodotto: l'attività non è un utile progresso, l'attesa non è bloccata automaticamente e l'esecuzione del comando non è un risultato verificato. Sidewisp è attualmente in anteprima privata. Gli adattatori di monitoraggio della produzione non sono generalmente spediti oggi; il sito pubblico è un'esperienza di accesso precoce e una dimostrazione del prodotto. La sequenza di implementazione pratica è breve: fissare la data della documentazione, registrare la riga di supporto, scegliere un percorso di avvio, dichiarare il limite di campionamento, elencare le operazioni di effetto richieste, riprodurre le otto luci, quindi inviare un canario in diretta e verificare la sua destinazione. Solo dopo che tutti questi ricevute saranno d'accordo, una traccia verde dovrebbe diventare un verdetto verde contro l'agente sanitario.