Grüne Telemetrie kann stillen Datenverlust verbergen, wenn Workloads die Tools wechseln

Ein Software-Ingenieur entdeckte, dass sein automatisiertes Telemetriesystem über Wochen hinweg eine normale Gesundheit meldete, während es gleichzeitig stillschweigend versagte, den Großteil seiner KI-Agent-Aktivitäten zu erfassen. Der Vorfall ereignete sich im Oktober 2026, nachdem der Nutzer seinen Workflow von Claude Code zu Codex umgestellt hatte – eine Änderung, die die Datengenerierung außerhalb des Bereichs seiner bestehenden Monitoring-Pipeline verlegte.

Was passiert ist

Der Ingenieur pflegt einen wöchentlichen geschichteten Vergleichsbericht, der Agent-Sitzungen analysiert und Metriken wie Tool-Fehlerraten und Output-Tokens verfolgt. Dieser Bericht wird jeden Montag um 09:30 Uhr per Cron-Job generiert und verarbeitet Transkripte aus einem spezifischen Verzeichnis, das von Claude Code verwendet wird. Über mehrere Wochen hinweg wurde der Bericht weiterhin mit dem Status „normal“ veröffentlicht, ohne Datenqualitätsprobleme und mit konsistenten statistischen Verteilungen.

Die zugrunde liegenden Daten hatten sich jedoch drastisch verändert. Am 6. September 2026 konfigurierte der Nutzer sein System so, dass unbeaufsichtigte geplante Läufe und Headless-Abfragen standardmäßig an Codex weitergeleitet wurden, wobei Claude Code auf nur zwei Sitzungen pro Tag beschränkt war. Später, am 5. Oktober, wechselte er Claude Code zurück in die Rolle des Haupt-Orchestrators, aber unbeaufsichtigte Läufe blieben bei Codex. Die Ingestion-Pipeline wurde nie aktualisiert, um aus dem Codex-Sitzungsverzeichnis zu lesen, was bedeutete, dass sie nur einen winzigen Bruchteil der tatsächlich ausgeführten Arbeit erfasste.

Trotz dieser enormen Blindstelle bestanden die Health Checks jede Woche. Das System überprüfte, ob der Kopierbefehl mit Exit-Code 0 beendet wurde, ob die Anzahl der Archivdateien nicht abnahm und ob interne Datenkonsistenzregeln erfüllt waren. Da der Cron-Job selbst erfolgreich lief und die wenigen verbleibenden Claude-Code-Dateien fehlerfrei verarbeitete, hatte das Monitoring-System keinen Grund, einen Vorfall zu melden. Der Bericht beschrieb genau den kleinen Ausschnitt der erhaltenen Daten und erzeugte ein falsches Gefühl der Sicherheit.

Wichtige Details

• Der Telemetrie-Bericht zeigte über Wochen identische Mediane und Interquartilsbereiche, mit Abweichungen von nur 12 Zeilen, die sich auf Metadaten und geringfügige Zählungen bezogen.
• Zwischen dem 13. und 20. September protokollierte das System null Claude-Code-Transkriptdateien, aber 192 Codex-Rollout-Dateien.
• Vom 27. September bis zum 4. Oktober erfasste die Ingestion nur 3 Claude-Code-Dateien, während 1.058 Codex-Dateien generiert wurden.
• Die neueste Sitzung in der Datenbank endete am 11. September, doch der Bericht vom 21. September markierte das System weiterhin als normal.
• Die Health Checks validierten die Prozessausführung und Datenkonsistenz, überprüften aber nicht, ob das Volumen der ingestierten Daten mit der tatsächlichen Aktivität übereinstimmte.
• Eine separate Staleness-Prüfung (Veraltetheitsprüfung) bestand, weil die Datenbankdatei unabhängig davon, ob neue Daten hinzugefügt wurden, wöchentlich durch den Build-Prozess neu geschrieben wurde.

Hintergrund

Telemetriesysteme verlassen sich oft auf „Heartbeat“- oder Exit-Code-Monitoring, um die Gesundheit zu bestimmen. Wenn ein Skript ohne Absturz vollständig ausgeführt wird, gilt es als gesund. Dieser Ansatz funktioniert gut zur Erkennung von Abstürzen, versagt aber bei „stillen Fehlern“, bei denen das Skript läuft, aber keine sinnvollen Daten verarbeitet. In diesem Fall war das Monitoring eng an einen spezifischen Tool-Pfad gekoppelt. Als sich der Workload auf ein anderes Tool mit einer anderen Dateistruktur verschob, überwachte das System weiterhin den leeren alten Pfad.

Dies illustriert eine häufige Falle bei selbst gehosteter Observability: Das Monitoring konzentriert sich auf den Mechanismus statt auf das Ergebnis. Das System bestätigte, dass die Datenpipeline betriebsbereit war, aber nicht, dass die Pipeline die erwarteten Eingaben erhielt. Ohne einen externen Nenner – eine Zählung der gesamten über alle Tools hinweg ausgeführten Arbeit – konnte das System nicht erkennen, dass sich sein Blick auf die Welt verengt hatte.

Warum das wichtig ist

Für Teams, die ihre eigene Software betreiben, verdeutlicht dieses Szenario das Risiko statischen Monitorings in dynamischen Umgebungen. Wenn sich Infrastruktur und Workflows entwickeln, werden hartcodierte Pfade und Annahmen zu Haftungsrisiken. Wenn Ihr Backup-Skript erfolgreich läuft, aber ein leeres Verzeichnis sichert, weil sich die Datenquelle bewegt hat, bleibt Ihr Monitoring wahrscheinlich grün, bis Sie versuchen, ein Restore durchzuführen. Die Abwesenheit von Fehlern ist kein Beweis für Erfolg.

Dieser Vorfall zeigt auch die Gefahr, sich zu sehr auf interne Konsistenzprüfungen zu verlassen. Metriken wie „null verwaiste Tool-Ergebnisse“ sind wertvoll für die Datenintegrität, aber nutzlos für die Abdeckung. Ein System kann perfekt konsistent sein und dennoch völlig irrelevant. Ingenieure müssen sicherstellen, dass ihre Health Checks Gültigkeitsbeschränkungen für Datenvolumen und Aktualität im Verhältnis zur externen Realität enthalten, nicht nur interne Prozesszustände.

Darüber hinaus machte die Stille des Fehlers ihn schwerer zu erkennen als einen Crash. Ein kaputtes Skript erzeugt Alarme; ein funktionierendes Skript, das veraltete Daten verarbeitet, erzeugt Vertrauen. Teams müssen Monitore so gestalten, dass sie lautstark fehlschlagen, wenn keine Daten mehr eintreffen, anstatt stillschweigend das Akzeptieren, was verfügbar ist. Dies erfordert eine Entkopplung der Definition von „gesund“ von „fehlerfrei ausgeführt“.

Was Sie tun können

• Implementieren Sie Heartbeat-Monitoring für kritische Jobs, das ein explizites Signal aus dem Prozess heraus erfordert, nicht nur einen erfolgreichen Exit-Code.
• Fügen Sie externe Nenner-Prüfungen hinzu, die das ingestierte Datenvolumen mit bekannten Quellen der Wahrheit vergleichen, z. B. Datei-Zählungen in allen relevanten Verzeichnissen.
• Konfigurieren Sie Staleness-Alerts basierend auf dem Zeitstempel des neuesten Datensatzes, nicht auf der letzten Änderungszeit der Datenbankdatei.
• Überprüfen Sie Routing-Richtlinien und Tool-Änderungen, um sicherzustellen, dass Monitoring-Scopes aktualisiert werden, wann immer sich Datenquellen verschieben oder erweitern.
• Testen Sie die Monitoring-Logik durch Simulation von Datenverhungern (Data Starvation), um zu überprüfen, ob Szenarien mit niedrigem Volumen angemessene Warnungen auslösen.
• Entkoppeln Sie Alerting von der primären Tool-Nutzung, indem Sie Benachrichtigungen an Kanäle senden, die unabhängig vom überwachten System sind.