Jeder Alert sollte handlungsrelevant sein. Wenn nicht, ist es Rauschen.
Regel Nr. 1: Alerting auf Symptome, nicht Ursachen¶
Alert bei „CPU > 90%” ist Rauschen. Alert bei „5xx Error Rate > 1%” ist ein Symptom, das Benutzer betrifft.
Severity-Stufen¶
- Critical — Benutzer sind JETZT betroffen → On-Call wecken
- Warning — wird bald ein Problem → während der Arbeitszeit beheben
- Info — Zur Kenntnisnahme → nur Log/Dashboard
Was überwachen¶
- Error Rate (5xx)
- Latenz (P95, P99)
- Auslastung (CPU, Speicher, Festplatte)
- Queue Depth
- Zertifikatsablauf
- Festplattenplatz
Anti-Patterns¶
- Zu empfindliche Schwellenwerte → Alert Fatigue
- Alerting auf Dinge, die sich selbst heilen
- Kein Runbook → niemand weiß, was zu tun ist
- Doppelte Alerts
Runbook-Vorlage¶
Alert: HighErrorRate¶
Severity: Critical Bedeutung: 5xx Error Rate > 1% über 5 Minuten Auswirkung: Benutzer sehen Fehler Schritte: 1. Deployment-Historie prüfen 2. Logs ansehen 3. Rollback bei kürzlichem Deploy 4. Eskalation an #oncall
Zusammenfassung¶
Weniger Alerts = mehr Aufmerksamkeit. Jeder Alert muss ein Runbook und eine klare Handlung haben.
alertingmonitoringsre