Zum Inhalt springen
← Zurück zum Blog

Veröffentlicht am 9. September 2026 · 4 Min. Lesezeit

Mein Monitoring schweigt. Ich habe es so gebaut, dass das Schweigen etwas bedeutet

Mein Skript zur Backup-Kontrolle sagt normalerweise nichts. Es läuft, prüft ein paar Dutzend Dinge und beendet sich ohne ein Wort. Schweigen bedeutet: alles läuft.

Das ist bequem und zugleich die riskanteste Design-Entscheidung im ganzen Setup. Denn Schweigen hat genau zwei Ursachen: entweder gibt es wirklich nichts zu melden, oder die Kontrolle ist gar nicht gelaufen. Von außen sehen beide identisch aus.

Eine Kontrolle, die sich selbst kontrolliert

Deshalb prüft das Skript als Letztes sich selbst. Zwei Fragen: Sind die geplanten Aufgaben des Systems überhaupt geladen, und wann lief diese Kontrolle zuletzt. Wenn sie seit rund einem Tag nicht gelaufen ist, sagt das Skript es direkt — weil Schweigen in dieser Zeit nichts bedeutet hätte.

Die Schwelle liegt bei 48 Stunden. Darunter ist es meist nur ein Computer, der übers Wochenende ausgeschaltet ist, und ein Alarm über einen ausgeschalteten Computer lehrt einen, Alarme zu ignorieren.

Das ist die ganze Regel, und sie passt in einen Satz: Schweigen ist nur dann ein Beweis, wenn etwas bestätigt, dass das schweigende System lebt. Ohne das ist kein Alarm nicht von keinem Monitoring zu unterscheiden.

Was diese Kontrolle tatsächlich prüft

Backups: das Alter der Systemsicherung, die Auslastung des zugewiesenen Limits, der vom Backup-Mechanismus gemeldete Fehlercode, die Tiefe der Historie — denn eine verkürzte Kette bedeutet, dass die Sicherung von vorn begonnen hat und ältere Dateiversionen nicht mehr existieren. Dazu das Alter der Kaltsicherung und der externen Kopie.

Hardware: SMART-Status der Festplatten, freier Speicherplatz auf jedem Sicherungsziel, eine hängende Netzlaufwerk-Einbindung. Serverseitig: der Status jedes Speicherpools, abweichende Blöcke, freier Platz in den Pools, das Vorhandensein der richtigen Sicherungsdatei und die Größe des Netzwerk-Papierkorbs, in den beim Ausdünnen der Historie gelöschte Dateien wandern.

Die Schwellenwerte sind nicht der Optik wegen rund. 36 Stunden für die Systemsicherung sind der stündliche Zeitplan plus ein Puffer für eine Nacht ohne Netzwerk. 10 Tage für die wöchentliche Kaltsicherung ist bereits ein Verzug. 14 Tage für die externe Kopie sind eine Woche plus Puffer für eine Reise. 50 GB frei auf dem Ziel, weil Synchronisation mit Löschung Platz zum Schreiben braucht, bevor alte Dateien gelöscht werden.

Was ich bewusst nicht überwache

Das ist die wichtigere Hälfte der Liste, denn jede Benachrichtigung ohne Entscheidung dahinter lehrt einen, den Rest zu ignorieren.

Ich überwache weder Serverlast noch Speichernutzung, weder ob Temperaturen im Rahmen liegen noch Laufzeit ohne Neustart. Keine dieser Zahlen ändert eine einzige meiner Entscheidungen. Ich überwache auch nicht CPU, Grafik, Netzteile und RAM — nicht weil sie nicht ausfallen können, sondern weil sie kein Vorwarnsignal geben. Eine Festplatte kündigt einen Ausfall Monate im Voraus an, deshalb überwache ich sie. Der Rest funktioniert entweder oder nicht.

Keine meiner Maschinen hat fehlerkorrigierenden Speicher, also ist ein Speicherfehler unsichtbar, bis er einen Ausfall verursacht. Statt eine Messung vorzutäuschen, die ich nicht habe, zähle ich Systemabstürze in einem 14-Tage-Fenster und spontane Server-Neustarts. Ein Absturz ist eine Information, mehrere sind ein Alarm. Das ist das einzige Signal, das ich über Speicher, Stromversorgung und Kühlung habe — und ich benenne es genau als das, statt einen grünen Indikator zu zeigen, der auf nichts beruht.

Was ich nicht getan habe

Ich habe keine Erinnerung zu einem der Speicherpools hinzugefügt, der keine Redundanz hat. Es war verlockend, denn das Skript sieht diesen Zustand, und das Betriebssystem meldet diesen Pool als gesund — er ist als Spiegel aus einer einzigen Platte definiert. Er sieht gesund aus und ist es technisch auch.

Ich habe geprüft, was dort liegt: wiederherstellbare Daten. Ein Ausfall dieser Platte kostet Zeit, keinen Verlust. Statt einer monatlichen Warnung, die ich ohnehin ignorieren würde, steht die Entscheidung also in der Dokumentation, zusammen mit der Bedingung, die sie kippen würde: Sollte auf diesen Pool je etwas Unwiederbringliches gelangen, wird das Thema neu aufgerollt. Dokumentation erinnert sich besser als eine Benachrichtigung, die ich gelernt habe wegzuklicken.

Drei Dinge, die ich daraus mitnehme

Schweigen muss verdient sein. Ein System, das schweigt, hat die Pflicht zu beweisen, dass es lebt — sonst ist sein Schweigen wertlos.

Eine Liste nicht überwachter Dinge ist Teil des Monitorings. Aufgeschrieben und begründet, hört sie auf, ein Versehen zu sein, und wird zu einer Entscheidung, zu der man zurückkehren kann.

Ein Alarm ohne Entscheidung dahinter ist ein Schaden, kein Gewinn. Bevor du eine Kontrolle hinzufügst, beantworte, was du tatsächlich tust, wenn sie anschlägt. Lautet die Antwort „nichts", hast du gerade alle anderen Alarme geschwächt.


Die oben beschriebenen Schwellenwerte, Zahlen und Entscheidungen stammen aus einer Konfiguration, die am 16. August 2026 auf meiner eigenen Heimhardware gemessen und geordnet wurde.

Patryk Piecyk

Patryk Piecyk

Warschau · Junior-Implementierungsberater · ab sofort verfügbar

Siebeneinhalb Jahre habe ich in einem deutschen Unternehmen gearbeitet, fünf davon habe ich sein Büro geführt: Aufträge, Rechnungen, Reklamationen, ERP. Seit Juni 2026 baue ich eigene Werkzeuge für genau diese Arbeit — ich bin kein gelernter Programmierer; der Code entsteht gemeinsam mit einem KI-Assistenten, Entwurf, Entscheidungen und Tests sind meine. Diese Notizen beschreiben, was in diesen Systemen kaputtging und was dabei herauskam.

Eine Frage zu diesem Text?

Schreiben Sie mir →