Osservabilità LLM su AWS: controllo delle destinazioni Span AgentCore

La risposta pratica all' Osservabilità LLM su AWS non è "aprire il dashboard CloudWatch". Per prima cosa prova dove Amazon Bedrock AgentCore dovrebbe consegnare gli span, quindi cerca ogni destinazione che può ancora contenere prove, verifica l'identità della sessione e della traccia, rifiuta le osservazioni obsolete e unisci la traccia a una ricevuta separata per il risultato esterno previsto. Questo ordine è importante perché la destinazione di AgentCore può cambiare. La documentazione attuale di AWS afferma che i nuovi agenti supportati possono inviare intervalli a un gruppo di log per agente, mentre le configurazioni precedenti possono utilizzare il metodo condiviso aws/spans gruppo. Versioni ADOT precedenti 0.18.0 ignorare l'impostazione della destinazione unificata. La modifica dell'impostazione non sposta le vecchie campate. Una query effettuata solo sul gruppo di log odierno può quindi produrre una falsa diagnosi di "assenza di telemetria" anche quando le prove mancanti si trovano esattamente dove le aveva inserite la configurazione precedente. Questa guida crea un controllo privo di contenuti per tale confine. Utilizza identità della risorsa, versione, destinazione, timestamp, identificatori di correlazione, stato di esecuzione e una ricevuta di risultato booleana. Non richiede prompt, risposte, argomenti dello strumento o segreti. Individuare le prove prima di dichiararle mancanti Osservabilità di AgentCorefornisce parametri integrati per le risorse AgentCore e archivia parametri, intervalli e log in Amazon CloudWatch. Il limite importante è che le metriche integrate non sono le stesse tracce dell'applicazione. AWS documenta gli intervalli predefiniti per le risorse di memoria, mentre i dettagli di runtime dell'agente e di traccia del gateway dipendono dalla strumentazione. Ciò crea tre domande separate: 1. Il percorso di osservazione AWS è abilitato? CloudWatch Transaction Search deve essere abilitato e la destinazione del segmento di traccia deve essere CloudWatch Logs. 2. Dove dovrebbero finire gli intervalli attuali? La risposta dipende dall'impostazione della destinazione unificata, dal supporto regionale, dall'età dell'agente, dal ruolo di esecuzione e dalla versione ADOT. 3. Dove possono rimanere gli intervalli storici? Qualsiasi destinazione utilizzata prima di uno switch rimane parte della finestra di indagine perché AWS non migra i dati degli intervalli esistenti. ILGuida alla configurazione di AgentCorefornisce un limite operativo particolarmente utile: la consegna unificata per agente richiede aws opentelemetry distro =0.18.0 . Le versioni precedenti ignorano la configurazione e forniscono gli span al gruppo condiviso. La stessa guida richiede l'autorizzazione per installare la policy delle risorse CloudWatch Logs pertinente. Utilizza questi fatti per calcolare una destinazione prevista prima di eseguire una query: Osservazione Ambito di ricerca corrente previsto Conclusione dell'operatore Ricerca transazioni disabilitata Nessuno è ancora affidabile Correzione della configurazione; non dedurre lo stato dell'agente Traccia i segmenti non instradati a CloudWatch Logs Nessuno è ancora affidabile Correggere il prerequisito di destinazione Richiesto unificato, ADOT di seguito 0.18.0 Condiviso aws/spans Un gruppo vuoto per agente è un errore nell'ambito della query Criteri attivi e di ruolo unificati consentiti Gruppo di log di runtime per agente Controlla lì le campate attuali La destinazione è cambiata durante la finestra di revisione Gruppi attuali e precedenti Cerca entrambi; le vecchie campate restano dove sono atterrate Questa tabella non è deliberatamente un singolo controllo della "telemetria presente". Un record mancante nel gruppo per agente può significare un errore di configurazione, una consegna bloccata, una versione ADOT obsoleta o un record cronologico corretto nel gruppo condiviso. Quegli stati necessitano di riparazioni diverse. Conserva un record della transizione di destinazione Non fare dell'impostazione attiva la tua unica fonte di verità. Archivia un piccolo record di transizione accanto al runbook: Il record non contiene alcun contenuto di prompt o di risposta. Risponde alla domanda di pianificazione delle query che una dashboard non può ricostruire in seguito: quali destinazioni si sovrappongono alla finestra dell'incidente? Esegui un controllo AgentCore sensibile alla migrazione L'audit utilizzato per questo articolo valuta undici casi risolti. Il suo contratto di input è intenzionalmente piccolo: Il suo ordine decisionale è più importante della sua sintassi: Eseguendo il classificatore sull'apparecchiatura prodotta: I casi riguardano la ricerca delle transazioni disabilitata, la destinazione della traccia errata, il vecchio ADOT interrogato solo nel gruppo per agente, l'omissione di prove storiche dopo un passaggio, un'autorità di consegna insufficiente, un intervallo corrente mancante, prove obsolete, correlazione interrotta, un'attesa di approvazione legittima, un falso completamento e un risultato sano in grado di riconoscere la migrazione. Questo è un test decisionale, non una prova su un account AWS attivo. Adatta i suoi input dalla tua configurazione e dalle query canary. Conservare l'ordinamento: altrimenti generico telemetry missing Il verdetto può nascondere il fatto molto più perseguibile che l'operatore ha cercato nel posto sbagliato. Preserva l'identità della sessione, l'identità della traccia e la freschezza AWS descrive l'osservabilità di AgentCore come una gerarchia: una sessione contiene tracce e una traccia contiene intervalli. ILdocumentazione telemetricarende esplicita quella gerarchia. È utile solo se l'identità sopravvive al percorso della richiesta. Per le chiamate runtime AgentCore basate su ADOT, la guida alla configurazione documenta due dettagli di propagazione: Inviare X Amzn Bedrock AgentCore Runtime Session Id quindi l'ID di sessione raggiunge la telemetria a valle; richiamare il runtime con traceId=<traceId quando è necessario propagare un ID di traccia. Registra se tali identificatori sono presenti, non il contesto sensibile del payload. Un intervallo senza sessioni collegabili può comunque dimostrare che il codice è stato eseguito, ma non può supportare una sequenza temporale dell'incidente a livello di sessione. Classificalo come correlation broken , non sano. La freschezza ha bisogno di un contratto altrettanto esplicito. Una traccia trovata la scorsa settimana non dimostra che la consegna funzioni ora. Definire: Scegli l'età massima dalla cadenza prevista del flusso di lavoro e dalla tolleranza agli incidenti. Cinque minuti sono ragionevoli per un canarino ogni minuto; è irragionevole per un lotto notturno. Conservare la soglia con il verdetto affinché “fresca” rimanga ispezionabile. Anche l’attesa ha bisogno di prove. Se una traccia mostra una dipendenza di approvazione limitata con un proprietario e l'esecuzione è ripristinabile, restituisce waiting . Non paginarlo come bloccato semplicemente perché non è apparso alcun nuovo intervallo di strumenti. Se il verbale di approvazione è assente, contraddittorio o scaduto, restituire uncertain o eseguire l'escalation in base al runbook. Richiedere ricevuta di esito dopo la tracciatura Una traccia completa risponde “il percorso di esecuzione strumentato è terminato?” Non risponde necessariamente “il lavoro previsto è stato realizzato?” La distinzione è visibile nei guasti comuni: uno strumento di caricamento ritorna prima che la destinazione impegni l'oggetto; un'API di messaggio accetta una richiesta ma il messaggio non raggiunge mai il canale previsto; un agente scrive un file locale mentre l'artefatto richiesto appartiene all'archivio remoto; la chiamata del modello finale ha esito positivo dopo che una transazione a valle è già stata ripristinata; un'attesa di approvazione viene erroneamente convertita in un successo terminale. Guida prescrittiva AWSraccomanda di correlare le prove LLM con l’impatto a valle. Un'implementazione minima in termini di privacy può farlo con una ricevuta di esito: La ricevuta dovrebbe essere prodotta dal controllo deterministico più forte disponibile: un oggetto HEAD , un database letto tramite chiave stabile, un recupero API pubblica, un checksum o un test mirato. Non deve contenere il corpo dell'oggetto, il prompt, la risposta o il segreto. Tenete separati i due verdetti: Traccia prove Ricevuta esito Stato Mancante o obsoleto Qualunque Le prove di osservabilità sono insufficienti Completare Mancante false complete In attesa di approvazione registrata Non ancora previsto waiting Completo e fresco Presente e verificato healthy per questo risultato testato L'ambito della riga finale è limitato. Dimostra il canarino e la destinazione fissi, non ogni percorso, ogni attività o la qualità dell'output semantico. Adottare l'audit senza raccogliere contenuti Una ricevuta di produzione utile necessita solo di dati sufficienti per distinguere gli strati di guasto: identificatori di risorse e endpoint dell'agente in forma redatta o con hash; Regione e tempo di osservazione; Ricerca delle transazioni e stato della destinazione del tracciamento; Versione ADOT e impostazione di destinazione unificata; classi di destinazione attuali e precedenti; se entrambe le destinazioni sono state cercate durante la finestra di indagine; orario canarino corrispondente più recente; presenza dell'ID di sessione e dell'ID di traccia; stato di esecuzione e stato di approvazione limitato; identità operativa stabile e stato deterministico di esito ricezione. Mantieni il testo dei prompt, le risposte del modello, gli argomenti dello strumento, le credenziali, le intestazioni non elaborate e i payload del cliente fuori da questa ricevuta. Se per un incidente specifico è necessaria un'ispezione più approfondita dei contenuti, autorizzala e definiscila separatamente. Anche l'audit ha dei limiti. Non dimostra la copertura della strumentazione in ogni percorso applicativo, la completezza del campionamento, la conservazione di CloudWatch, il ripristino dell'esportazione o la qualità della risposta semantica. Dimostra che il percorso delle prove selezionato è configurato e ricercabile, che il canarino è fresco e correlato e che il risultato esterno selezionato ha una propria ricevuta. Ciò è sufficiente per evitare un costoso errore di categoria: cambiare l'agente perché un operatore ha cercato la destinazione dello span sbagliata. Sidewisp è attualmente in anteprima privata.Il suo ruolo previsto è quello di trasformare prove come la copertura della destinazione, l'aggiornamento, la correlazione, lo stato di attesa e la verifica dei risultati in una visione chiara della salute. Gli adattatori di monitoraggio Production AgentCore e CloudWatch non vengono attualmente spediti, quindi questo articolo è un modello operativo che puoi applicare ora, non un'affermazione cheSidewispesegue già questo controllo.