Error Budgets und Burn-Rate-Alerts: aus den richtigen Gründen alarmieren
Wie man aus einem SLO Alerts macht, die bei echten Ausfällen schnell auslösen, bei Rauschen still bleiben und aufhören, sobald das Problem behoben ist.
Die Beispiele sind generisch und dienen der Veranschaulichung. Sie stammen aus keiner Kundenumgebung: Passen Sie Schwellenwerte und Einstellungen an Ihr eigenes System an.
Bei dem beginnen, was Nutzer erleben
Die meisten lauten Alarme entstehen, weil auf Ursachen alarmiert wird — CPU, Speicher, ein neu gestarteter Pod — statt auf das, was Nutzer spüren. Ein Service-Level-Indikator (SLI) misst Letzteres direkt: den Anteil gültiger Anfragen, die gut waren. Gut kann eine Antwort ohne Serverfehler bedeuten, eine Antwort unter einem Schwellenwert oder beides.
Ein Service-Level-Objective (SLO) legt ein Ziel für diesen Anteil über ein Zeitfenster fest, zum Beispiel 99,9 % erfolgreiche Anfragen über 30 Tage. Die Lücke zu 100 % ist das Error Budget: hier 0,1 % der Anfragen oder rund 43 Minuten Totalausfall im Monat.
Warum Schwellenwert-Alerts scheitern
Ein Alert wie „Fehlerrate über 1 % für 5 Minuten“ ist zugleich zu empfindlich und zu langsam. Er alarmiert bei einer kurzen Spitze, die kaum Budget verbraucht hat, und löst nie aus bei einer Fehlerrate von 0,5 %, die still das ganze Budget in einer Woche aufbraucht.
Die Burn Rate löst das. Sie ist die Geschwindigkeit, mit der das Budget relativ zum SLO verbraucht wird: Eine Burn Rate von 1 verbraucht genau das Budget über das Fenster; eine Burn Rate von 14,4 verbraucht ein 30-Tage-Budget in gut zwei Tagen.
Alerts mit mehreren Fenstern und Burn Rates
Der im SRE Workbook von Google beschriebene Ansatz kombiniert jeden Burn-Rate-Schwellenwert mit einem langen Fenster, das zeigt, dass das Problem erheblich ist, und einem kurzen Fenster, das zeigt, dass es noch andauert. Für ein SLO von 99,9 % über 30 Tage ist ein gängiger Ausgangspunkt:
- Alarm: Burn Rate über 14,4 in 1 Stunde und in 5 Minuten — 2 % des Budgets in einer Stunde verbraucht.
- Alarm: Burn Rate über 6 in 6 Stunden und in 30 Minuten — 5 % des Budgets verbraucht.
- Ticket: Burn Rate über 1 in 3 Tagen und in 6 Stunden — 10 % des Budgets verbraucht.
# Fast-burn page for a 99.9% availability SLO (error budget = 0.001)
(
sum(rate(http_requests_total{job="api", code=~"5.."}[1h]))
/ sum(rate(http_requests_total{job="api"}[1h]))
) > (14.4 * 0.001)
and
(
sum(rate(http_requests_total{job="api", code=~"5.."}[5m]))
/ sum(rate(http_requests_total{job="api"}[5m]))
) > (14.4 * 0.001)Das kurze Fenster ist so wichtig wie das lange: Sobald der Fix ausgerollt ist, sinkt der 5-Minuten-Anteil und der Alert löst sich auf, statt den Rest der Stunde weiterzufeuern.
Details, die über den Erfolg entscheiden
- Recording Rules: Berechnen Sie die Fehlerquote jedes Fensters vor, damit Alert-Ausdrücke günstig und lesbar bleiben.
- Wenig Traffic: Bei wenigen Anfragen pro Minute ist ein einzelner Fehler ein großer Anteil. Verlangen Sie eine Mindestzahl an Anfragen oder messen Sie mit synthetischen Prüfungen.
- Latenz-SLOs: Zählen Sie Anfragen, die langsamer als der Schwellenwert sind, als schlechte Ereignisse — mit Histogramm-Buckets, die den Schwellenwert enthalten.
- Ausnahmen: Legen Sie vorab fest, ob Client-Fehler und Health Checks zählen, und schreiben Sie es neben das SLO.
Wofür das Budget da ist
Das Budget ist ein Entscheidungswerkzeug, nicht nur ein Pager. Solange es gesund ist, kann das Team schneller ausliefern und riskantere Änderungen eingehen. Ist es aufgebraucht, hat Zuverlässigkeitsarbeit Vorrang vor Features, bis sich der Trend erholt. Vereinbaren Sie diese Regel mit den Produktverantwortlichen vor der ersten Verletzung, nicht währenddessen.