Schwellenwerte, Alerting und Eskalation

Monitoring sammelt Daten – Alerting macht sie nutzbar. Eine Disk-Füllstand-Metrik alleine bewirkt nichts; sie wird erst zum Werkzeug, wenn sie bei 90 % jemanden alarmiert, der dann auch reagiert. Dahinter steckt mehr Tücke als es klingt: zu niedrige Schwellen erzeugen ständige Fehlalarme („alert fatigue") – die echten Probleme gehen im Rauschen unter. Zu hohe Schwellen merken nichts, bis es zu spät ist. Schlecht eingerichtete Eskalation sorgt dafür, dass nachts der falsche Mensch geweckt wird. In dieser Lektion klärst du, wie man Schwellen sinnvoll setzt, was Hysterese gegen Flapping tut, wie Eskalations-Ketten aufgebaut sind und welche Anti-Patterns Teams in die Resignation treiben.

1) Schwellenwerte – statisch vs. dynamisch

Die einfachste Form: ein fester Wert, jenseits dessen Alarm geschlagen wird. „Disk > 90 % → Critical". Funktioniert für viele Fälle. Klick und ziehe den Wert, um zu sehen, wie ein zweischwelliger Alarm reagiert:

2) Trends statt Punktwerte – „Disk wird in 7 Tagen voll"

Ein Punktwert sagt dir den Zustand jetzt. Spannender ist oft der Trend – wohin entwickelt es sich? Predict_linear in Prometheus, forecast() in Zabbix: extrapoliert lineare Steigung in die Zukunft. Ein klassischer Anwendungsfall:

# PromQL: warnt, wenn aktueller Trend auf "voll in 4 Tagen" hinweist
predict_linear(node_filesystem_avail_bytes[6h], 4*24*3600) < 0

Vorteil: du wirst gewarnt, bevor der Wert überhaupt einen kritischen Punkt erreicht. Mehr zur systematischen Trend-Auswertung in Kapazitätsplanung.

3) Hysterese gegen Flapping

„Flapping" beschreibt einen Service, der wiederholt zwischen OK und Problem hin- und herwechselt – etwa wenn die CPU-Last bei 80 % schwingt und die Warning-Schwelle bei 80 % liegt. Folge: alle paar Sekunden ein „alarmierender" Statuswechsel, Mailbox läuft voll, niemand reagiert mehr. Hysterese ist die Lösung: zwei verschiedene Schwellen für „Alarm an" und „Alarm aus":

4) Eskalation – wer wird wann geweckt?

Ein Alarm braucht einen Empfänger. Bei kritischen Systemen reicht aber „eine E-Mail an die IT-Abteilung" nicht – wenn niemand antwortet, muss es weitergehen. Das ist die Eskalationskette. Klick „Alarm starten", um eine typische Kette in Aktion zu sehen:

5) Alert-Fatigue – das größte Anti-Pattern

Wenn ein Team täglich 200 Alarme bekommt, von denen 190 nicht handlungsrelevant sind, dann werden auch die 10 echten ignoriert. Das ist Alert-Fatigue, eines der häufigsten und gefährlichsten Probleme in der Praxis. Ein gutes Alarm-System hat wenige Alarme – aber jeder ist relevant:

6) Acknowledgements, Silencing, Maintenance Windows

Drei Werkzeuge, die jedes ernstzunehmende Monitoring-System bietet:

• Acknowledgement (Ack). Jemand hat den Alarm gesehen und übernimmt. Stoppt die Eskalation. Wichtig: das ist nicht dasselbe wie „behoben". Der Alarm bleibt aktiv im Dashboard, sendet aber keine neuen Notifications mehr.
• Silencing. Bestimmte Alarme für einen Zeitraum bewusst ausschalten – etwa weil bekannt ist, dass ein System gerade umzieht oder ein Drittprodukt fehlerhaft alarmiert. Sparsam einsetzen! Silenced-Alarme sind eine häufige Ursache übersehener Probleme.
• Maintenance Window. Geplante Wartung – Alarme während des Zeitraums werden unterdrückt oder zumindest entsprechend markiert. Verbindet sich mit Change Management: jeder Change sollte ein passendes Maintenance Window auslösen.

7) Auf welchen Kanal alarmieren?

Zusammenfassung

Schwellenwert-Alarm wird brauchbar erst, wenn drei Dinge stimmen: gut gewählte Schwellen (statisch oder dynamisch/baseline-basiert), Trend-statt-Punkt-Logik (mit predict_linear/forecast), Hysterese oder min_duration gegen Flapping. Eskalations-Ketten regeln, wer wann benachrichtigt wird – mit Acknowledgements als Stopp-Signal. Größte Falle: Alert-Fatigue – durch radikales Aufräumen vermeiden (weniger ist mehr). Silencing und Maintenance Windows für geplante Ausnahmen. Benachrichtigungskanäle nach Eskalationsstufe staffeln – E-Mail/Chat fürs Erste, SMS/Pager/Anruf für die Stufen danach. Eng verzahnt mit Incident Management und Service Level Management.

Verwandte Lektionen: Incident Management · Level Support · Service Level Management · und mehrWeitere relevante LektionenKapazitätsplanungMonitoring-KonzeptTicket-PriorisierungChange ManagementProblem ManagementFailoverNagios & Icinga