Worum geht’s
Was du nicht misst, bemerkst du erst, wenn der Nutzer anruft. Im Second-Level baust du Checks, die Dienste überwachen, definierst Schwellen und ein Alerting, das warnt, ohne mit Fehlalarmen zu ermüden. Verfügbarkeitsziele (SLA) übersetzt du in konkrete Downtime-Budgets, an denen du dein Monitoring ausrichtest.
Konzept
- Check-Arten: Ein Liveness-Check prüft „läuft der Prozess?” (Port offen,
Ping antwortet). Ein Readiness-/Service-Check prüft „funktioniert er
fachlich?” (HTTP 200 auf
/health, Antwortzeit unter Schwelle, DB erreichbar). Letzteres fängt den „Prozess läuft, liefert aber Fehler 500”-Fall. - SLA / Verfügbarkeit: in Prozent über eine Periode. 99,9 % („three nines”) erlaubt ca. 8,77 h Ausfall pro Jahr, 99,99 % nur ~52 min. Jede zusätzliche Neun verzehnfacht ungefähr den Aufwand.
- Alerting-Konzept: Schwellen mit Warning (frühzeitig, z. B. Disk 80 %) und Critical (Eingriff nötig, Disk 95 %). Gegen Fehlalarme helfen Hysterese/Dämpfung (erst nach N fehlgeschlagenen Checks alarmieren) und Eskalationsstufen (E-Mail → Push → Anruf). Alert-Müdigkeit ist real: zu viele Alarme = niemand schaut mehr hin.
- Symptom statt Ursache alarmieren: melde „Dienst antwortet nicht für Nutzer”, nicht jede einzelne interne Metrik.
Konzept-Visualizer
Wähle eine Verfügbarkeitsklasse und lies das erlaubte Ausfall-Budget pro Jahr, Monat, Woche und Tag ab. So wird greifbar, was eine zusätzliche Neun kostet.
| Periode | Erlaubte Ausfallzeit |
|---|---|
| pro Jahr | — |
| pro Monat | — |
| pro Woche | — |
| pro Tag | — |
Beispiel-Fall
Gegeben: Ein interner Dienst soll 99,9 % verfügbar sein. Du planst ein Wartungsfenster — wie viel Downtime bleibt im Monat?
- 99,9 % = 0,1 % Ausfall erlaubt. Pro Monat (≈ 30 Tage) sind das rund 43 min.
- Ein geplantes Wartungsfenster zählt voll auf dieses Budget — willst du es ausklammern, muss das im SLA als „geplante Wartung” vereinbart sein.
- Check-Design: HTTP-
/healthalle 60 s, Alarm erst nach 3 Fehlversuchen in Folge (Dämpfung) → ein einzelner Aussetzer löst keinen Pager aus. - Eskalation: 1. Fehlversuch → nur Log; 3 in Folge → Warning per Chat; 10 min anhaltend → Critical per Push an Bereitschaft.
- Verifizieren: Test-Ausfall (Dienst kurz stoppen) und prüfen, ob der Alarm wie geplant nach der Dämpfung kommt — nicht früher, nicht später.
Kern: erst das Budget kennen, dann Check-Frequenz, Dämpfung und Eskalation so wählen, dass echte Ausfälle sicher, einzelne Aussetzer aber nicht alarmieren.
Anwenden
Bestimme für einen deiner Dienste eine realistische Verfügbarkeitsklasse — und richte Wartungsfenster und Alarmschwellen am abgelesenen Budget aus.
- Wähle 99,9 % und lies das Monats- und Jahresbudget ab.
- Vergleiche mit 99,99 % — sieh, wie drastisch das Budget schrumpft.
- Überlege, ob dein Dienst die nächsthöhere Klasse überhaupt braucht (Aufwand vs. Nutzen).
Geplante Checks musst du nicht selbst bauen: Die Monitoring-Plattform unter
/monitor richtet externe HTTP-/TCP-Checks ein und benachrichtigt bei
Ausfällen — ideal, um das hier Gelernte direkt produktiv zu nutzen.
Selbsttest
Praxis-Challenge
Lege für einen Dienst ein Verfügbarkeitsziel fest (z. B. 99,9 %), lies im SLA-Rechner das Monatsbudget ab und entwirf ein Alerting-Konzept: Check-Intervall, Dämpfung (N Fehlversuche) und zwei Eskalationsstufen. Begründe, warum dein Wartungsfenster ins Budget passt.