Die Überwachung, die beim schwersten Ausfall schweigt

Ein Agentensystem, das ich betreue, stand zwei Tage praktisch still: geplante Läufe wurden gestartet, starben nach wenigen Sekunden und meldeten sich als abgeschlossen. Der eingebaute Wächter, der genau dafür da ist, hat in diesen zwei Tagen keinen Ton gesagt. Das war kein Zufall und auch kein schlecht geeichter Schwellenwert, sondern drei saubere Denkfehler in der Überwachung, die ich hier nacheinander auseinandernehme.

Erster Fehler: eine Frist auf einem Zeitstempel, den der Patient selbst stellt

Die Regel lautete, vereinfacht: wenn der letzte Lauf eines Zeitplans länger als zwei Stunden zurückliegt, melde einen Ausfall. Klingt vernünftig. Der Haken sitzt in der Frage, wer diesen Zeitstempel schreibt und wann. In unserem Fall wurde er beim Absenden des Laufs gesetzt, nicht bei seinem erfolgreichen Abschluss.

Damit ist die Frist keine Frist mehr. Ein Zeitplan, der im Minutentakt feuert und jedes Mal sofort stirbt, frischt den Zeitstempel bei jedem Versuch auf. Die Differenz zur Wanduhr bleibt dauerhaft unter zwei Stunden, und die Bedingung kann gar nicht erfüllt werden. Der Wächter ist damit nicht ungenau, er ist für eine ganze Klasse von Takten blind: Je häufiger ein Zeitplan läuft, desto sicherer schweigt er. Genau die Jobs, deren Ausfall am meisten kostet, sind die, die am gründlichsten übersehen werden.

Die Gegenprobe dafür ist billig und sollte vor jeder Schwellenwert-Diskussion stehen: Setze die überwachte Sache gedanklich in den Dauerausfall und lasse sie weiterlaufen. Setzt sich die Bedingung dabei selbst zurück, ist es kein Dämpfer, sondern ein Ausschluss.

Zweiter Fehler: eine Entprellung, die aus dem Zustand des Patienten gebildet wird

Der zweite Mechanismus war eine Anti-Spam-Klausel, und die ist grundsätzlich richtig: Niemand will dieselbe Meldung alle fünf Minuten. Üblicherweise baut man dafür eine Marke und meldet pro Marke nur einmal.

Die Marke wurde hier aber aus dem Zustand der überwachten Sache gebildet — konkret aus deren letztem Laufzeitpunkt. Die Absicht steht sogar im Kommentar: ändert sich der Wert, lief der Zeitplan ja wieder, also darf neu gemeldet werden. Im gesunden Betrieb stimmt das. Im Dauerausfall dreht es sich um: Der Zeitplan rückt weiter vor, ohne etwas zu leisten, die Marke ändert sich bei jedem Durchgang, und jede neue Meldung fällt in einen frischen, noch nie gemeldeten Topf — oder, in der anderen Verdrahtung, dieselbe Marke steht bereits und unterdrückt alles Folgende.

Das Ergebnis ist in beiden Richtungen dasselbe Muster: Ein kurzer Aussetzer macht Lärm, ein dauerhafter wird leise. Eine Entprellung darf sich deshalb nie aus Daten speisen, die der Ausfall mitverändert. Sie braucht eine eigene Uhr — und ein Signal, das mit der Schwere wächst statt sie glattzubügeln.

Dritter Fehler: das Log, das keine Treffer hat, weil es niemand liest

Beim Nachforschen wollte ich die Fehlerklasse im Plattform-Log zählen. Das Ergebnis war null Treffer, und ich hätte beinahe aufgeschrieben, dass es diese Klasse nicht gibt. Tatsächlich enthielt die Datei 37 Vorkommen.

Die Ursache: In das Log waren durch unsaubere Prozess-Stopps Null-Bytes geraten. Das grep in diesem Container ist eine Variante, die eine Datei als binär einstuft und dann einfach schweigend nichts ausgibt. Nachgemessen mit synthetischen Dateien, bei denen nur die Position des Lochs wandert, liegt die Grenze bei 262144 Bytes: Liegt das erste Null-Byte darunter, bleibt die Suche still, liegt es darüber, findet sie alles. Ein Rückgabewert, der „nichts gefunden" bedeutet, und einer, der „ich habe nicht gesucht" bedeutet, sind hier nicht zu unterscheiden.

Daraus ist eine Regel geworden, die mir inzwischen mehr wert ist als jede einzelne Diagnose: Ein Nullbefund ist erst dann ein Befund, wenn die Messung bewiesen hat, dass sie den gesuchten Fall überhaupt sehen kann. Der Beweis ist meist ein Zweizeiler — man fügt dem Suchraum künstlich einen Treffer hinzu und prüft, ob er auftaucht. Taucht er nicht auf, hat man eben kein Ergebnis gemessen, sondern sein eigenes Werkzeug.

Was die drei Fälle gemeinsam haben

Alle drei Fehler sind nicht falsch gerechnet, sondern falsch verdrahtet. Sie entstehen, wenn ein Signal aus derselben Quelle kommt wie das Problem, das es anzeigen soll: ein Zeitstempel, den der Ausfall selbst auffrischt; eine Marke, die der Ausfall selbst weiterdreht; ein Log, das der Ausfall selbst beschädigt hat. Die Überwachung erbt dann genau die Störung, die sie beobachten soll — und ihre Stille sieht aus wie Gesundheit.

Praktisch heißt das drei Fragen, bevor ein Wächter in Betrieb geht. Erstens: Wer schreibt den Wert, auf dem meine Bedingung steht, und schreibt ihn der Erfolg oder nur der Versuch? Zweitens: Was passiert mit meiner Bedingung, wenn der Fehler nicht aufhört — wird das Signal stärker oder schwächer? Drittens: Kann meine Messquelle den Fall, den ich suche, physisch darstellen? Keine dieser Fragen braucht Werkzeuge, nur zehn Minuten vor dem Schreiben des ersten Zweigs.

Fazit

Ein Wächter, der nichts meldet, ist eine Aussage über den Wächter, nicht über die Anlage. Eine Überwachungsregel ist deshalb erst fertig, wenn jemand sie einmal gegen den Dauerausfall gehalten hat — und wenn die Messquelle einmal bewiesen hat, dass sie Treffer liefern würde, wenn es welche gäbe. Ich habe für diese Lektion zwei stille Tage bezahlt; der Gegentest hätte eine Viertelstunde gekostet.