Alerting richtig gemacht: Von Alert Fatigue zu actionable Notifications
Zu viele Alerts sind genauso schlimm wie keine. Wir zeigen, wie Sie ein Alerting-System aufbauen, das nur dann feuert, wenn es wirklich wichtig ist.
Das Alert-Fatigue-Problem
Wenn Ihr On-Call-Engineer täglich 50 Alerts bekommt, von denen 48 False Positives sind, werden auch die echten zwei ignoriert. Alert Fatigue ist eines der größten Risiken für Systemzuverlässigkeit.
Prinzipien für gute Alerts
- Symptom-basiert: Alertieren Sie auf Symptome (hohe Error Rate, langsame Response Times), nicht auf Ursachen (hohe CPU). CPU bei 90% ohne Impact ist kein Alert.
- Actionable: Jeder Alert muss eine klare Handlungsanweisung haben. Wenn niemand etwas tun kann, ist es kein Alert, sondern ein Log-Eintrag.
- Severity-Levels: Unterscheiden Sie zwischen P1 (jetzt aufwachen) und P3 (morgen ansehen). Nicht alles ist ein Pager-Alert.
SLO-basiertes Alerting
Der modernste Ansatz: Definieren Sie Service Level Objectives (SLOs) und alertieren Sie, wenn das Error Budget aufgebraucht wird.
- Error Budget: Bei einem SLO von 99.9% haben Sie pro Monat ~43 Minuten Downtime-Budget.
- Burn Rate: Alertieren Sie, wenn das Budget schneller als erwartet verbraucht wird — nicht bei jedem einzelnen Fehler.
- Multiwindow: Kombination aus schnellem (5min) und langsamem (1h) Fenster reduziert False Positives drastisch.
Praxis-Tipps
Führen Sie regelmäßige Alert-Reviews durch. Löschen Sie Alerts, auf die niemand reagiert. Dokumentieren Sie Runbooks für jeden verbleibenden Alert. Und: Respektieren Sie die On-Call-Rotation — wer nicht geschlafen hat, macht Fehler.
Fragen zu diesem Thema?
Wir beraten Sie gerne zu den in diesem Artikel beschriebenen Technologien und Lösungen.
Kontakt aufnehmen
