Die Burn Rate gibt an, wie schnell ein Service sein Error Budget im Verhältnis zum SLO verbraucht. Eine Burn Rate von 1 verbraucht das gesamte Budget genau bis zum Ende des SLO-Zeitfensters, eine Burn Rate von 10 zehnmal schneller. Berechnet wird sie als beobachtete Fehlerquote geteilt durch die erlaubte Fehlerquote.
Was die Burn Rate bedeutet
Jedes SLO definiert implizit ein Error Budget. Ein Verfügbarkeitsziel von 99,9 % über 30 Tage erlaubt, dass 0,1 % der Requests fehlschlagen; das ist das Budget. Die Burn Rate zeigt, wie schnell dieses Budget gerade verbraucht wird:
Burn Rate = beobachtete Fehlerquote / (1 - SLO-Ziel)Bei einem SLO von 99,9 % beträgt die erlaubte Fehlerquote 0,001. Schlagen aktuell 0,5 % der Requests fehl, liegt die Burn Rate bei 0,005 / 0,001 = 5. In diesem Tempo wäre das gesamte 30-Tage-Budget nach 30 / 5 = 6 Tagen aufgebraucht. Eine Burn Rate von genau 1 bedeutet, dass Sie das Fenster mit null Restbudget beenden; alles unter 1 lässt Reserve.
Der Nutzen liegt in der Normierung: Eine Fehlerrate von 0,5 % ist für einen 99,99-%-Service eine Krise und für einen 99-%-Service unkritisch. Die Burn Rate drückt beide Fälle in derselben Einheit aus.
Die Rechnung hinter Burn-Rate-Alerts
Welcher Anteil des Budgets in einem Alert-Fenster verbraucht wird, folgt direkt aus der Burn Rate:
verbrauchtes Budget = Burn Rate x Alert-Fenster / SLO-ZeitraumBei 30 Tagen (720 Stunden) verbraucht eine Burn Rate von 14,4 über eine Stunde 14,4 x 1 / 720 = 2 % des Budgets. Eine Burn Rate von 6 über sechs Stunden verbraucht 6 x 6 / 720 = 5 %. Eine Burn Rate von 1 über drei Tage (72 Stunden) verbraucht 10 %. Die Zeit bis zur Erschöpfung ist schlicht der SLO-Zeitraum geteilt durch die Burn Rate: Ein konstanter 14,4-facher Verbrauch leert ein 30-Tage-Budget in rund 50 Stunden.
Rückwärts gerechnet ergeben sich so die Schwellenwerte: Legen Sie fest, welchen Anteil des Budgets Sie verlieren dürfen, bevor jemand geweckt wird, wählen Sie ein Fenster und berechnen Sie die Burn Rate.
Multi-Window-, Multi-Burn-Rate-Alerts
Das Google SRE Workbook (Kapitel „Alerting on SLOs“) empfiehlt, mehrere Burn Rates mit jeweils zwei Fenstern zu kombinieren. Startwerte für ein SLO von 99,9 % über 30 Tage:
| Verbrauchtes Budget | Langes Fenster | Kurzes Fenster | Burn Rate | Aktion |
|---|---|---|---|---|
| 2 % | 1 Stunde | 5 Minuten | 14,4 | Page |
| 5 % | 6 Stunden | 30 Minuten | 6 | Page |
| 10 % | 3 Tage | 6 Stunden | 1 | Ticket |
Ein Alert feuert nur, wenn die Burn Rate im langen und im kurzen Fenster über dem Schwellenwert liegt. Das lange Fenster stellt sicher, dass tatsächlich genug Budget verbraucht wurde, um jemanden zu wecken. Das kurze Fenster, etwa ein Zwölftel des langen, sorgt dafür, dass der Alert kurz nach der Behebung endet, statt noch eine Stunde weiterzufeuern, weil das lange Fenster alte Fehler enthält. Schneller Verbrauch wird binnen Minuten erkannt, langsamer binnen Stunden, und kleine Ausreißer, die das SLO nie gefährden, bleiben still. Das reduziert Alert Fatigue spürbar.
Die Erkennungszeit skaliert mit der Schwere. Bei einem Totalausfall mit 100 % Fehlern und konstantem Traffic überschreitet die Ein-Stunden-Quote die 14,4-fache Schwelle von 1,44 % nach rund 52 Sekunden, die Page geht also nach etwa einer Minute raus. Ein kleinerer Incident mit 2 % Fehlern (Burn Rate 20) braucht rund 43 Minuten, bis dieselbe Regel auslöst. Das ist vertretbar, weil er das Budget deutlich langsamer verbraucht.
Beispiel: PromQL-Regel
Ein beispielhafter Prometheus-Alert für die schnellste Stufe, basierend auf Request-Zählern eines Checkout-Service:
(
sum(rate(http_requests_total{job="checkout",code=~"5.."}[1h]))
/ sum(rate(http_requests_total{job="checkout"}[1h]))
) > (14.4 * 0.001)
and
(
sum(rate(http_requests_total{job="checkout",code=~"5.."}[5m]))
/ sum(rate(http_requests_total{job="checkout"}[5m]))
) > (14.4 * 0.001)In der Praxis werden die Quoten je Fenster als Recording Rules vorberechnet, damit die Alert-Ausdrücke günstig und lesbar bleiben.
Best Practices
- Auf Burn Rate statt auf rohe Fehlerzahlen alarmieren. So hängt jede Page direkt an der Nutzerwirkung, wie das SLO sie definiert.
- Workbook-Werte als Ausgangspunkt nutzen und anhand der Frage nachjustieren, wie oft ein Alert zu echter Aktion geführt hat.
- Geringen Traffic bewusst behandeln. Erhält ein Service nur wenige Requests pro Minute, erzeugt ein einzelner Fehler eine enorme Burn Rate. Ergänzen Sie synthetischen Traffic, verlangen Sie eine Mindestanzahl an Requests oder fassen Sie kleine Services unter einem gemeinsamen SLO zusammen.
- Auch für Latenz-SLOs nutzen. Requests über dem Schwellenwert zählen als „schlechte Ereignisse“, die Formel bleibt dieselbe.
- Nach Dringlichkeit routen. Schneller Verbrauch geht an die Rufbereitschaft, langsamer wird zum Ticket.
Typische Fehler
Ein einzelnes kurzes Fenster führt zu flatternden Alerts bei jeder kurzen Spitze. Ein einzelnes langes Fenster erkennt Probleme spät und alarmiert lange nach der Erholung weiter. Häufig wird die Burn Rate außerdem aus gemittelten Fehlerraten pro Instanz berechnet statt aus summierten guten und gesamten Ereignissen. Dann zählen kleine Instanzen genauso viel wie große.
Wie Obseria unterstützt
In Obseria definieren Sie SLOs auf beliebigen Metrik- oder Span-Abfragen und alarmieren darauf direkt mit Multi-Window-, Multi-Burn-Rate-Regeln, wobei das verbleibende Error Budget stets sichtbar ist. Die Alerts landen im Incident Management, zusammen mit betroffenen Services und den letzten Deployments.
