#Monitoring

Eine Backup-Warnung muss kommen, bevor die Sicherung startet, nicht erst am Morgen danach. Unsere nächtliche Loco-Soft-Sicherung bleibt hängen, sobald abends noch an einem Arbeitsplatz eine Sitzung eingetragen ist. Deshalb prüft ein kleiner Wächter genau das um 20:45 und schickt eine Mail. Am 16. Oktober kam sie, um 20:54 war die verwaiste Sitzung gelöscht, und um 21:00 lief die Sicherung durch, 174 Megabyte. Ein Alarm nach dem Schaden ist ein Protokoll, ein Alarm davor ist ein Werkzeug.

Eine Sicherungsplatte ist nicht automatisch gesund, nur weil die Sicherung jede Nacht Erfolg meldet. Unsere Windows-Sicherung meldete genau das, obwohl Windows die Platte seit Mitte September als reparaturbedürftig markiert hatte. Eine Prüfung von zwei Minuten hat das Dateisystem repariert, und alle 94 Sicherungsstände blieben erhalten. Seitdem prüft unsere Morgenmail neben dem Erfolg auch den Zustand der Platte. Eine Sicherung, die geschrieben wurde, ist noch keine, die sich lesen lässt.

Wie viele Datensicherungen in unserem Betrieb laufen, wusste ich selbst nicht genau, am Ende waren es vier. Drei fanden wir bei der Bestandsaufnahme sofort, die vierte, die Loco-Soft nachts selbst anstößt, erst knapp zwei Wochen später. Ausgerechnet sie war ausgefallen, während zwei andere Stränge grün meldeten. Seit heute stehen alle vier in einer einzigen Morgenmail. Grün heißt nur, dass das Geprüfte läuft, nicht dass alles geprüft ist.

Unsere nächtliche Loco-Soft-Sicherung blieb hängen, weil das Programm einen Arbeitsplatz noch für angemeldet hielt, der längst weg war. Ein Laptop hatte am 25. September eine verwaiste Sitzung hinterlassen, und die Sicherung wartete siebzehn Nächte lang auf eine Dateisperre, ohne dass ein Alarm kam. Unsere Diagnose-Werkzeuge suchten nach offenen Dateien und fanden nichts, denn diese Datei war nicht geöffnet, sie lag nur da. Heute prüft ein kleiner Wächter jeden Abend vor der Sicherung, ob alte Sitzungen herumliegen. Um zu sperren, muss niemand etwas festhalten, ein vergessener Zettel genügt.

Wenn im gespiegelten Server eine Festplatte ausfällt, merkt man es im Alltag nicht, denn genau dafür ist die Spiegelung gebaut: alles läuft weiter. Ich habe erst an diesem Sonntag im Ereignisprotokoll unseres Fujitsu-Servers gelesen, dass schon im August 2025 eine Platte ausgefallen war, und eine der Warnadressen gehörte noch dem früheren IT-Betreuer. Seitdem prüft ein eigener Wächter die Hardware alle fünf Minuten und meldet sich in Uptime Kuma. Redundanz kauft nur Zeit, wenn jemand merkt, dass die Uhr läuft.

Ob ein schwaches WLAN-Signal am Standort liegt, weiß man erst, wenn man ausrechnet, wie stark es dort sein müsste. Bei einem Shelly-Schalter im Showroom hat unsere KI den schwachen Pegel als Standortproblem abgetan, vermutlich ein Metallverteiler. Die Dose war aber aus Plastik und hatte zehn Meter freie Sicht zum Access Point. Nachgerechnet fehlten gut zwanzig Dezibel, also rund das Hundertfache an Leistung, und in der Sichtachse stand ein E-Roller. Ein Messwert ohne Sollwert ist eine Zahl, noch kein Befund.

Einen Dienst, über den man selbst verbunden ist, schaltet man aus der Ferne nur mit einem vorher eingeplanten Rückweg ab. Ich wollte abends prüfen, ob Uptime Kuma den Ausfall unseres Fernzugangs meldet, und habe dafür den VPN-Dienst auf einem kleinen Rechner im Keller gestoppt. Nur lief meine eigene Verbindung genau über diesen Dienst, und von selbst startete er nicht wieder. Seitdem stelle ich vor so einem Test einen Zeitschalter, der den Dienst nach sechs Minuten wieder hochfährt. Wer an dem Ast sägt, auf dem er sitzt, stellt vorher die Leiter hin.

Die Nachtsicherung fällt aus, wenn abends ein Arbeitsplatz offen bleibt, und das passiert ganz still. Unser Werkstatt-Programm Loco-Soft sichert seine Daten nachts selbst. Ist aber noch ein Rechner angemeldet, wartet es endlos darauf, dass die Datei freigegeben wird, und meldet keinen Fehler. So fehlten in knapp vier Wochen neun Nächte, während unsere beiden anderen Sicherungen die ganze Zeit grün meldeten. Seit heute prüft ein kleiner Wächter jeden Morgen, ob eine frische Sicherungsdatei da ist. Grün heißt nur, dass alles in Ordnung ist, was man auch wirklich prüft.

Funktionierende Software baue ich nicht um, nur damit sie ordentlicher aussieht. Das tue ich erst, wenn ein konkreter Schaden es verlangt. Der teuerste Fehler in unserem Dokumentenarchiv hatte mit der Struktur gar nichts zu tun: Die Anweisung an das lokale Modell über Ollama war neunmal größer, als das Modell überhaupt lesen konnte, und statt 78 Prozent der Felder kamen nur 3 Prozent richtig heraus. Das lief monatelang so, weil nichts hinsah. Zehn Zeilen Wächter hätten es am ersten Tag gezeigt, ein schöner Umbau dagegen nie.

Eine unauffällige Nachmessung widerlegt die Störungsmeldung eines Kollegen nicht. Als bei uns wieder über Aussetzer beim Telefonieren geklagt wurde, zeigte meine Messung zwanzig Minuten später eine völlig ruhige Leitung. Das Protokoll unseres Dauermonitors sagte etwas anderes: fünfzehn Störungsphasen zwischen Viertel vor acht und elf Uhr, Schwankungen bis 58 Millisekunden. Solche Fehler kommen und gehen in Minuten, wie ein sporadischer Fehler, der bei der Probefahrt nie auftritt. Wer nur im Moment misst, gibt am Ende dem Falschen recht.

Ein Neustart des Rekorders hilft nicht, wenn alle Kameras gleichzeitig schwarz sind, denn dann fehlt meist der Strom, nicht die Software. Unsere Kameras bekommen ihren Strom über das Netzwerkkabel vom Rekorder, und das Protokoll zeigte eine Störung genau dieser Versorgung, vermutlich ein Kurzschluss an einem einzigen Kanal. Sechs Tage lang hat es niemand bemerkt. Erst als ich alle Kabel abgezogen und wieder eingesteckt habe, kam das Bild zurück. Fällt alles auf einmal aus, sucht man das, was alle gemeinsam haben.

Einen kurzen Leitungsabriss meldet eine Überwachung nie, wenn sie nur einen Zustand prüft und kein Ereignis festhält. Unser Uptime Kuma schlägt bei der Telefonie erst an, wenn zwei Prüfungen in Folge ausbleiben. So haben wir es eingestellt, nachdem ein zu knapper Takt an einem einzigen Tag neunundvierzig Fehlalarme ausgelöst hatte. Eine Leitung, die sich für zwei, drei Minuten neu synchronisiert, ist aber wieder da, bevor die zweite Prüfung kommt. Jetzt meldet der Sender einen erkannten Abriss fünf Minuten lang weiter als Störung. Wer nur den Zustand abfragt, verpasst jedes Ereignis, das kürzer ist als der Abstand zwischen zwei Prüfungen.

Eine Überwachungskamera, die einen Passwortfehler meldet, ist nicht kaputt, sie lebt und antwortet nur mit dem falschen Schlüssel. Bei uns galt eine Kamera am Rekorder monatelang als defekt, niemand hat genauer hingesehen. Als ich die Statusmeldung des Rekorders direkt abgefragt habe, stand dort kein Ausfall, sondern ein Anmeldefehler. Eine Neueinrichtung hat sie in wenigen Minuten zurückgeholt. Wer eine Fehlermeldung schickt, ist noch da, man muss sie nur zu Ende lesen.

Mein Testalarm schlug nicht an, weil die echte Meldequelle noch lief und ihn überholte. Ich wollte in Uptime Kuma prüfen, ob die Störmeldung unserer Telefonie wirklich ankommt, und schickte künstliche Fehler hinein. Der laufende Prüfdienst meldete im nächsten Takt Entwarnung, bevor die Überwachung den Fehler überhaupt bestätigt hatte. Erst nachdem ich ihn angehalten und dreimal im Abstand von zwölf Sekunden eine Störung gemeldet hatte, ging die Mail raus. Wer einen Alarm testet, während der Normalbetrieb weiterredet, prüft nur, wer lauter ist.

Solange das Signal schwach bleibt, sollte man ein Gerät nicht daran hindern, sich ständig neu ins WLAN einzuwählen. Einer unserer Schaltaktoren warf sich bei schlechtem Empfang jede Minute selbst aus dem Netz, 81-mal in vierzehn Tagen. Ich habe die Schwelle gelockert, und der erste Test sah glänzend aus: Der Paketverlust fiel von zehn auf ein Prozent. Zwanzig Minuten später hing das Gerät fünfundzwanzig Minuten lang an einer toten Verbindung, weil ihm seine einzige Selbstheilung fehlte. Wer nur das Symptom abstellt, tauscht oft viele kurze Ausfälle gegen einen langen.

Ein Gerät, das sich ständig neu mit dem WLAN verbindet, sollte man nicht daran hindern, solange sein Signal schwach bleibt. Ein Shelly-Schaltmodul bei uns hatte sich in vierzehn Tagen 81 Mal ab- und wieder angemeldet. Also habe ich seine Roaming-Schwelle geändert, und der erste Test sah glänzend aus: Der Paketverlust fiel von zehn auf ein Prozent. Kurz darauf hing es 25 Minuten an einer toten Verbindung fest, obwohl der Access Point es als verbunden anzeigte. Ich habe die Werkseinstellung zurückgesetzt. Wer nur das Symptom abstellt, tauscht viele kurze Ausfälle gegen einen langen.

Nach der Lehrbuchregel 1, 6 und 11 sollte man WLAN-Kanäle nicht blind einstellen, erst wird gemessen. Ich habe bei uns zwei Zugangspunkte auf die Regel umgestellt, weil ihre Kanäle 8 und 3 wie ein Versehen aussahen. Danach stieg die Funkauslastung von sechzehn auf dreiunddreißig Prozent. Im Gewerbegebiet funken alle Nachbarn auf 1, 6 und 11: Auf Kanal 6 hörte ein Gerät 36 fremde Netze, auf Kanal 8 nur eines. Mein Vorgänger hatte recht, und ich habe seine Einstellung zurückgeholt. Was krumm aussieht, ist manchmal das Ergebnis einer Messung, die man nicht kennt.

Der Qualitätsnote im WLAN-Controller kann man nur trauen, wenn man weiß, was sie wirklich misst. Bei uns sprang ein Funk-Zugangspunkt im UniFi-Controller von 66 auf 99 Punkte, also von schlecht auf exzellent, während seine eigene Funkanbindung von rund 770 auf gut 100 Megabit einbrach. Der Grund: Ein einziges schwaches Gerät hatte sich abgemeldet, und die Note bewertet nur die angemeldeten Geräte, nicht die Zuleitung. Seitdem lese ich bei solchen Anzeigen die Rohwerte. Eine gute Note beantwortet die Frage, die gemessen wurde, nicht unbedingt die, die man gestellt hat.

Hunderte blockierte Verbindungen im Gäste-WLAN sind nicht automatisch ein Angriff. Bei uns hat ein einziger Gast-Laptop 314 abgewiesene Verbindungsversuche erzeugt, und im Protokoll sah das zunächst bedrohlich aus. Dann habe ich mir die Ziele angesehen: Das Gerät suchte nur seinen Drucker und seine Netzlaufwerke von zu Hause, die es bei uns natürlich nicht fand. Die Firewall hat getan, was sie soll. Eine Zahl sagt nur, dass etwas passiert, erst das Ziel sagt, was.

Eine schnellere Internetleitung hilft nicht, wenn die vorhandene gar nicht ausgelastet ist. Unsere Leitung schafft laut Fritz!Box gut achtundsechzig Megabit im Download. Wir nutzen im Tagesschnitt zwei bis drei davon, am stärksten Tag gut neun. Die Aussetzer kamen trotzdem, und die Messung verortete sie außerhalb unseres Hauses. Ein teurerer Tarif hätte Geld gekostet und nichts geändert. Eine breitere Straße hilft nicht, wenn die Schlaglöcher bleiben.

Beim Videoanruf geht der Ton, aber das Bild bricht ab, wenn die Leitung zwar nichts verliert, aber sehr ungleichmäßig liefert. Unsere Messung zeigte an diesem Tag null Prozent Paketverlust, dafür Schwankungen der Laufzeit bis vierundvierzig Millisekunden. Die Ursache lag außerhalb unseres Hauses, nicht im WLAN. Für Sprache reichen rund dreißig Kilobit, und ein kleiner Puffer gleicht die Schwankungen aus. Video braucht gleichmäßig etwa ein Megabit, also schaltet der Sender das Bild ab. Eine Leitung kann schnell genug sein und trotzdem zu unruhig.

Eine Klimaanlage braucht ein Serverschrank im Keller nicht von Anfang an, das entscheidet erst die Messung. Bei unserer Serverablösung zieht der alte große Server in ein anderes Gebäude. Im Keller bleibt dann kaum ein halbes Kilowatt Abwärme. Ein belüfteter Schrank kostet rund 1.100 bis 4.100 Euro, die Variante mit Kühlung 4.600 bis 7.200 Euro. Also kommt zuerst der belüftete Schrank, über den Sommer messen wir Temperatur und Feuchte, und gekühlt wird nur, wenn die Kurve es verlangt. Nachrüsten kostet weniger als eine Kühlung, die man nie gebraucht hätte.

Ob ein abgebrochenes Telefonat an der Telefonanlage oder an der Internetleitung liegt, zeigt die einfachste Probe: Bricht auch ein internes Gespräch ab, sind es die Anlage oder das Endgerät. Reißen nur Gespräche nach draußen ab, ist es die Leitung. Bei uns hat eine Woche Messung beides zugleich gezeigt. Auf der Leitung gab es 915 Störungen, daneben zehn kurze Aussetzer der Anlage selbst, während die Leitung sauber war. Wer nur nach einer Ursache sucht, findet auch nur eine.

Die Backup-Berichte las bei uns nach dem Wechsel immer noch der frühere IT-Betreuer, jeden Tag, nur wir selbst nicht. Aufgefallen ist das, weil jemand sagte, wir bekämen keine Backup-Mail mehr. Bei der Bestandsaufnahme fand ich drei getrennte Sicherungsstränge, einer davon stand seit dem 8. August still, und den Hauptzugang zur Sicherungsmaschine hat bis heute nur er. Wer den Betreuer wechselt, übergibt nicht nur die Schlüssel, sondern auch die Frage, wem die Maschinen Bescheid sagen.

Die Berichtsmails des eigenen Servers kommen nicht an, weil der Empfänger sie zwar annimmt und danach still aussortiert. In einem Betrieb hieß es seit Wochen, es komme keine Sicherungs-Mail mehr. Der Postfix auf dem Gateway hat jeden Abend zugestellt, Microsoft 365 quittierte täglich mit einem sauberen 250, doch der Absender war im SPF-Eintrag der Domain nicht erlaubt. Die Berichte lagen in der Quarantäne. Angenommen ist nicht dasselbe wie gelesen.

Eine Vermutung reicht nicht, man braucht eine Messung, die Zeitpunkt und Ausmaß festhält. Unser Internet war seit Mitte Juli immer wieder zäh, aber einundfünfzig Tage lang hat niemand gemessen, weil das alte Prüfskript keine echte Systemd-Unit war und nach sechs Stunden von selbst ausstieg. Seit es als Dienst mit Neustart-Garantie läuft und alle zehn Sekunden Verlust, Latenz und Jitter mitschreibt, standen nach anderthalb Stunden sechs belegte Störungen im Protokoll, darunter zehn Prozent Paketverlust. Wer nicht misst, verhandelt mit Gefühlen.

Eine unveränderte Antwortzeit beweist nicht, dass die Maßnahme nichts gebracht hat, sondern oft nur, dass man das Falsche gemessen hat. Nach dem Umbau des Funknetzes für unser Werkstatt-Telefon lag die Ping-Zeit vorher bei 169 und nachher bei 174 Millisekunden, also praktisch gleich. Ein Ping läuft aber als gewöhnlicher Verkehr, während das Gespräch bevorzugt behandelt wird; die Verbesserung konnte in dieser Zahl gar nicht auftauchen. Belastbar war erst der Testanruf beim Gang über den Platz. Eine ehrliche Zahl zur falschen Frage bleibt eine falsche Antwort.

Die Beschwerden hören nicht auf, weil es oft zwei Ursachen gleichzeitig sind und man nur eine davon behoben hat. Ich hatte unsere Telefonprobleme dem WLAN am Arbeitsplatz zugeschrieben und die Leitung freigesprochen. Dann maß der neue Monitor auf der DSL-Strecke dreiundneunzig Millisekunden Latenz bei fast fünfundzwanzig Millisekunden Jitter, während Fritzbox und Telefonanlage sauber blieben. Es war beides. Wer bei der ersten plausiblen Ursache aufhört, repariert die Hälfte und wundert sich über den Rest.

Eine Domain kann offline sein, obwohl der Server einwandfrei läuft. Bei einer unserer Domains zeigte der Delegationseintrag bei Hetzner auf drei Namensserver, die diese Domain gar nicht kannten, und jede Anfrage von außen lief ins Leere. Der Webserver war gesund, die Seite fertig ausgeliefert, nur fand kein Besucher den Weg dorthin. Aufgefallen ist es erst zwei Monate später, als ich alle Domains einzeln von außen durchprüfte. Ein gesunder Server sagt nichts darüber, ob jemand bei ihm ankommt.

Ein geplanter Ausfall steht nicht auf der Störungsseite, weil er dort gar nicht als Störung geführt wird, sondern unter angekündigter Wartung. Hetzner hatte die Arbeiten an einem Netzwerkverteiler im Rechenzentrum für eine Stunde angekündigt, samt Anweisung, die angehängten Speicher vorher abzutrennen. Die Mail lag ungelesen, und vier Minuten nach Beginn des Fensters standen unsere Seiten. Eine Ankündigung, die niemand liest, ist für den Betrieb dasselbe wie keine.

Eine Website kann monatelang offline sein, obwohl der Server einwandfrei läuft, wenn der Weg zu ihm abgeschnitten ist. Ende Juni habe ich bei Hetzner die Namensauflösung für fünf unserer Domains umgestellt und eine davon vergessen. Ab da war diese Website für jeden Besucher unerreichbar, während der Server fehlerfrei lief. Aufgefallen ist es erst nach gut zwei Monaten. Seitdem gleiche ich jede Sammel-Umstellung mit der vollständigen Liste ab und prüfe von außen, nicht vom Server aus. Wer nur von innen schaut, sieht immer ein gesundes Haus.

Einen einmal gescheiterten Vorgang darf eine Automatik nie für immer überspringen. Unser Import ins Dokumentenarchiv merkte sich jede Rechnung, die er schon angefasst hatte, unabhängig davon, ob sie angekommen oder gescheitert war. Als der Archivdienst wegen Speichermangels ein paar Tage streikte, fehlten am Ende 44 Rechnungen aus zwei Monaten, ohne dass jemand etwas bemerkte. Ein Aussetzer von Stunden wird so zu einem Verlust von Monaten.

Als Dauerüberwachung taugt ein Diagnose-Skript nicht, solange ein Ende fest eingebaut ist. Ich wollte eine sporadische Internet-Störung mitschneiden und hatte dafür eine Schleife laufen, 2160 Durchläufe alle zehn Sekunden, also genau sechs Stunden. Als ich einen Monat später ins Protokoll sah, endete es mit der Zeile Monitor Ende, nachmittags am ersten Tag, und lag im Zwischenspeicher, den jeder Neustart leert. Ein Wächter, der sich unbemerkt verabschiedet, ist schlimmer als gar keiner, weil man sich auf ihn verlässt.

Unser Dateiserver meldete sich nie, weil seine Warnmails an einen Mailserver gingen, den es auf dieser Maschine gar nicht gab. Fünfzehn Monate lang lief unsere Nextcloud so, und in dieser Zeit hat der Speicheranbieter 634 Zugriffe gedrosselt, ohne dass ein Mensch je davon erfuhr. Erst nach der Umstellung auf unser echtes Postfach kamen die ersten Meldungen an. Ein Alarm, den niemand empfängt, ist kein Alarm, sondern nur eine Zeile im Protokoll.

Ein Diagnose-Schalter, den man nach der Reparatur anlässt, wird irgendwann selbst zum Fehler. Auf einem unserer WordPress-Server stand die ausführliche Fehlerprotokollierung seit Monaten auf an, im Produktivbetrieb. Die Protokolldatei war auf 1,96 Gigabyte gewachsen und der Datenträger zu sechsundachtzig Prozent voll. Bevor ich sie geleert habe, habe ich ihr Ende gelesen, denn genau dort stand die Ursache des Ausfalls. Was man zum Suchen anschaltet, gehört nach dem Finden wieder ausgeschaltet.

Ein Protokoll, das jede Minute dieselbe Zeile schreibt, muss man ausdünnen, sonst versteckt es den einen Satz, der zählt. Die Protokolldatei unserer Achsmess-Automatik war auf 4,4 Megabyte und 34.616 Zeilen gewachsen, fast nur Meldungen, dass das Gerät gerade ausgeschaltet ist. Die Hälfte stand sogar doppelt drin, weil zwei Wege in dieselbe Datei schrieben. Jetzt rotiert die Datei täglich, wird nach vierzehn Tagen weggeworfen, und die Doppelung ist raus. Ein Protokoll nützt erst, wenn die Abweichung darin auffällt.

Wie oft eine Überwachung nachsehen muss, entscheidet sich daran, wann der Kunde die Störung merkt. Bei uns stand ein Monitor in Uptime Kuma auf dreihundert Sekunden, also fünf Minuten zwischen zwei Prüfungen. Jeder Ausfall, der kürzer war, blieb für das System unsichtbar, und ich habe die Störung vor dem Monitoring bemerkt. Seitdem laufen Kundenseiten auf sechzig Sekunden. Eine Überwachung, die langsamer schaut als der Kunde klickt, meldet nur noch, was ohnehin schon alle wissen.

Die Warnmails der eigenen Server landen in der Quarantäne, wenn sie ohne digitale Signatur verschickt werden. Aus den Berichten unseres Mailservers ging hervor, dass 125 von 222 Systemmails eines Verwaltungsrechners beim Empfänger aussortiert wurden, still, ohne dass bei mir eine Fehlermeldung ankam. Betroffen war genau der Kanal, über den sich abgelaufene Zertifikate und fehlgeschlagene Sicherungen melden. Eine Warnung, die niemanden erreicht, ist keine Warnung, sondern nur eine Zeile in einem Protokoll, das keiner liest.

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.

Dem Anbieter zeigt man das, indem man vorher die eigene Seite lückenlos ausmisst. Bei uns luden Seiten tagelang mal sofort, mal gar nicht, und ein Neustart der Fritzbox half nichts. Bevor ich zum Hörer griff, habe ich das Haus durchgemessen: keine Last am Gateway, null Übertragungsfehler nach außen, gut tausend offene Verbindungen von fünfundsechzigtausend möglichen, Namensauflösung überall sauber, kein verlorenes Paket bei knapp neun Millisekunden. Erst so ein Bündel macht aus einem Gefühl eine Meldung, die jemand ernst nehmen muss.

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.