Wer überwacht die Überwachung?

Ein Monitoring, das ausfällt, meldet seinen eigenen Ausfall nicht. Das ist banal, aber es ist der Grund für eine eigene Maschine bei Hetzner in Falkenstein, die nichts anderes tut, als die Überwachung zu überwachen.

Der Grundaufbau

Seit dem 19. August 2026 läuft Icinga 2 neu: ein Master auf icinga00, ein Agent auf jeder Maschine, alles aus einem eigenen Puppet-Modul. Jede Prüfung ist eine eigene Klasse, die in Foreman einem Host oder einer Gruppe zugewiesen wird; die Objekte sammelt der Master über PuppetDB ein und räumt verwaiste von selbst ab. Über fünfzig solcher Klassen sind es inzwischen, jede mit einer Handlungsanweisung direkt am Alarm.

Benachrichtigt wird gestaffelt: Platte voll oder Dateisystem nur noch lesbar rund um die Uhr, ein hängender Puppet-Lauf oder eine ausgebliebene Sicherung tagsüber auch am Wochenende, Kleinigkeiten nur an Werktagen per Mail. Damit die Werktage stimmen, prüft eine eigene Prüfung, ob die beweglichen Feiertage in Baden-Württemberg für das laufende Jahr eingetragen sind — gerechnet mit der Gaußschen Osterformel.

Messwerte schreibt Telegraf alle 30 Sekunden nach InfluxDB, Grafana stellt sie dar. Alle Dashboards folgen seit dem 25. August demselben Muster: oben eine Reihe Kacheln mit dem Stand jetzt, darunter der Verlauf. Protokolle sammelt seit dem 27. August Loki auf einer eigenen Maschine, Alloy liefert sie von jedem Host. Die Etiketten sind bewusst auf vier begrenzt — jedes weitere vervielfacht die Zahl der Zeitreihen. Herkunftsland und Netz eines Zugriffs auf die Firewall stehen deshalb als Metadaten am Eintrag, nicht als Etikett.

Der Wächter

Seit dem 8. September läuft watch00 in Falkenstein: ein eigenständiges Icinga mit eigener CA, ohne Verbindung zum Konfigurationsbaum des Masters. Der Master schickt ihm in festen Abständen ein Lebenszeichen über die API. Bleibt es aus, wird der Wächter nach Ablauf des Zeitfensters von selbst rot — ein Dead Man's Switch. Zusätzlich fragt der Wächter den Status des Masters ab, mit einem Zugang, der nur lesen darf.

Wozu, zeigt ein Fall, den das Monitoring selbst nicht erkennen kann: Fällt die Datenbank hinter der Weboberfläche aus, zeigt die Oberfläche weiter den letzten Stand. Alles grün, nur eben eingefroren.

Alarme laufen über easyNag aufs Telefon, vom Master wie vom Wächter. Dass beide denselben Weg nutzen, ist eine bewusst offene Lücke: Fällt easyNag aus, schweigen beide. Pushover ist seit dem 2. September abgeschaltet.

Drei Prüfungen, die logen

SMART: die Platte, die nie kaputt gewesen wäre. Die SMART-Werte prüfte zunächst ein eigenes Skript. Darin stand ein regulärer Ausdruck mit (?!OK) — ein Negative Lookahead, den POSIX ERE nicht kennt. Eine SAS-Platte mit Status FAILED wäre damit als gesund durchgegangen. Seit dem 2. September läuft stattdessen das fertige Plugin aus dem Debian-Paket, eine Prüfung je Platte statt einer für alle. Eine SSD im Host steht seitdem bei 27 CRC-Fehlern — ein Problem der Übertragungsstrecke, nicht der Platte. Ihr Wert ist seit Wochen stabil; der Schwellwert für genau diese Platte liegt jetzt bei 30, für alle anderen nicht.

DNSSEC: der Schlüssel, der nicht fehlte. Eine Prüfung vergleicht seit dem 7. September den DS-Eintrag bei der Registry mit dem Schlüssel der Zone — sie soll merken, wenn ein Schlüsselwechsel nicht nachgezogen wurde. Am 29. September meldete sie für zwei Zonen kein KSK. Die Ursache war ein öffentlicher Resolver, der die vielen Anfragen drosselte; die Prüfung lief 101 Sekunden und wurde nach 60 abgebrochen. Seitdem prüft sie den Rückgabewert der Abfrage, unterscheidet SERVFAIL von einer leeren Antwort, hat eine eigene Frist unterhalb des Timeouts und fragt auf den Nameservern die eigenen autoritativen Server statt eines fremden Resolvers.

Zertifikate: alle auf einmal. Die Inventur am 21. August ergab, dass die CA von Puppet bis 2125 läuft — die Zertifikate der Agents aber gehäuft im Herbst 2030 und Sommer 2031 ablaufen, weil die Lebensdauer nie gesetzt war und der Vorgabewert von fünf Jahren galt. Bis dahin ist Zeit, aber eine Prüfung der Zertifikatsdateien und ein dokumentiertes Verfahren zur Neuausstellung gibt es schon jetzt: erst das Serverzertifikat, dann die Agents.

Was sonst dazukam

• Ereignisprotokoll des Servers (IPMI). Am 10. September stand dort ein kurzer Ausfall eines Netzteils, nach vier Minuten wieder in Ordnung. Niemand hätte es bemerkt. Jetzt meldet jede neue Zeile.
• Neustarts von Diensten. Ein Dienst, den systemd still neu startet, ist kein gesunder Dienst. Gezählt wird über NRestarts und den Startzeitpunkt.
• PHP-FPM. Eine Prüfung rechnet aus, ob alle FPM-Prozesse im Ernstfall mehr Speicher bräuchten, als die Maschine hat.
• Rücksicherung. Ein Test stellt regelmäßig eine Datei aus der Sicherung wieder her — dazu mehr in der Notiz über die Datensicherung.

Was ich daraus mitnehme

Eine Prüfung ist Code und hat Fehler wie jeder andere Code. Die gefährlichen sind nicht die, die zu oft rot werden — die bemerkt man. Gefährlich sind die, die grün bleiben, wenn sie es nicht dürften.