Phoenix LLM Observabilité: les traces de preuve survivent à la redémarrage

Phoenix peut montrer une trace complète alors que sa propre couche de preuves est encore fragile. Une page accessible prouve que le processus Web répond maintenant. Znot prouve qu'une trace plus ancienne a survécu à un redémarrage, que le collecteur a repris l'ingestion ou que la politique de conservation effective couvre la période pendant laquelle votre équipe enquête sur les incidents. Le défaut raisonnable est un exercice de redémarrage à deux canaries: 1. une trace sans contenu créée avant le redémarrage; 2. redémarrer le service Phoenix sans modifier le code de l'application; 3. Rechercher la même trace; 4. émettre et consulter une deuxième trace après le redémarrage; 5. comparer l'âge d'observation et la rétention effective avec des limites explicites. Le vieux canary met à l'épreuve la persévérance. Les nouveaux tests canariens ont repris l'ingestion. Vous avez besoin des deux. Si seulement l'ancienne trace existe, le stockage peut être bien pendant que la collection est cassée. Si seulement la nouvelle trace existe, le serveur est revenu sur un stockage vide ou inattendu. Traitez Phoenix comme trois couches de preuves La documentation de l'architecture de Phoenix sépare le système en une interface Web, un collectionneur de traces et un backend de base de données SQL. Cette distinction est importante lors du diagnostic: l'interface peut répondre pendant que l'ingestion OTLP échoue; le collecteur peut accepter une connexion alors qu'une trace ne devient jamais consultable; la base de données peut être accessible pendant que le conteneur pointe vers un nouveau répertoire de travail SQLite; Tous les trois peuvent être mis en place pendant qu'un travail de rétention supprime les preuves plus tôt que le processus d'incident ne l'attend. Phoenix prend en charge SQLite et PostgreSQL. Sa documentation actuelle positionne SQLite pour le développement local et les déploiements à utilisateur unique, avec des données sous ~/.phoenix/ ou PHOENIX WORKING DIR . PostgreSQL est le choix de production documenté pour les déploiements multi utilisateurs et à haute disponibilité. Ce n'est pas une règle selon laquelle SQLite est toujours malsain. Un seul développeur peut exécuter une instance locale fiable avec un volume monté. L'échec laisse la persévérance implicite. Le guide officiel de Docker indique directement les deux contrats: Pour PostgreSQL, Phoenix lit PHOENIX SQL DATABASE URL ; le guide documente PostgreSQL 14 ou plus récent. Gardez la valeur de connexion dans votre système secret, pas dans un reçu de santé. Le reçu n'a besoin que de la classe backend, d'un identifiant de déploiement opaque et du résultat des requêtes canaries. L'affichage de l'image est un contrôle séparé. latest peut être pratique pour un essai local jetable, mais il permet un redémarrage capable de modifier les attentes de l'application et de sa base de données en même temps. Enregistrez une image immuable ou une version explicite avant l'exercice. Un redémarrage réussi contre une image inconnue n'est pas une preuve reproductible. Créer un reçu de redémarrage sans contenu Choisissez un chemin canarien qui exerce le même collecteur et le même routage de projet que le trafic d'agents qui vous intéresse. Ne mettez pas une vraie requête, un modèle de réponse, un argument d'outil, une carte d'identité ou un identifiant de client dans le canary. Une étiquette et un timestamp sont suffisants. L'extrémité REST documentée de Phoenix peut liste des traces d'un projet avec des limites d'heure de démarrage et des intervalles optionnels. Utilisez la méthode d'authentification de votre déploiement, mais gardez la valeur d'autorisation hors de l'historique du shell et de la sortie enregistrée. Par exemple, définissez des valeurs de routage non secrètes et demandez une fenêtre de temps étroite: Rechercher la réponse localement pour le trace id opaque du canary; ne pas exporter le corps de réponse en tant que télémétrie générale. Si vous demandez include spans=true , la taille de la réponse et la latence de la requête augmentent, donc la référence de l'API Phoenix recommande de récupérer les détails de la portée paresseusement. La séance de redémarrage a besoin d'identification et de temps, pas de contenu rapide. Un reçu minimal peut ressembler à ceci: effectiveRetentionDays désigne la politique attachée au projet réel, et non simplement un défaut de déploiement. Phoenix conserve les données indéfiniment par défaut, représenté comme zéro jour dans sa politique par défaut. Un administrateur peut attribuer des politiques basées sur le temps ou le nombre de traces à des projets individuels. Le temps de déploiement par défaut peut mettre à jour de nouveaux projets sans modifier les surcharges existantes spécifiques au projet. C'est pourquoi l'intention de configuration et l'état efficace du projet sont des preuves différentes. Comparez la rétention avec votre processus d'exploitation. Si un incident peut passer inaperçu pendant 14 jours, une fenêtre de repérage de sept jours est dégradée même lorsque toutes les traces actuelles sont présentes. Trente jours n'est pas non plus intrinsèquement sain; il est sain seulement par rapport à la fenêtre d'examen, au budget de stockage et à la décision de gouvernance des données. Exécutez l' exercice sans cacher l' interruption Utilisez l'opération normale de redémarrage de l'exécution. Ne combinez pas le premier exercice avec une mise à niveau de Phoenix, une migration de stockage, une reconfiguration du collecteur ou une sortie d'application. Le but est d'isoler la persistance et de reprendre l'ingestion. Immédiatement avant le redémarrage: 1. l'enregistrement de la version imprimée ou de la digestion de l'image; 2. confirmer l'arrière plan de base de données prévu et le volume durable ou l'identité de la base de données; 3. enregistrer la politique effective de conservation du projet; 4. émettent le premier canarien à travers le chemin normal avec instrument; 5. la requérir et stocker uniquement le résultat booléen, l'identifiant de trace et les timestamps. Après redémarrage: 1. attendre le comportement de préparation documenté du service au lieu d'utiliser un sommeil arbitraire; 2. effectuer une requête sur la même trace avant le redémarrage; 3. émettent un canary différent après le redémarrage; 4. rechercher la nouvelle trace à travers le même itinéraire du projet; 5. sceller le reçu et l'évaluer avant l'expiration de sa limite de fraîcheur. L'appareil d'accompagnement de cet article applique une limite d'observation de cinq minutes et remplace neuf états: Le résultat est 9/9 cases pass . Deux configurations sont classées comme saines: PostgreSQL fiché pour un déploiement multi utilisateurs, et SQLite fiché avec un volume durable pour un utilisateur. Les appareils restants produisent délibérément evidence lost , ingestion failed , waiting , needs human , uncertain ou degraded . La décision est prioritaire: Les preuves Le verdict Décision de l'opérateur La migration se déroule comme prévu . waiting Observer l'opération de maintenance limitée; ne la qualifiez pas de défaillance de l'agent La migration a échoué needs human Arrêter la récupération automatique et inspecter la limite de base de données/version L'observation est plus ancienne que la limite de fraîcheur uncertain Retournez la requête avant d'agir Une ancienne trace de la politique a disparu. evidence lost Préserver le stockage actuel et diagnostiquer d'abord l'identité de l'installation/de la base de données Des traces anciennes restent, mais des traces nouvelles sont absentes. ingestion failed Inspection de la facilité d'accès du collecteur, du chemin de l'exportateur, de l'autorisation et du routage du projet Les deux traces existent, mais la rétention est trop courte. degraded Aligner la politique de projet efficace avec l'examen des incidents Les deux traces existent, les preuves sont fraîches, et les contrôles correspondent. healthy La couche de preuves a traversé ce forage délimité Cette ordonnance empêche un avertissement de configuration de masquer la perte de données réelle. Une image sans support est importante, mais une trace manquante dans la politique est le premier incident. Mettre les migrations à l'extérieur de la récupération aveugle Phoenix fait savoir que de nouvelles versions majeures peuvent exécuter des migrations de base de données pendant le démarrage. Il prévient également que le retour d'une image d'application fait automatiquement baisser le schéma de base de données à not . C'est pourquoi le redémarrage du vieux conteneur est une règle de récupération générique dangereuse après une mise à niveau majeure ratée. Pour Kubernetes, le guide de migration recommande d'exécuter des migrations dans un initContainer afin qu'elles soient terminées avant que le conteneur principal ne soit soumis à des contrôles de vie. Il explique également que la création d'un index PostgreSQL peut bloquer les écrits. PHOENIX MIGRATE INDEX CONCURRENTLY=true évite de tenir cette serrure d'écriture, mais le compromis documenté est une migration environ deux à trois fois plus lente, et la nouvelle capsule attend encore d'être achevée. Translatez ces mécanismes en états: une migration se déroulant à l'intérieur de sa fenêtre d'entretien approuvée est waiting ; une requête effectuée alors que l'état de migration est inconnu est uncertain ; une migration ratée qui a peut être fait avancer le schéma est needs human ; le retour automatique n'est autorisé que lorsque le plan de compatibilité de la base de données le soutient explicitement. C'est la même distinction que les opérations d'agents fiables ont besoin ailleurs: l'activité n'est pas un progrès, l'attente n'est pas bloquée et l'achèvement d'un commandement n'est pas le résultat prévu. Sachez ce que ce reçu ne prouve pas Un reçu de redémarrage de passage protège un chemin de la preuve. Cela ne prouve pas que chaque modèle de route est instrumenté, que chaque intervalle est sémantiquement correct, qu'une sauvegarde peut être restaurée ou qu'un agent a fourni le résultat prévu. Il ne valide pas non plus le contenu d'une évaluation LLM. Ce sont des tests séparés. Le reçu est intentionnellement libre de contenu. Cela réduit l'exposition, mais cela signifie aussi que les erreurs sémantiques nécessitent une évaluation limitée ou un examen humain. Traitez les preuves qui ne sont pas disponibles comme si elles n'étaient pas disponibles; ne les remplissez pas d'une bonne conjecture. Le modèle de santé prévu par Sidewisp concerne la fraîcheur des preuves, la facilité d'accès, les progrès utiles, les résultats et les limites de récupération sûre. Le modèle opérationnel correspond ici à ce territoire, mais il ne s'agit pas d'une revendication d'intégration maritime. Sidewisp ne se connecte actuellement pas à Phoenix ni ne surveille ce déploiement. Sidewisp est actuellement en préversion privée. Si vous définissez le premier contrat de santé pour une pile d'agents, gardez ce reçu de redémarrage à côté du reçu de résultats de l'agent. L'un vous dira si les preuves diagnostiques ont survécu. L'autre vous dit si le travail l'a fait.