Elastico LLM Osservabilità: supporto all'audit prima del verde

L'osservabilità elastica di LLM può dirti molto sulle chiamate di modello, ma una vista Kibana verde non è ancora un verdetto di salute dell'agente. Prima di fidarsi di esso, verificare cinque strati in ordine: il percorso di raccolta, il supporto per la coppia di lingue/fornitori esatte, la freschezza della telemetria, i campi GenAI richiesti e il risultato di destinazione. L'ordine conta. Elastic documenta due metodi di raccolta: integrazioni dei fornitori per le metriche e i registri e tracciamento delle applicazioni attraverso le distribuzioni elastiche di OpenTelemetry (EDOT). Tali metodi hanno una copertura diversa. Anche un intervallo LLM supportato e privo di errori non dimostra che la logica di business specifica per l'applicazione è stata eseguita o che esiste il risultato promesso. Questa guida trasforma questi confini in un piccolo audit che puoi eseguire prima di risolvere un incidente. Identificare il percorso di raccolta prima di leggere la scheda di controllo LLM e AI visione generale dell'osservabilità agentica di Elastic descrive un'ampia serie di integrazioni di provider, tracce APM, metriche, registri e dashboard. Il primo errore operativo è comprimere tutto questo in una capacità chiamata Elastic monitoring. Tenere due aerei di raccolta separati: Aereo Che cosa produce le prove Utile per Ciò che non stabilisce Integrazione dei fornitori Un fornitore o un servizio cloud invia metriche e registri Errori del fornitore, latenza, utilizzo, eventi di guardrail, salute della piattaforma Che la tua domanda abbia emesso un intervallo LLM o abbia completato il suo effetto strumento Tracciamento delle applicazioni EDOT Un processo strumentale di Java, Node.js o Python esporta spans OTLP Flusso di richieste, chiamate di modello, durata, errori, campi di token, correlazione Che le biblioteche non supportate siano state strumentalizzate o che il consegnabile esterno esista Non si tratta di una debolezza del prodotto. E' un limite di prove. Un'integrazione Bedrock può fornire nuove metriche di servizio mentre un'applicazione Java non ha strumentazione EDOT Bedrock LLM documentata. Al contrario, una durata di cliente OpenAI può essere completa mentre una scrittura di database personalizzata successiva non è strumentale. Il Pagina di supporto EDOT LLM corrente di Elastic rende concreto il confine linguistico/fornitore: Percorso del fornitore EDOT Java EDOT Node.js EDOT Python : : : Cliente OpenAI Sostenuto Sostenuto Sostenuto AWS Bedrock Non elencati Non elencati Sostenuto Google Vertex AI Non elencati Non elencati Sostenuto La pagina etichetta l'osservabilità di LLM nelle tre distribuzioni EDOT come preview tecnico e indica agli operatori le pagine specifiche dello SDK per le versioni esatte. Tratta quel tavolo come un'istantanea di supporto datata, non come una promessa di capacità eterna. L'audit inizia quindi con due domande alle quali una tabella di controllo non può rispondere per voi: 1. Quale aereo dovrebbe contenere le prove di questo incidente? 2. La lingua, il provider, il pacchetto client e la versione utilizzati hanno documentato l'istrumentazione su quel piano? Se la risposta alla seconda domanda è no, non aspettare che si verifichi un intervallo mancante. Classificare il percorso come non supportato, scegliere strumentazione OpenTelemetry nativa o manuale documentata o modificare il requisito di prova. Nessun errore in Elastic non è significativo quando l'evento rilevante non si prevedeva mai di essere catturato. Supporto dei test e schema come cancelli separati Supportato non significa osservato, e osservato non significa completo. Il Tabella di tecnologia Python EDOT documenta le versioni di Python, le fasce di pacchetti del cliente, i nomi dei tracciatori e lo stato della convenzione semantica. Al momento della presente revisione, la sua riga di strumenti OpenAI etichetta le convenzioni semantiche come development . La stessa pagina dice esplicitamente che l'istrumentazione automatica non può coprire framework personalizzati o proprietari, componenti non supportati a fonte chiusa o logica aziendale specifica per l'applicazione. Questo ci dà quattro controlli distinti: 1. Support: la matrice documentata include la coppia lingua/fornitore. 2. Reaccessibilità: il collezionatore e il percorso di ingestione accettano la telemetria corrente. 3. Presenza: la corsa produce la durata prevista di LLM. 4. Schema: lo spazio contiene i campi necessari per la decisione dell'operatore. Un contratto di campo minimo potrebbe richiedere: Non confondere questo esempio con uno schema universale. Pin le versioni di convenzione semantica e di strumentazione utilizzate dalla tua distribuzione. Le ex pagine di convenzione GenAI di OpenTelemetry indicano ora un repositorio dedicato di convenzioni semantiche di GenAI, che è un'altra ragione per registrare la provenienza piuttosto che supporre che un insieme di attributi sia senza tempo. Il classificatore di seguito conserva gli importanti stati di guasto: Eseguire l'audit contro un dispositivo piuttosto che testare solo il sentiero felice: Il corrispondente incontro di nove casi ha prodotto nove verdetti attesi: Questa priorità impedisce un errore comune di monitoraggio: lasciare che un segnale verde successivo nasconda un vuoto di prova precedente. Un intervallo di successo non può annullare un assegno di collezione irraggiungibile, e una corsa completata non può annullare una ricevuta di destinazione mancante. Conserva l'attesa, la mancanza di prove e il fallimento come stati diversi Una pausa di approvazione non è un guasto di strumentazione. Un intervallo mancante non è automaticamente un fallimento del fornitore. Un percorso non supportato non è una telemetria obsoleta. Queste distinzioni modificano la prossima mossa dell'operatore: Verdicto Significato La prossima azione è limitata . UNSUPPORTED PATH La strumentazione automatica LLM prevista è al di fuori della matrice documentata Aggiungere i termini nativi/manuali documentati o modificare il contratto di prova TELEMETRY STALE Esistono prove pertinenti, ma non all'interno della finestra di freschezza della corsa Controllare l'esportazione, il collezionatore, l'ingestione, l'orologio e la finestra di consultazione INSTRUMENTATION GAP Il percorso è supportato e arriva una nuova telemetria, ma la distanza LLM è assente. Verificare la gamma di pacchetti, bootstrap, strumentazione disabilitata e identità del tracciatore SCHEMA GAP L'intervallo esiste ma non riesce a rispondere alla domanda richiesta Controllare la versione della convenzione e la mappatura dei campi; riferire che il campo non è disponibile nel frattempo WAITING Una dipendenza o approvazione nominata è eccezionale Avvisare il proprietario registrato; non riprovare lo strumento ciecamente FALSE COMPLETE Elastico mostra completamento pulito ma il risultato promesso non è verificato Eseguire una verifica deterministica della destinazione prima di chiudere l'incidente Notate cosa la tabella non raccomanda: trattare ogni lacuna come un motivo per riavviare l'agente. Il recupero senza diagnosi può duplicare gli effetti esterni, spendere più token o cancellare prove utili. Per un'attesa legittima, tenere un proprietario, ragione, ora di inizio, scadenza e condizione di ripresa. Questo trasforma una pausa ambiguosa in uno stato operativo ispezionabile. Se il termine passa, lo stato può rimanere bloccato o richiedere l'attenzione umana, ma la pausa iniziale non è stata un fallimento semplicemente perché non sono arrivati nuovi spazi. Richiedere un ricevimento di risultato fuori dalla traccia Un intervallo LLM risponde a una domanda di chiamata modello. Il consegnabile appartiene alla domanda. Supponiamo che un agente chieda a un modello di preparare una fattura, chiama un'API interna e riferisce il completamento. Elastico può mostrare: una traccia fresca; il fornitore e il modello atteso; nessuna eccezione; la latenza plausibile e il conteggio dei token; una transazione di base completata. La fattura può essere ancora assente. L'API personalizzata può aver accettato la richiesta senza impegnarla, un lavoratore asincrono può aver fallito o l'agente può aver saltato l'utensile e aver prodotto solo una richiesta testuale. Defini la più piccola ricevuta deterministica che dimostri l'effetto promesso. Esempi sono: l'oggetto atteso esiste alla destinazione e corrisponde ad un hash di contenuto; una riga di base di dati ha la chiave di business prevista e lo stato di impegno; esiste una richiesta di pull presso il repository previsto e la SHA di capo; un endpoint report restituisce la nuova versione e passa la convalida dello schema; un fornitore di messaggi restituisce un identificatore di consegna che può essere riconciliato in seguito. Conservare solo le prove sicure minime: L'identificatore di traccia fornisce una correlazione. Non è la prova stessa. Nel dispositivo, l'unica differenza tra FALSE COMPLETE e HEALTHY è outcomeVerified: true ; nessuno dei campi di span Elastic cambia. Questa è la regola operativa centrale: eliminare un incidente solo quando la copertura telemetrica e le prove dei risultati dell'applicazione concordano. Trattare la privacy e la deriva di versione come parte della salute La panoramica di Elastic dice che il tracciamento LLM può catturare richieste e risposte. Questo può essere utile per la diagnosi, ma cambia anche i confini dei dati. Decidere esplicitamente se il contenuto è consentito prima di consentirlo. Preferire identificatori, lunghezze, hash, classificazioni, conteggi di token e categorie di errori modificati quando non è richiesto il contenuto completo. Registrare questi valori con ogni audit di copertura: La versione di distribuzione EDOT e distribuzione elastica; il tempo di esecuzione linguistico e la versione del pacchetto client strumentale; il nome del pacchetto di strumentazione attiva e del tracciatore; fonte e revisione della convenzione semantica; il percorso di raccolta e di ingestione; campi richiesti e finestra di freschezza; politica di cattura dei contenuti; versione del verificatore di destinazione. Riattivare il dispositivo quando uno di questi valori cambia. Un aggiornamento del pacchetto può aggiungere supporto, rinominare o migrare i campi o modificare l'istrumentazione predefinita. Un oggetto salvato dal cruscotto può rimanere verde mentre le sue ipotesi diventano silenziosamente obsolete. Il default pratico è modesto: utilizzare Elastic per il modello e le prove di applicazione che effettivamente raccoglie, mantenere espliciti i segnali non supportati o mancanti e aggiungere una ricevuta deterministica per il risultato che interessa all'utente. Che produce una decisione di salute difensata senza fingere che un tabellone di controllo possieda ogni strato. Sidewisp è attualmente in anteprima privata. La sua direzione del prodotto è quella di trasformare le prove come la raggiungibilità, il progresso, l'accesso agli strumenti, il contesto, il costo e i risultati verificati in una visione chiara della salute; attualmente gli adattatori di monitoraggio Elastic in diretta non vengono spediti. Se questa distinzione tra il completamento della traccia e il lavoro reale è importante nel tuo stack di agenti, la lista di attesa di anteprima privata è il luogo adatto per condividere il caso di fallimento che devi coprire.