#Monitoring

Ob ein Fehler am Server liegt oder am Rechner davor, verrät das Protokoll des Servers. Bei Vaultwarden scheiterte jede Einladung mit einer Meldung, die nach Server klang, also nach Ablauf, Zugang oder Mailversand. Im Protokoll stand zu den Klickversuchen jedoch kein einziger Aufruf: Die Oberfläche im Browser brach ab, bevor sie überhaupt fragte. Wo nichts ankommt, kann auch nichts falsch beantwortet werden, dann liegt die Ursache davor.

Eine leere Auswertung beweist nicht, dass nichts passiert ist, sie beweist oft nur, dass nichts aufgezeichnet wird. Ich habe im WLAN-Controller nach Verbindungsabbrüchen eines Geräts gesucht, keinen einzigen Eintrag gefunden und das fast als Entwarnung notiert. Dann habe ich die Tabelle selbst gezählt: null Datensätze insgesamt, für alle Geräte, seit Inbetriebnahme. Seitdem prüfe ich zuerst, ob eine Quelle überhaupt etwas liefert, bevor ich ihr Schweigen als Antwort nehme. Kein Befund ist noch kein Ergebnis.

Dreimal so viele Prozesse zählte ich, weil das Systemprotokoll bei jedem Absturz die komplette Liste noch einmal ausgibt. Bei drei Abstürzen standen dort 111 Einträge, tatsächlich liefen 37. Hätte ich der Zahl geglaubt, hätte ich einen größeren Server bestellt, statt die Obergrenze der Arbeitsprozesse von 89 auf 49 zu senken. Ein Protokoll zeigt Ereignisse, keine Bestände, und wer beides verwechselt, kauft die falsche Lösung.

Ein Besucherzähler reicht dafür nicht, weil er zeigt, dass jemand kam, aber nicht, warum. Unser Umami misst sauber, wie viele Leute eine Seite öffnen und wie weit sie lesen, doch die Suchbegriffe, mit denen sie überhaupt erst bei uns landen, stehen dort nirgends. Dafür habe ich diese Woche die Search Console angebunden, die einzige Quelle für diese eine Frage. Zwei Werkzeuge, zwei verschiedene Fragen: das eine zählt die Leute, das andere verrät, was sie gesucht haben.

Ob ein Fehler im Protokoll neu ist, weiß man erst, wenn man ihn im alten Zustand nachzählt. Nach dem Umzug unseres Dokumentenarchivs auf eigene Hardware meldete das Protokoll rund zweihundert Mal am Tag, die Datenbankverbindung sei geschlossen, und ich hielt das prompt für eine Folge des Umzugs. Im alten Container stand dieselbe Meldung 320 Mal, seit Monaten, ohne jeden Schaden: die Software baut die Verbindung einfach neu auf. Ein Fehler, der auffällt, weil man gerade hinsieht, ist deshalb noch keiner, der gerade entstanden ist.

Ein neues Messwerkzeug liefert keine Zahlen aus der Vergangenheit, weil es erst ab dem Tag zählt, an dem man es einschaltet. Ich habe unsere Seite am siebenundzwanzigsten Juli in der Google Search Console angemeldet und sofort eine Auswertung über neunzig Tage abgerufen, die vollkommen leer war. Die ersten echten Zahlen kamen ein bis drei Tage später, alles davor bleibt für immer dunkel. Eine Messung, die man erst startet, wenn man die Antwort braucht, kommt immer zu spät.

Einen Rechner, den der Überwachungsserver nicht erreicht, überwacht man andersherum: er meldet sich von selbst. Unser Uptime Kuma steht außerhalb des Werkstattnetzes und kommt an den Prüfstands-PC für die Abgasuntersuchung nicht heran. Also läuft dort alle fünf Minuten eine kleine Prüfung und schickt ein Lebenszeichen nach draußen; bleibt es aus, schlägt die Überwachung Alarm. Wer nicht angerufen werden kann, muss selbst anrufen.

Eine Überwachung, die nur läuft, solange jemand angemeldet ist, fällt genau dann aus, wenn man sie braucht. Unser Empfangsprogramm für die Abgasuntersuchung startet mit der Benutzersitzung, und meine erste Prüfaufgabe hing an derselben Sitzung. Meldet sich abends jemand ab, wären beide still gewesen, und Stille sieht aus wie Ruhe. Jetzt läuft die Prüfung als Systemaufgabe, unabhängig von der Anmeldung, und zeigte beim Test knapp acht Tage ununterbrochenen Empfang. Ein Wächter, der mit dem Bewachten einschläft, ist keiner.

Eine Sammeländerung erfasst nur die Datensätze, die das Programm überhaupt anzeigt. Ich hatte in Uptime Kuma alle Überwachungen auf einen E-Mail-Kanal umgestellt und fand fünf Tage später sechs weitere, die in keiner Liste und in keiner Abfrage auftauchten, weil ihnen in der Datenbank ein Feld fehlte. Einer davon stand seit Wochen auf rot, ohne dass es jemand sah. Seitdem zähle ich nach jeder Sammelaktion gegen die Datenbank, nicht gegen die Liste. Was ein Programm nicht anzeigt, hat man auch nicht geändert.

Melden muss sich eine Automatik seltener, als man zuerst denkt, sonst schlägt der Wächter Alarm, wenn gar nichts ist. Für unsere nächtlichen Abläufe habe ich in Uptime Kuma Wächter eingerichtet, bei denen sich der Ablauf selbst meldet statt abgefragt zu werden. Er läuft alle fünf Minuten, der Wächter wartet aber fünfzehn, bevor er Alarm gibt. So übersteht ein einzelner Aussetzer die Prüfung, ein echter Stillstand nicht. Ein Alarm, dem man nicht mehr glaubt, ist schlimmer als keiner.

Wenn alle Überwachungs-Meldungen gleichzeitig verstummen, ist selten jeder Job kaputt, sondern der gemeinsame Weg. Bei uns war die automatische Zertifikats-Erneuerung stillgelegt, das Zertifikat lief ab, und danach kam acht Tage lang keine einzige Erfolgsmeldung mehr bei Uptime Kuma an: 783 Warnungen aus einer einzigen Ursache. Die Sicherungen liefen die ganze Zeit sauber, nur sagen konnte es niemand mehr. Wer viele Alarme auf einmal sieht, sucht zuerst das, was sie alle gemeinsam haben.

Ein Dienst darf sich selbst neu starten, aber nur mit fester Bremse und nur als Schadensbegrenzung, nicht als Reparatur. Unser Dokumentenarchiv Paperless war wegen eines bekannten Speicherlecks erst sieben Stunden, dann noch einmal anderthalb Stunden nicht erreichbar, bis jemand den Container von Hand neu startete. Jetzt prüft ein kleiner Wächter alle zwei Minuten den Zustand und startet höchstens einmal in zehn Minuten neu, aus Stunden werden so drei bis vier Minuten. Die Ursache beheben wir trotzdem, der Wächter kauft nur die Zeit bis dahin.

Dass ein Alarm im Ernstfall wirklich ankommt, weiß man erst, wenn man ihn einmal absichtlich auslöst. Bei uns war das Dokumentenarchiv sieben Stunden nicht erreichbar, und Uptime Kuma blieb stumm: der Monitor war nie mit einem Meldekanal verknüpft, sein Zeitlimit stand auf null, und der E-Mail-Kanal selbst zeigte auf einen toten Anschluss. Drei Fehler auf einmal, und jeder einzelne hätte jede Warnung verhindert. Aufgeflogen ist das erst, als wir eine Testmeldung schickten und keine ankam. Eine Überwachung, die man nie testet, überwacht am Ende nur sich selbst.

Eine Überwachung meldet keinen Ausfall, wenn ihre Prüfung kein Zeitlimit hat. Unser Dokumentenarchiv lag sieben Stunden am Boden, und der zuständige Monitor blieb die ganze Zeit auf grün: Sein Zeitlimit stand auf null, also wartete er sechs Stunden und neunundvierzig Minuten auf eine Antwort, statt aufzugeben und Alarm zu schlagen. Heute hat jede Prüfung achtundvierzig Sekunden Zeit, danach gilt sie als gescheitert. Wer nie aufgibt, meldet auch nie einen Fehler.

Wenn das Messgerät abends ausgeschaltet ist, tut eine gute Automatik gar nichts, und genau das ist die richtige Antwort. Unser Achsmessstand wird jede Minute abgefragt; ist er aus, schreibt der Ablauf eine ruhige Zeile ins Protokoll und beendet sich, ohne den Stand der Dinge zu verändern. Am nächsten Morgen holt er die offenen Messungen binnen einer Minute nach. Nicht erreichbar ist kein Fehler, und wer beides gleich laut meldet, erzieht seine Leute dazu, Alarme zu überlesen.

Das Prüfgerät kann sehr wohl die Ursache sein, und dann sucht man tagelang am falschen Ende. Ich war überzeugt, unser WLAN filtere die Druckersuche weg, und habe am Gateway extra einen Dienst nachgerüstet, damit die Geräte wieder gefunden werden. Dann habe ich mit dem Diensthandy gegengeprüft: alle drei Drucker sofort da. Auf meinem Laptop liefen neun VPN-Tunnel, die jede Suchanfrage abfingen. Den nachgerüsteten Dienst habe ich wieder abgebaut. Wer misst, misst immer auch sein Messgerät.

Einen Fehler, der keinen Schaden anrichtet, behebt man trotzdem, sobald er regelmäßig im Protokoll steht. Unser Dokumentenarchiv Paperless startet jeden Morgen um sechs kurz neu, und unser Import-Programm klopfte im Fünf-Minuten-Takt genau in diese Lücke: jeden Tag rote Fehlermeldungen, nie ein echter Schaden. Jetzt fragt das Programm vorher kurz an, ob das Archiv erreichbar ist, und zieht sich sonst still bis zum nächsten Takt zurück. Ein Protokoll voller harmloser Fehler erzieht zum Überlesen, und irgendwann überliest man den einen, der zählt.

Fehler in einer neuen Software sollten wir zuerst bemerken, nicht die Mitarbeiter, die täglich damit arbeiten. Unser Dokumenten-System läuft seit gut einer Woche im Echtbetrieb, und die Kollegen fühlten sich in dieser Zeit wie Beta-Tester, weil sie Störungen vor uns fanden. Jetzt prüfe ich nach jeder Änderung selbst aus Mitarbeiter-Sicht, ob ein frischer Tresen-Scan sichtbar ankommt, und überwache die Fehlerordner, statt auf Meldungen zu warten. Die Akzeptanz einer neuen Software entscheidet sich nicht an ihren Funktionen, sondern daran, wer ihre Fehler zuerst findet.

Zwei laufende Exemplare eines wichtigen Programms reichen als Absicherung nicht, wenn beide im Gleichtakt altern. Unser Dokumentensystem Paperless hatte zwei Webserver-Prozesse als Reserve, doch beide starteten morgens zur selben Minute, verbrauchten gleich schnell Speicher und wurden deshalb fast gleichzeitig ausgetauscht. Genau in dieses Fenster fiel die Meldung vom Empfang, die Seite reagiere nicht. Seit drei Prozesse mit kleinerer Schwelle laufen, springt bei jedem Wechsel eine warme Reserve ein, die Seite antwortet in einer Drittelsekunde. Eine Reserve schützt nur, wenn sie nicht im selben Takt ausfällt wie das, was sie ersetzen soll.

Einen Fehler, der immer wiederkommt, behebt man nicht nur, man baut ihm einen Wächter. In unserer Dokumentenablage schlich sich derselbe Sichtbarkeits-Fehler seit Projektbeginn in jeden neuen Upload-Weg ein, zuletzt bei 132 Bildern, die nachts eingespielt wurden. Jetzt prüft eine kleine Routine alle fünf Minuten den Bestand und stellt falsche Zuordnungen von selbst richtig. Die Ursache beheben wir trotzdem jedes Mal, aber der Wächter fängt das nächste Vergessen ab. Gegen einen wiederkehrenden Fehler hilft keine Erinnerung, nur ein Mechanismus.

Ein Beleg im Fehlerordner ist erst gerettet, wenn dort auch regelmäßig jemand hineinsieht. Unsere Beleg-Automatik legt Dokumente, die sie nicht in die Ablage hochladen kann, sauber in einen Fehlerordner, damit nichts verloren geht. Genau dort lagen fünf Belege aus mehreren Tagen, still und unbemerkt, bis ich zufällig nachsah. Alle fünf habe ich am selben Abend nachträglich eingespeist, und als Nächstes bekommt der Ordner eine Überwachung, die meldet, sobald er nicht leer ist. Ein Auffangnetz, in das niemand schaut, ist nur ein zweiter Ort zum Verlieren.

Ein neuer Alarm kann einen alten Ausfall erklären, manchmal besser als jede Suche damals. Wir hatten unserem nächtlichen Sicherungsskript gerade erst einen Wächter in Uptime Kuma gegeben, und schon in der ersten Nacht schlug er an. Die Suche zeigte: Das Skript war seit rund elf Wochen still kaputt, seine Aufräum-Routine lief nie, der Backup-Ordner wuchs auf 208 GB, und genau diese volle Platte hatte Anfang Juli unsere ganze Cloud lahmgelegt. Ein Fehler ohne Alarm verschwindet nicht, er sammelt sich nur an.

Eine Sicherung, die auf demselben Rechner wie die Originaldaten liegt, ist noch keine echte Sicherung. Bei uns war das nächtliche Auslagern der Archive an einen zweiten Ort seit Mai still ausgefallen, ohne dass es jemand bemerkte, und so lagen die Kopien nur dort, wo auch das Original lag. Jetzt geht jede Nacht eine Kopie an einen Rechner an einem anderen Standort mit über achthundert Gigabyte Platz, und jeder Job meldet sich danach bei Uptime Kuma. Eine Kopie neben dem Original teilt im Ernstfall dessen Schicksal.

Dass ein Backup-Job seit Wochen nichts mehr sichert, merkt man nur, wenn er sich auch dann meldet, wenn er läuft, nicht bloß wenn er scheitert. Unser Forgejo-Backup-Skript war spurlos verschwunden, der nächtliche Auftrag lief ins Leere, und rund 2,9 GB Repositorien lagen wochenlang ungesichert, ohne dass es jemand bemerkte. Jetzt pusht jeder Job nach getaner Arbeit ein Signal an Uptime Kuma, bleibt es aus, klingelt es. Ein stiller Job sieht aus wie ein erledigter, bis man ihn braucht.

Ja, die eigene Datensicherung kann den ganzen Betrieb lahmlegen, wenn niemand prüft, ob sie sich auch selbst aufräumt. Bei uns lief die Aufräum-Automatik still aus: statt sieben Tage sammelten sich vierundfünfzig, 208 GB alte Sicherungen, bis die Platte zu hundert Prozent voll war und Docker keinen einzigen Container mehr starten konnte. Alles, was in der Hetzner-Cloud lief, war mit einem Schlag offline. Eine Sicherung, die niemand kontrolliert, wird irgendwann selbst die Gefahr, vor der sie schützen sollte.

Ein falscher Gesundheitscheck kann einen laufenden Dienst lahmlegen, und genau das ist mir passiert. Als ich eine alte Domain stilllegte, prüfte der Healthcheck plötzlich die falsche Seite, meldete den Container als krank, und Traefik nahm daraufhin alle drei gesunden Webseiten vom Netz, obwohl der Server intern weiter sauber auslieferte. Erst der Blick auf den Health-Status statt auf die Konfiguration brachte mich zur Ursache. Ein Test, der das Falsche prüft, ist gefährlicher als gar keiner, weil er Gesundes für krank erklärt.

Nur die Startseite zu überwachen reicht nicht, denn ein Haus kann eine offene Tür und trotzdem ein verschlossenes Zimmer haben. Bei einem unserer Auftritte lief die Startseite einwandfrei, doch das Impressum war über einen Routing-Fehler nicht erreichbar, also ausgerechnet eine Pflichtseite, deren Fehlen rechtlich teuer wird. Seitdem legt unsere Überwachung mit Uptime Kuma für jeden Auftritt auch eine Unterseite an, nicht nur die Homepage. Wer nur die Vordertür prüft, übersieht das kaputte Zimmer dahinter.

Eine Überwachung, die nur prüft ob ein Dienst läuft, übersieht den Dienst, der läuft und trotzdem nichts Frisches liefert. Bei einer Gesundheitsprüfung fiel mir auf, dass unsere nächtliche Kopie drei Tage alt war, während ein Cron alle drei Minuten per curl brav meldete, alles sei erreichbar. Die Datei war da, nur eben von vorgestern. Gesund heißt nicht, dass etwas atmet, sondern dass es das Richtige tut.

Ein Server, an dem niemand etwas geaendert hat, rebootet meist, weil etwas Vergessenes im Hintergrund Amok laeuft. Bei uns war es ein alter Entwicklungs-Dienst fuer Directus, der sein Arbeitsverzeichnis nicht mehr fand und sich deshalb neu startete, wieder und wieder, ueber fuenfundsiebzigtausend Mal. Das frass den Speicher, bis die Maschine von selbst neu startete. Im Log stand alles, man musste nur nachsehen. Ein abgeschalteter Dienst ist erst dann wirklich tot, wenn ihn niemand mehr neu startet.

Weil Docker und der Reverse Proxy so einen Endpunkt tausende Male am Tag abfragen. Bei mir hat ein Health-Check in einem Dienst bei jedem Aufruf eine kostenpflichtige Such-API (Tavily) angestoßen. In vierundzwanzig Stunden waren das über viertausend Aufrufe und rund zehn Euro, ohne dass die eigentliche Funktion ein einziges Mal lief. Seitdem prüft ein Health-Check bei mir nur lokal: Läuft der Prozess, antwortet er. Nichts, was Geld kostet oder nach außen telefoniert.

Nicht vom Kunden, wenn man es richtig macht. Wir überwachen die wichtigen Dienste durchgehend mit Uptime Kuma und bekommen eine Meldung, bevor jemand anruft. Was man nicht misst, bemerkt man erst, wenn der Schaden schon da ist. Stille Überwachung ist der Unterschied zwischen reagieren und überrascht werden.

Eine, die heimlich nicht mehr läuft. Ein nächtlicher Loco-Soft-Export sprang eine Weile nicht mehr an, und niemand merkte es, weil man sich darauf verließ. Manuell ausgelöst funktionierte er sofort. Seitdem prüfe ich aktiv, dass das Automatische wirklich automatisch passiert, statt es einfach anzunehmen.