Phoenix LLM Beobachtbarkeit: Nachweisspuren Überleben Neustart

Phoenix kann eine vollständige Spur zeigen, während seine eigene Beweislage noch zerbrechlich ist. Eine erreichbare Seite beweist, dass der Webprozess jetzt antwortet. Znot beweist, dass eine ältere Spur einen Neustart überlebt hat, dass der Sammler die Einnahme wieder aufgenommen hat oder dass die effektive Aufbewahrungsrichtlinie den Zeitraum deckt, in dem Ihr Team Vorfälle untersucht. Die vernünftige Standardlage ist eine zwei Kanarien Wiederstart Boot: 1. Abfrage eines vor dem Neustart erstellten inhaltfreien Spuren; 2. den Phoenix Dienst ohne Änderung des Anwendungscodes neu starten; 3. die gleiche Spur wieder abfragen; 4. eine zweite Spur nach dem Neustart ausstrahlen und abfragen; 5. Vergleichen Sie das Alter der Beobachtung und die wirksame Aufbewahrung mit ausdrücklichen Grenzen. Die alten Kanarien testen die Beharrlichkeit. Die neuen Kanarien Tests haben die Einnahme wieder aufgenommen. Du brauchst beides. Wenn nur die alte Spur existiert, kann die Lagerung in Ordnung sein, während die Sammlung kaputt ist. Wenn nur die neue Spur existiert, ist der Server auf leerem oder unerwartetem Speicher zurückgekehrt. Phoenix als drei Beweislagen behandeln . Die Architekturdokumentation von Phoenix trennt das System in eine Weboberfläche, einen Spurenkollektor und ein SQL Datenbank Backend. Diese Unterscheidung ist bei der Diagnose wichtig: die Schnittstelle kann antworten, wenn die OTLP Eingestaltung fehlschlägt; der Sammler kann eine Verbindung akzeptieren, während eine Spur nie nachfragbar wird; die Datenbank ist zugänglich, während die Container auf ein neues Arbeitsverzeichnis SQLite hinweisen; Alle drei können aufstehen, während eine Aufbewahrungsarbeit Beweise früher entfernt, als der Vorfallprozess erwartet. Phoenix unterstützt SQLite und PostgreSQL. Die aktuelle Dokumentation stellt SQLite für lokale Entwicklungen und Einbenutzer Einsätze mit Daten unter ~/.phoenix/ oder PHOENIX WORKING DIR fest. PostgreSQL ist die dokumentierte Produktionswahl für Multi User und hochverfügbarkeitsbasierte Bereitstellungen. Dies ist keine Regel, dass SQLite immer ungesund ist. Ein einzelner Entwickler kann eine zuverlässige lokale Instanz mit einem montierten Volumen ausführen. Das Scheitern lässt die Beharrlichkeit implizit. Die offizieller Docker Leitfaden zeigt die beiden Verträge direkt an: Für PostgreSQL liest Phoenix PHOENIX SQL DATABASE URL ; der Leitfaden dokumentiert PostgreSQL 14 oder neuere. Bewahren Sie den Anschlusswert in Ihrem geheimen System, nicht in einer Krankenüberweisung. Die Quittung benötigt nur die Backend Klasse, einen unsichtbaren Bereitstellungs Identifikator und das Ergebnis der Kanarienfragen. Das Pinning des Bildes ist eine separate Steuerung. latest ist zwar für eine Einweglokalversuch praktisch geeignet, aber es ermöglicht einen Neustart, der gleichzeitig die Erwartungen an die Anwendung und ihre Datenbank verändern kann. Vor dem Bohrvorgang ein unveränderliches Bild oder eine explizite Version aufnehmen. Ein erfolgreicher Neustart gegen ein unbekanntes Bild ist kein reproduzierbarer Beweis. Erstellen Sie eine Inhaltsfreie Neustart Rechnung Wählen Sie einen Kanarienweg, der den gleichen Sammler und Projektrouting wie der Agent Traffic ausübt, den Sie interessieren. Stellen Sie keine echte Anforderung, Modellreaktion, Werkzeugargumentation, Anmeldeinformationen oder Kunden Identifikator in den Kanarien. Ein zufällig ausgeführtes Etikett und Zeitstempel reichen aus. Der dokumentierte REST Endpunkt von Phoenix kann Liste von Spuren für ein Projekt mit Startzeitgrenzen und optionale Spannungen. Verwenden Sie die Authentifizierungsmethode Ihres Einsatzes, aber halten Sie den Berechtigungswert aus der Shell Geschichte und gespeicherten Ausgabe. Setzen Sie beispielsweise nicht geheime Routingwerte und verlangen Sie ein schmales Zeitfenster: Suchen Sie die Antwort lokal nach dem unsichtbaren trace id des Kanarien; exportieren Sie den Antwortkörper nicht als allgemeine Telemetrie. Wenn Sie include spans=true anfordern, erhöhen sich die Reaktionsgröße und die Abfrage Latenz, so dass die Phoenix API Referenz empfiehlt, Spannungsdetails faul zu holen. Die Neustart Boot muss Identität und Zeit aufspüren, nicht Inhalt. Eine minimale Quittung kann so aussehen: effectiveRetentionDays bezeichnet die mit dem eigentlichen Projekt verbundene Politik, nicht nur eine Ausführung. Phoenix Speichert Daten nach Standardzeit unbestimmt, repräsentiert als Null Tage in seiner Standardpolitik. Ein Administrator kann den einzelnen Projekten Zeit oder Spurenzahl basierte Richtlinien zuweisen. Die Standardzeit für die Bereitstellung kann neue Projekte aktualisieren, ohne die vorhandenen projektspezifischen Überschriften zu ändern. Aus diesem Grund sind die Absicht der Konfiguration und der effektive Projektzustand unterschiedliche Beweise. Vergleichen Sie die Aufbewahrung mit Ihrem Betrieb. Wenn ein Vorfall 14 Tage lang unbemerkt bleiben kann, wird ein sieben tägiges Spurenfenster eingeschränkt, auch wenn alle aktuellen Spuren vorhanden sind. Auch 30 Tage sind nicht von Natur aus gesund; sie sind nur im Verhältnis zum Überprüfungszeitraum, zum Speicherbudget und zur Entscheidung über die Datenverwaltung gesund. Führen Sie die Bohrungen durch, ohne die Unterbrechung zu verbergen. Verwenden Sie die normale Neustartoperation. Kombinieren Sie die erste Bohrung nicht mit einem Phoenix Upgrade, einer Speichermigration, einer Rekonfiguration des Kollektors oder einer Applikationsveröffentlichung. Es geht darum, die Beharrlichkeit zu isolieren und die Einnahme wieder aufzunehmen. Unmittelbar vor dem Neustart: 1. Aufzeichnen Sie die versehene Version oder die Bildverarbeitung; 2. bestätigen Sie das beabsichtigte Backend der Datenbank und das dauerhafte Volumen oder die Datenbankidentität; 3. die wirksame Aufbewahrungspolitik des Projekts aufzeichnen; 4. die erste Kanarie durch den normalen Instrumentenweg ausstrahlen; 5. Sie können es abfragen und nur das Boolean Ergebnis, die Trace ID und die Zeitstempel speichern. Nach Neustart: 1. Erwarten Sie das dokumentierte Bereitschaftsverhalten des Dienstes, anstatt willkürlich zu schlafen; 2. die gleiche Spur vor dem Neustart abfragen; 3. eine andere Kanarie nach dem Neustart ausstrahlen; 4. die neue Spur über die gleiche Projektroute abfragen; 5. Sie stempeln die Quittung und bewerten sie vor Ablauf der Frischheitsgrenze. Die Begleitvorrichtung für diesen Artikel setzt eine fünfminütige Beobachtungsgrenze und stellt neun Zustände wieder: Das Ergebnis ist 9/9 cases pass . Zwei Konfigurationen werden als gesund eingestuft: eine festgeschnürte PostgreSQL für eine Multi Benutzer Deployment und eine festgeschnürte SQLite mit einem langlebigen Volumen für einen Benutzer. Die übrigen Geräte produzieren absichtlich evidence lost , ingestion failed , waiting , needs human , uncertain oder degraded . Die Entscheidung hat Vorrang: Beweise Urteil Entscheidung des Betreibers Die Migration läuft wie geplant . waiting Beobachten Sie den begrenzten Wartungsvorgang; nennen Sie ihn nicht als Agentenversagen Die Migration ist gescheitert. needs human Stoppen Sie die automatische Wiederherstellung und überprüfen Sie die Datenbank/Versionsgrenze Die Beobachtung ist älter als die frische Grenze uncertain Laufen Sie die Abfrage vor der Handlung erneut durch Die alten Spuren in der Politik verschwanden . evidence lost Erhaltung des aktuellen Speichers und Diagnose der Montage /Datenbankidentität Alte Spuren bleiben, aber neue Spuren fehlen. ingestion failed Überprüfen Sie die Erreichbarkeit des Sammlers, den Exporteur Pfad, die Auth und die Projektleitung Beide Spuren existieren , aber die Aufbewahrung ist zu kurz . degraded Die wirksame Projektpolitik mit der Überprüfung von Vorfällen in Einklang zu bringen Beide Spuren existieren, die Beweise sind frisch, und die Kontrollen passen. healthy Die Beweis Schicht hat diese begrenzte Bohrmaschine überschritten. Diese Reihenfolge verhindert, dass eine Konfigurationswarnung den tatsächlichen Datenverlust verschleiert. Ein ungestütztes Bild ist wichtig, aber eine fehlende Spur in der Politik ist der erste Vorfall. Migrationen außerhalb der Blind Recovery Phoenix dokumentiert, dass neue Hauptversionen Datenbank Migrationen während des Startups ausführen können. Es warnt auch davor, dass die Rückführung eines Anwendungsbildes Znot das Datenbank Schema automatisch abgradert. Das macht Restart des alten Behälters eine unsichere generische Wiederherstellungsregel nach einem gescheiterten großen Upgrade. Für Kubernetes empfiehlt die Migrationsleitfaden, Migrationen in einem initContainer durchzuführen, damit sie abgeschlossen werden, bevor der Hauptcontainer einer Lebensdauerprüfung unterzogen wird. Es erklärt auch, dass die Erstellung von PostgreSQL Index schreibt blockieren kann. PHOENIX MIGRATE INDEX CONCURRENTLY=true vermeidet, das Schreibschloss zu halten, aber der dokumentierte Kompromiss ist eine Migration etwa zwei bis dreimal langsamer, und die neue Kapsel wartet noch auf den Abschluss. Übersetzen Sie diese Mechanik in Zustände: eine Migration, die innerhalb seines zugelassenen Wartungsfensters läuft, ist waiting ; eine Abfrage, die während des Migrationszustands unbekannt erfolgt ist, ist uncertain ; eine fehlerhafte Migration, die das Schema möglicherweise fortgeschritten hat, ist needs human ; automatische Rückführung ist nur dann zulässig, wenn der Datenbankkompatibilitätsplan es ausdrücklich unterstützt. Dies ist die gleiche Unterscheidung, die zuverlässige Agenten Operationen an anderer Stelle brauchen: Aktivität ist kein Fortschritt, Warten ist nicht fest, und Befehlsvollständigung ist nicht das beabsichtigte Ergebnis. Wissen Sie , was diese Quittung nicht beweist . Eine Übergangs Wiederstart Receipt schützt einen Beweisweg. Es beweist nicht, dass jede Modellroute instrumentalisiert ist, jeder Span semantisch korrekt ist, ein Backup wiederhergestellt werden kann oder ein Agent das beabsichtigte Ergebnis liefert. Sie bestätigt auch nicht den Inhalt einer LLM Bewertung. Das sind separate Tests. Die Quittung ist absichtlich inhaltsfrei. Das reduziert die Exposition, bedeutet aber auch, dass semantische Fehler eine begrenzte Bewertung oder menschliche Überprüfung erfordern. Behandeln Sie nicht verfügbare Beweise als nicht verfügbar; füllen Sie sie nicht mit einer gesunden Vermutung. Das beabsichtigte Gesundheitsmodell von Sidewisp bezieht sich auf die Frische der Beweise, die Erreichbarkeit, den nützlichen Fortschritt, die Ergebnisse und die sicheren Grenzen der Wiederherstellung. Das operative Muster hier passt zu diesem Gebiet, aber es ist kein Anspruch auf eine verschiffte Integration. Sidewisp verbindet sich derzeit nicht mit Phoenix oder überwacht diesen Einsatz. Sidewisp befindet sich derzeit in einer privaten Vorschauphase. Wenn Sie den ersten Gesundheitsvertrag für einen Agentenstack definieren, behalten Sie diese Neustart Rechnung neben der Ergebnisrechnung des Agenten. Einer sagt Ihnen, ob die diagnostischen Beweise überlebt haben. Der andere sagt Ihnen, ob die Arbeit funktioniert.