Phoenix LLM Osservabilità: prove di tracce sopravvivere riavvio

Phoenix può mostrare una traccia completa mentre il suo strato di prove è ancora fragile. Una pagina accessibile dimostra che il processo web risponde ora. Znot dimostra che una traccia più antica è sopravvissuta a un riavvio, che il collezionista ha ripreso l'ingestione o che la politica di conservazione efficace copre il periodo in cui il tuo team indaga sugli incidenti. Il default ragionevole è un'esercitazione di riavvio a due canarie: 1. consultare una traccia senza contenuti creata prima del riavvio; 2. riavviare il servizio Phoenix senza modificare il codice dell'applicazione; 3. richiedere di nuovo la stessa traccia; 4. trasmettere e consultare una seconda traccia dopo il riavvio; 5. confrontare l'età di osservazione e la ritenzione effettiva con limiti espliciti. Il vecchio canario mette alla prova la persistenza. I nuovi test canari hanno ripristinato l'ingestione. Hai bisogno di entrambe le cose. Se esiste solo la vecchia traccia, il deposito potrebbe andare bene mentre la raccolta è rotta. Se solo la nuova traccia esiste, il server e' tornato su un archivio vuoto o inaspettato. Tratta Phoenix come tre strati di prove . Documentazione architettonica di Phoenix separa il sistema in un'interfaccia web, un collezionatore di tracce e un backend di database SQL. Questa distinzione è importante durante la diagnosi: l'interfaccia può rispondere mentre l'ingestione di OTLP non funziona; il collezionista può accettare una connessione mentre una traccia non diventa mai consultabile; il database può essere raggiungibile mentre il contenitore punta a una nuova directory di lavoro SQLite; Tutti e tre possono essere alzati mentre un lavoro di conservazione rimuove le prove prima del previsto dal processo incidentale. Phoenix supporta SQLite e PostgreSQL. La sua documentazione attuale posiziona SQLite per lo sviluppo locale e le implementazioni per un utente singolo, con i dati sotto ~/.phoenix/ o PHOENIX WORKING DIR . PostgreSQL è la scelta di produzione documentata per le implementazioni multiutente e ad alta disponibilità. Questa non è una regola che SQLite sia sempre malsano. Un singolo sviluppatore può eseguire un'istanza locale affidabile con un volume montato. Il fallimento sta lasciando implicita la persistenza. La guida ufficiale di Docker mostra direttamente i due contratti: Per PostgreSQL, Phoenix si legge PHOENIX SQL DATABASE URL ; la guida documenta PostgreSQL 14 o più recente. Tieni il valore della connessione nel tuo sistema segreto, non in un ricevimento sanitario. La ricevuta richiede solo la classe backend, un identificatore di distribuzione opaco e il risultato delle query canarie. La messa inchiodata dell'immagine è un controllo separato. latest può essere conveniente per una sperimentazione locale monouso, ma fa un riavvio in grado di modificare allo stesso tempo le aspettative dell'applicazione e del suo database. Prima dell'esercizio, registrare un'immagine immutabile o una versione esplicita. Un ripartire con successo contro un'immagine sconosciuta non è una prova riproducibile. Costruire una ricevuta di riavvio senza contenuti Scegli un percorso canario che eserciti lo stesso collezionista e il percorso del progetto come il traffico dell'agente che ti interessa. Non inserire nel canario un vero richiamo, una risposta modello, un argomento di strumento, una credenziale o un identificatore del cliente. Un'etichetta di corsa casuale e timestamp sono sufficienti. L'endpoint REST documentato di Phoenix può essere elencare le tracce di un progetto con limiti di tempo di avvio e intervalli opzionali. Utilizzare il metodo di autenticazione della distribuzione, ma mantenere il valore di autorizzazione fuori dalla cronologia dello shell e la produzione salvata. Ad esempio, impostare valori di routing non segreti e richiedere una finestra temporale ristretta: Cercare la risposta localmente per la trace id opaca del canario; non esportare il corpo di risposta come telemetria generale. Se si richiede include spans=true , la dimensione della risposta e la latenza della query aumentano, quindi il riferimento Phoenix API raccomanda di ottenere dettagli di span pigri. Il processo di riavvio ha bisogno di tracciare l'identità e il tempo, non di contenuti immediati. Una ricevuta minima può sembrare così: effectiveRetentionDays significa la politica allegata al progetto effettivo, non semplicemente un default di implementazione. Phoenix conserva i dati per tempo indeterminato per impostazione predefinita, rappresentato come zero giorni nella sua politica di default. Un amministratore può assegnare alle singole attività politiche basate sul tempo o sul tracciamento. Il tempo di implementazione predefinito può aggiornare i nuovi progetti senza modificare le sovrapposizioni esistenti specifiche del progetto. Ecco perché l'intenzione di configurazione e lo stato effettivo del progetto sono prove diverse. Confronta la ritenzione con il tuo processo operativo. Se un incidente può rimanere inosservato per 14 giorni, una finestra di traccia di sette giorni si degrada anche quando ogni traccia attuale è presente. Anche 30 giorni non sono intrinsecamente sani; sono sani solo rispetto alla finestra di revisione, al budget di stoccaggio e alla decisione di gestione dei dati. Eseguire l' esercitazione senza nascondere l' interruzione Utilizzare la normale operazione di riavvio del runtime. Non combinare il primo allenamento con un aggiornamento di Phoenix, migrazione di archiviazione, riconfigurazione del collezionatore o rilascio dell'applicazione. Il punto è quello di isolare la persistenza e riprendere l'ingestione. Immediatamente prima del riavvio: 1. registrare la versione o la digestione dell'immagine fissata; 2. confermare il backend della base di dati previsto e il volume duraturo o l'identità della base di dati; 3. registrare l'efficace politica di conservazione del progetto; 4. emettono il primo canario attraverso il percorso normale strumentale; 5. la query e memorizzare solo il risultato boolean, ID trace e timestamp. Dopo il riavvio: 1. attendere il comportamento di preparazione documentato del servizio piuttosto che utilizzare un sonno arbitrario; 2. consultare lo stesso tracciato prima del riavvio; 3. emettono un canario diverso dopo il riavvio; 4. consultare la nuova traccia attraverso lo stesso percorso del progetto; 5. sigillare la ricevuta e valutarla prima che scada il limite di freschezza. L'apparecchio di accompagnamento di questo articolo applica un limite di osservazione di cinque minuti e riporta nove stati: Il risultato è 9/9 cases pass . Due configurazioni sono classificate come sane: pinned PostgreSQL per una distribuzione multi utente, e pinned SQLite con un volume duraturo per un utente. Le altre apparecchiature producono deliberatamente evidence lost , ingestion failed , waiting , needs human , uncertain o degraded . La priorità decisionale è: Le prove Verdicto Decisione dell'operatore La migrazione è in corso come previsto . waiting Osservare l'operazione di manutenzione limitata; non definirla un guasto dell'agente Migrazione fallita needs human Fermare il recupero automatico e controllare il confine di database/versione L'osservazione è più antica del limite di freschezza uncertain Riescita la query prima di agire In politica, una vecchia traccia è scomparsa. evidence lost Conservazione della memoria corrente e diagnosi prima dell'identità di montaggio/database Rimane una traccia antica , ma manca una nuova . ingestion failed Controllare la raggiungibilità del collezionista, il percorso dell'esportatore, l'autore e il percorso del progetto Entrambe le tracce esistono, ma la ritenzione è troppo breve. degraded Allineare l'efficace politica del progetto con la revisione degli incidenti Entrambe le tracce esistono, le prove sono fresche e i controlli corrispondono. healthy Lo strato di prove ha superato questo foraggio di confine. Questo ordinamento impedisce che un avvertimento di configurazione maschi la perdita di dati effettiva. Un'immagine non appoggiata e' importante, ma una traccia mancante in politica e' il primo incidente. Mettere le migrazioni al di fuori del recupero cieco Phoenix documenta che le nuove versioni principali possono eseguire migrazioni di database durante l'avvio. Avverte anche che il rollolamento di un'immagine di applicazione torna a not automaticamente il schema del database. Ciò rende il riavvio del vecchio contenitore una regola di recupero generica non sicura dopo un importante aggiornamento fallito. Per Kubernetes, la Guida migratoria raccomanda di eseguire le migrazioni in una initContainer in modo che siano completate prima che il contenitore principale sia sottoposto a controlli di vitalità. Spiega anche che la creazione di indici PostgreSQL può bloccare le scritture. PHOENIX MIGRATE INDEX CONCURRENTLY=true evita di tenere quella serratura di scrittura, ma il compromesso documentato è una migrazione circa due o tre volte più lenta, e la nuova capsula sta ancora aspettando il completamento. Traduci queste meccaniche in stati: una migrazione all'interno della sua finestra di manutenzione approvata è waiting ; una query effettuata mentre lo stato di migrazione è sconosciuto è uncertain ; una migrazione fallita che potrebbe aver avanzato lo schema è needs human ; il rollback automatico è consentito solo quando il piano di compatibilità del database lo supporta esplicitamente. Questa è la stessa distinzione che le operazioni di agenti affidabili richiedono altrove: l'attività non è progresso, l'attesa non è bloccata e il completamento del comando non è il risultato previsto. Sappiate cosa non dimostra questo ricevimento. Una ricevuta di riavvio passante protegge un percorso di prova. Non dimostra che ogni percorso modello sia strumentale, che ogni intervallo sia semanticamente corretto, che un backup possa essere ripristinato o che un agente abbia fornito il risultato previsto. Inoltre non convalida il contenuto di una valutazione LLM. Sono test separati. La ricevuta è intenzionalmente priva di contenuti. Ciò riduce l'esposizione, ma significa anche che gli errori semantici richiedono una valutazione limitata o una revisione umana. Tratti le prove non disponibili come non disponibili; non riempire le prove con una saggia ipotesi. Il modello sanitario previsto da Sidewisp riguarda la freschezza delle prove, la raggiungibilità, i progressi utili, i risultati e i limiti di recupero sicuro. Il modello operativo qui si adatta a quel territorio, ma non si tratta di una richiesta di integrazione spedita. Sidewisp non si collega attualmente a Phoenix né monitorizza questa distribuzione. Sidewisp è attualmente in anteprima privata. Se stai definendo il primo contratto sanitario per un pacchetto di agenti, conserva questa ricevuta di riavvio accanto alla ricevuta di risultato dell'agente. Uno ti dice se le prove diagnostiche sono sopravvissute. L'altro ti dice se il lavoro ha funzionato.