## Monitoring des Monitorings: Strategien zur Vermeidung rekursiver Blindheit
Systemüberwachung erzeugt eine Illusion von Sicherheit: Wenn das Steuerungstool selbst ausfällt, zeigen Dashboards weiterhin veraltete Daten an und verschleiern echte Ausfälle. Dies ist kein hypothetisches Problem – reale Fälle mit Prometheus zeigen, wie leicht man kritische Vorfälle verpasst, wenn die Überwachung nicht mehr funktioniert. Die Lösung erfordert eine fehlertolerante Architektur, aber ohne unnötige Komplexität.
Warum das Monitoring-System zu einem Blindfleck wird
Wenn Prometheus oder ein ähnliches Tool nicht mehr funktioniert, sind die Konsequenzen katastrophal. In einem Fall war die Festplatte des Monitoring-Servers durch unbegrenzten Prometheus-Datenspeicher vollgelaufen. Im zweiten Fall hat kubelet den Prometheus-Pod aufgrund eines OOM-Fehlers getötet und Pod Disruption Budget war nicht konfiguriert. In beiden Szenarien blieben die Dashboards „grün“, da sie Daten von den letzten erfolgreichen Scrapes anzeigten. Alerts wurden nicht ausgelöst, da Alertmanager auf den nicht funktionierenden Prometheus angewiesen war.
Das zentrale Paradoxon: Monitoring kann sich selbst nicht überprüfen. Wenn das primäre Steuerungssystem ausfällt, gibt es keinen Mechanismus, um Alerts zu generieren. Dies ist kein abstraktes Problem – jedes Team, das fortschrittliche Observability implementiert, muss dieses rekursive Problem lösen. Bestehende Ansätze lassen sich in zwei Kategorien einteilen: theoretisch ideal (aber wirtschaftlich nicht gerechtfertigt) und praktisch umsetzbar (mit Kompromissen).
Architekturstrategien für fehlertolerante Steuerung
Unabhängige Ausfallbereiche – ein grundlegendes Prinzip. Ein Ausfallbereich umfasst Komponenten, die gemeinsam ausfallen (VPS, Kubernetes-Cluster, Cloud-Region). Der häufigste Fehler ist die Kolokation von Services und Monitoring auf demselben Server. Lösung:
- Separater physischer Server für Monitoring (reduziert das Risiko, eliminiert es aber nicht – das gemeinsame Rechenzentrum bleibt ein einziger Ausfallpunkt)
- Verteilung über verschiedene Clouds (Yandex Cloud + AWS), reduziert die Wahrscheinlichkeit eines simultanen Ausfalls auf 0,0001 % pro Monat
- Serverless-Architektur für kritische Checks (Check-Kette in Cloud Functions, unabhängig von der Hauptinfrastruktur)
Meta-Heartbeat implementiert einen einfachen Watchdog-Mechanismus:
- Der Monitoring-Scheduler aktualisiert alle Minute einen Timestamp in unabhängigem Storage (Redis, Datei)
- Eine separate Lambda-Funktion prüft alle 5 Minuten die Frische des Timestamps
- Bei Erkennung von Veraltung – ein Alert wird über einen alternativen Kanal versendet (SMS, separater Telegram-Bot)
Kritisch wichtig: Der Watchdog und der Benachrichtigungskanal dürfen nicht von denselben Komponenten abhängen wie das Hauptmonitoring. Sonst fügen Sie nur einen weiteren Ausfallpunkt hinzu.
Totmannschalter und Cross-Monitoring
Totmannschalter – eine Variante des Meta-Heartbeats mit externer Überprüfung. Ein Service wie Healthchecks.io oder PagerDuty erwartet regelmäßige Pings von Ihrem System. Bei Ausbleiben löst er einen Alert über einen Backup-Kanal aus:
[Monitoring system] --ping--> [External Dead Man's Switch]
|
(missed ping)
|
[Alert via SMS/PagerDuty]Dieser Ansatz schafft eine Abhängigkeit von einem Drittanbieter, aber die Wahrscheinlichkeit, dass Ihr Monitoring und der externe Service gleichzeitig ausfallen, ist vernachlässigbar. Bei mission-critical Systemen kommt Cross-Monitoring zum Einsatz: Zwei unabhängige Systeme überprüfen einander. Die Wartung zweier vollständiger Lösungen (z. B. Prometheus + Datadog) ist jedoch für die meisten Projekte wirtschaftlich nicht tragbar. Ein realistischeres Hybrid: Hauptmonitoring + primitiver Watchdog (Cron-Script auf einem separaten Server).
Praktische Grenze: Das „Gut genug“-Prinzip
Ausfallwahrscheinlichkeiten zeigen, dass zwei Unabhängigkeitsstufen der optimale Punkt für 99,9 % der Systeme sind:
- Ihr VPS fällt aus: ~0,1–1 % pro Monat
- Cloud nicht verfügbar: ~0,01 % pro Monat
- Zwei Clouds fallen gleichzeitig aus: ~0,0001 % pro Monat
- Drei Clouds: astrophysikalisches Ereignis-Niveau
Eine rationale Konfiguration umfasst:
- Hauptmonitoring in einem separaten Ausfallbereich (SaaS oder serverless)
- Totmannschalter in einem externen Service
- Backup-Benachrichtigungskanäle (Telegram + SMS)
Das dritte Schutzniveau rechtfertigt die Kosten nicht, angesichts der bereits minimalen Risikominderung. Wenn Hauptmonitoring, Totmannschalter und Telegram gleichzeitig ausfallen – stehen Sie vor Problemen, bei denen die Infrastruktursteuerung keine Priorität mehr hat (globaler Blackout, Atomkrieg).
Kritische Aspekte, die oft übersehen werden
Benachrichtigungskanäle als Ausfallbereich. Selbst bei funktionierendem Monitoring erreicht Sie ein Alert möglicherweise nicht wegen eines Slack- oder Telegram-Ausfalls. Lösung – Kanäle duplizieren: Kritische Alerts werden gleichzeitig per SMS und E-Mail versendet. Die Wahrscheinlichkeit, dass zwei Kanäle ausfallen, ist eine Größenordnung niedriger als bei einem.
Stateless vs. stateful Monitoring. Prometheus speichert die Metrik-Historie, daher gehen bei Ausfall die Daten für den Ausfallzeitraum verloren. Stateless-Checks („reagiert die URL?“) haben dieses Problem nicht: Sie starten sofort nach der Wiederherstellung wieder. Kombinieren Sie stateful-Systeme (Prometheus) mit stateless-Steuerung (externe Pings) – sie fallen unterschiedlich aus und decken verschiedene Szenarien ab.
Testen des Monitorings. Viele Teams richten das System ein, testen es aber nie unter realen Bedingungen. Führen Sie regelmäßig Game Days durch: Simulieren Sie absichtlich Ausfälle in der Staging-Umgebung und stellen Sie sicher, dass Alerts ausgelöst werden. Das ist günstiger, als nicht funktionierendes Monitoring während eines echten Vorfalls zu entdecken.
Wichtige Erkenntnisse
- Monitoring und überwachte Services in unabhängige Ausfallbereiche trennen (verschiedene Clouds, serverless)
- Totmannschalter mit separatem Benachrichtigungskanal implementieren (SMS/PagerDuty)
- Benachrichtigungskanäle für kritische Alerts duplizieren
- Das Steuerungssystem wie Code und Backups testen
- Für 99 % der Projekte reichen zwei Schutzebenen – die dritte ist unverhältnismäßig teuer
— Editorial Team
Noch keine Kommentare.