Wer Monitoring-Systeme betreibt, kennt das Problem: Alarme lösen aus, Dashboards leuchten rot, das On-Call-Telefon klingelt – aber eigentlich hat der Nutzer noch nichts gemerkt. Oder umgekehrt: Ein Dienst degradiert langsam über Stunden, kein einzelner Schwellenwert wird überschritten, und der Alert kommt zu spät oder gar nicht.
SLO-basiertes Alerting ist ein Ansatz, der diese Probleme grundsätzlich anders angeht. Statt einzelne Metriken gegen starre Schwellenwerte zu prüfen, fragt man: Wie viel des Error Budgets ist schon verbraucht, und wie schnell geht das weiter?
Was SLOs und Error Budgets sind
Ein Service Level Objective (SLO) ist eine messbare Zielgröße für die Qualität eines Dienstes. Typische Beispiele:
- 99,9 % aller HTTP-Requests werden in unter 500 ms beantwortet
- 99,5 % aller API-Aufrufe enden erfolgreich (kein 5xx-Fehler)
- Die Verfügbarkeit des Dienstes liegt über 99,95 % gemessen über 30 Tage
Das Error Budget ist der Umkehrwert: Bei einem SLO von 99,9 % Verfügbarkeit darf der Dienst in 30 Tagen insgesamt 43,2 Minuten ausfallen. Das ist das Budget, das verbraucht werden darf, ohne das SLO zu verletzen.
Wenn Fehler auftreten, wird dieses Budget verbraucht. Wenn es aufgebraucht ist, ist das SLO verletzt – und das hat Konsequenzen: für Reliability-Arbeit, für Deployments, für Feature-Arbeit. Das Konzept stammt aus Google's SRE-Praxis und hat sich als einer der praktischsten Ansätze für den Umgang mit Zuverlässigkeit erwiesen.
Das Problem mit klassischen Schwellenwert-Alarmen
Klassisches Alerting funktioniert einfach: Wenn Metrik X über Wert Y steigt, Alarm auslösen. Das klingt vernünftig, hat aber fundamentale Schwächen:
Zu viele Fehlalarme
Schwellenwerte werden oft konservativ gesetzt – zu nah an normalen Spitzen. Jede erhöhte Last, jedes kurze Latenzpeak, jede temporäre Verfügbarkeitsdelle löst einen Alarm aus, der keine echte Nutzerwirkung hat. Das Ergebnis ist Alert Fatigue: Teams ignorieren Alarme, weil die meisten bedeutungslos sind. Das Telefon klingelt, der Engineer schaut kurz hin, sieht nichts Kritisches – und geht zurück zum Schlafen. Beim nächsten echten Problem ist das Vertrauen in den Alert schon erodiert.
Echte Probleme werden übersehen
Ein Dienst kann konstant leicht unterperformen, ohne dass ein einzelner Schwellenwert je überschritten wird. Latenz liegt bei 490 ms, Schwellenwert ist 500 ms – kein Alarm. Aber wenn das über 20 Stunden so geht, ist das SLO längst verletzt. Schwellenwert-Alerting sieht Momentaufnahmen; das SLO-Modell sieht Trends.
Alarme ohne Kontext
„Latenz über 300 ms" sagt nichts darüber aus, ob das kritisch ist. Ist der Dienst dadurch für Nutzer spürbar beeinträchtigt? Wie lange läuft das schon? Ist das SLO gefährdet? Schwellenwert-Alarme antworten auf diese Fragen nicht – und zwingen den Engineer zur Kontextbeschaffung, bevor er reagieren kann.
SLO-basiertes Alerting: Das Burn-Rate-Modell
Die Kernidee des SLO-basierten Alertings ist die Burn Rate: Wie schnell wird das Error Budget verbraucht?
Eine Burn Rate von 1 bedeutet: Das Budget wird genau so schnell verbraucht, wie es sich über den Messzeitraum aufbaut. Bei einer 30-Tage-Messperiode würde bei Burn Rate 1 das Budget nach exakt 30 Tagen erschöpft sein – das SLO wäre knapp eingehalten.
Eine Burn Rate von 14 bedeutet: Das Budget wird 14-mal so schnell verbraucht. Bei einem 30-Tage-Fenster wäre das Budget in etwa 2 Tagen erschöpft. Das ist ein echtes Problem, das sofortige Aufmerksamkeit braucht.
Mehrere Alert-Ebenen kombinieren
Google empfiehlt in seinen SRE-Workbooks die Kombination aus kurzem und langem Beobachtungsfenster, um sowohl schnelle Ausreißer als auch langsame Degradierungen zu erkennen:
- Kritischer Alert (sofortiger Page): Burn Rate ≥ 14 über 1 Stunde – Budget erschöpft in weniger als 2 Tagen → sofortiger Eingriff erforderlich
- Kritischer Alert (Page): Burn Rate ≥ 6 über 6 Stunden – Budget erschöpft in weniger als 5 Tagen → baldiger Eingriff
- Warnung (Ticket, kein Page): Burn Rate ≥ 3 über 3 Tage → kein sofortiger Eingriff nötig, aber gezielte Untersuchung
- Info: Burn Rate ≥ 1 über mehrere Tage → Trend beobachten, noch kein Handlungsbedarf
Das Ergebnis: Pages werden nur ausgelöst, wenn ein echtes Risiko für das SLO besteht. Nicht bei jeder temporären Spike, nicht bei harmlosen Schwankungen – aber zuverlässig, wenn das Budget wirklich in Gefahr gerät.
Implementierung: Von der Theorie zur Praxis
Schritt 1: SLIs klar definieren
Bevor SLO-Alerting eingerichtet werden kann, muss klar sein, was gemessen wird. Service Level Indicators (SLIs) sind die konkreten Metriken. Für HTTP-Dienste ist das typischerweise:
- Verfügbarkeit: Anteil der Requests mit HTTP-Statuscode < 500 an allen Requests
- Latenz: Anteil der Requests, die in unter X Millisekunden beantwortet werden
- Fehlerrate: Anteil der fehlerhaften Requests an allen Requests
SLIs müssen klar messbar, aus dem System abrufbar und stabil in ihrer Definition sein – Änderungen an SLI-Definitionen invalidieren historische Daten.
Schritt 2: SLOs realistisch setzen
99,999 % klingt gut, ist aber für die meisten Dienste unrealistisch und teuer. SLOs sollten tatsächliche Nutzererwartungen widerspiegeln – nicht Marketingversprechen. Zu hohe SLOs führen zu dauerhaft ausgelösten Alerts und Frustration. Zu niedrige SLOs geben dem Team falsches Sicherheitsgefühl. Die erste Version eines SLO ist selten perfekt – sie wird mit der Zeit kalibriert.
Schritt 3: Burn-Rate-Abfragen konfigurieren
Die Berechnung der Burn Rate läuft über Abfragen der Monitoring-Plattform. Prometheus-Nutzer arbeiten mit Recording Rules:
# Fehlerrate über 1 Stunde (SLI-Wert)
rate(http_requests_total{status=~"5.."}[1h])
/
rate(http_requests_total[1h])
# Burn Rate = aktuelle Fehlerrate / erlaubte Fehlerrate (1 - SLO)
# Bei SLO 99.9%: erlaubte Fehlerrate = 0.001
# Burn Rate Alert wenn: (1h_error_rate / 0.001) >= 14Viele SaaS-Monitoring-Lösungen bieten SLO-Konfigurationsoberflächen, die diese Berechnung automatisieren und keine manuellen Prometheus-Queries erfordern.
Schritt 4: Eskalationspfade pro Alert-Ebene
SLO-Alerting ohne klare Eskalationspfade funktioniert nicht. Jede Alert-Ebene braucht eine definierte Reaktion: Wer wird benachrichtigt? Was ist der erste Schritt? Wann wird eskaliert? Ein kritischer Burn-Rate-Alert, der in ein stummes Slack-Kanal fällt, ohne jemanden zu wecken, ist wertlos.
Was SLO-Alerting nicht löst
SLO-basiertes Alerting ist kein Allheilmittel. Es löst nicht:
- Kausalität: Ein SLO-Alert sagt, dass etwas schiefläuft – nicht warum. Debugging und Root-Cause-Analyse bleiben Aufgabe des Teams.
- Hintergrundprozesse ohne Nutzerbezug: Für Batch-Jobs und Cron-Prozesse ohne direkten SLI ist das Modell schwer anzuwenden. Heartbeat-Monitoring ergänzt hier.
- Neue Systeme ohne historische Daten: SLOs brauchen reale Messungen als Basis. Für neue Dienste braucht man zunächst Observationsdaten, bevor sinnvolle SLOs gesetzt werden können.
- Sehr granulare Ursachensuche: SLO-Alerts sind auf Servicelevel definiert. Für die genaue Fehlerlokalisierung braucht es weiterhin Distributed Tracing, Logs und spezifische Metriken.
SLO-Alerting und KI: Neue Herausforderungen
Mit dem Einsatz von KI-Komponenten in Produktionssystemen entstehen neue SLI-Anforderungen. Was bedeutet „Erfolg" bei einem LLM-gestützten Feature? Wie definiert man Latenz bei einem Streaming-Response? Diese Fragen sind noch nicht standardisiert gelöst, aber das Grundmodell – SLI definieren, SLO setzen, Budget-Verbrennung messen – lässt sich übertragen.
Einige Teams messen für KI-Komponenten bereits SLIs wie: Anteil der Antworten, die unter einem Qualitätsschwellenwert liegen (gemessen durch Klassifizierer), oder Anteil der Requests, die innerhalb des Token-Budgets bleiben. Diese Definitionen sind schwieriger zu operationalisieren als HTTP-Statuscodes, aber die Richtung ist klar.
Fazit
SLO-basiertes Alerting ist einer der effektivsten Wege, um Alert Fatigue zu reduzieren und gleichzeitig echte Probleme besser zu erkennen. Das Konzept braucht initiale Investition – SLIs definieren, SLOs realistisch setzen, Burn Rates berechnen und Eskalationspfade festlegen. Aber das Ergebnis ist ein Alerting-System, das pagt, wenn es wirklich wichtig ist, und still bleibt, wenn es das nicht ist. Für Teams, die wachsende Alert-Mengen bewältigen und dabei den On-Call-Betrieb entlasten wollen, ist SLO-basiertes Alerting ein konkreter, bewährter nächster Schritt.
Bildquelle: Pexels / Luke Chesser
Quellen: Google SRE Workbook (O'Reilly, 2018); Prometheus Alerting-Dokumentation; „The Site Reliability Workbook" (Beyer et al.); Atlassian SLO-Guide.
