Wenn Ihr Team nachts wegen „CPU hoch“ geweckt wird, ist das nicht Observability – das ist Lärm. SLO-basiertes Alerting dreht die Logik um: Wir alarmieren nicht bei jeder Metrik-Anomalie, sondern dann, wenn ein messbares Nutzerziel (SLO) gefährdet ist. Das ist der Unterschied zwischen „Graf sieht komisch aus“ und „Checkout-Ausfälle fressen unser Error Budget“.
Dieser Beitrag ist als praktische Orientierung gedacht: Welche SLO-Alerting Beispiele funktionieren in Produktion, wie setzt man sie in Prometheus-kompatiblen Setups um, und wo liegen die typischen Trade-offs. Zielgruppe sind Teams, die bereits Metriken/Tracing/Logs haben (oder aufbauen) und Alarmierung endlich an Business-Impact koppeln wollen.
Was SLO-Alerting anders macht (und warum das zählt)
SLOs definieren ein Qualitätsziel für einen Service aus Nutzersicht, typischerweise als Verfügbarkeits- oder Latenz-Objective über ein Rolling Window (z. B. 99,9 % erfolgreiche Requests pro 30 Tage). Daraus ergibt sich ein Error Budget: der „Spielraum“ für Fehler, bevor das Ziel verfehlt wird.
SLO-Alerting nutzt dieses Error Budget als Steuergröße. Statt harte Schwellen an Rohmetriken zu hängen, wird alarmiert, wenn die aktuelle Fehler- oder Latenzrate das Budget in absehbarer Zeit aufbraucht. Dadurch werden Alerts seltener, aber deutlich relevanter. Der Nebeneffekt ist operativ wichtig: weniger Alarmmüdigkeit, klarere Priorisierung von Stabilitätsarbeit und ein sauberer Rahmen für Release-Entscheidungen.
Es hängt allerdings stark vom Service-Typ ab. Bei einem Batch-System ohne strikte Echtzeit-Anforderungen ist eine reine SLO-Alarmierung oft zu träge. Bei hochkritischen, interaktiven Systemen ist sie in der Regel genau richtig – ergänzt um wenige „symptomatische“ Alerts (z. B. kompletter Traffic-Einbruch).
SLO-Alerting Beispiele: die Burn-Rate-Logik
Das robusteste Muster im SRE-Umfeld ist Burn-Rate-Alerting. Die Burn Rate beschreibt, wie schnell das Error Budget im Vergleich zur erlaubten Rate verbraucht wird.
Beispiel: SLO 99,9 % erfolgreiche Requests über 30 Tage. Erlaubte Fehlerquote ist 0,1 %. Wenn Sie aktuell 1 % Fehler haben, verbrennen Sie Budget mit einer Burn Rate von 10. Damit wäre das Monatsbudget rechnerisch in 3 Tagen aufgebraucht.
In Prometheus-Logik wird das meist als Verhältnis „beobachtete Fehlerquote / erlaubte Fehlerquote“ modelliert, jeweils über ein Zeitfenster. Wichtig sind zwei Dinge: Erstens brauchen Sie saubere SLIs (Service Level Indicators), z. B. aus HTTP-Statuscodes oder aus business-näheren Erfolgs-Signalen. Zweitens brauchen Sie mehrere Zeitfenster, weil ein kurzes Fenster schnell reagiert, aber empfindlicher ist.
Beispiel 1: Multiwindow Burn Rate (Paging vs. Ticket)
Ein praxistaugliches Setup nutzt zwei Alert-Stufen: Paging (sofort) und Ticket (zeitnah).
Für Paging kombinieren Sie ein kurzes und ein mittleres Fenster, damit kurze Peaks nicht sofort wecken, echte Incidents aber schnell durchschlagen. Typisch sind Kombinationen wie 5 Minuten und 1 Stunde.
Für Ticketing nutzen Sie längere Fenster (z. B. 2 Stunden und 1 Tag), um schleichende Erosion zu erkennen, die keine akute Eskalation braucht, aber in Richtung SLO-Verlust läuft.
Trade-off: Multiwindow-Alerts sind konzeptionell anspruchsvoller, zahlen sich aber aus. Sie reduzieren False Positives und sorgen dafür, dass „kleiner Spike“ nicht denselben Kanal triggert wie „wir verlieren heute das Budget“.
Beispiel 2: Burn Rate für Availability (Request-basiert)
Ein konkretes SLI-Muster: „Anteil erfolgreicher Requests“.
- Erfolgreich: HTTP 2xx/3xx und definierte 4xx, die als Nutzerfehler gelten (z. B. 401 bei nicht eingeloggten Nutzern).
- Fehlerhaft: 5xx, Timeouts, und 429, wenn Rate-Limiting aus Sicht Ihres Produkts als Fehler zählt.
Die Definition ist nicht akademisch. Wenn 429 „zu viele Requests“ in Wahrheit bedeutet, dass Ihr System nicht skaliert, gehört es in den Fehlerzähler. Wenn es bewusstes Abuse-Protection ist, eher nicht. Genau an dieser Stelle entscheidet sich, ob SLO-Alerting das Team auf die richtigen Probleme lenkt.
Beispiel 3: Burn Rate für Latenz (Good-Event SLI)
Für Latenz funktioniert „Fehlerquote“ als „Anteil schneller Requests“. Beispiel: „95 % der Requests unter 300 ms“.
Sie zählen dann „good events“ (unter der Schwelle) und „total events“. Burn Rate entsteht aus der aktuellen „bad event“-Rate relativ zur erlaubten „bad event“-Rate.
Hier lauert ein Praxisproblem: Latenz ist distributionsgetrieben. P95/P99-Metriken sind nützlich, aber für SLI-Zählung sind Histogramme (Prometheus histograms) oft die belastbarere Basis, weil Sie echte Anteile berechnen können. Wenn Sie nur Summary-Quantile haben, wird es schwieriger, weil Quantile nicht sauber aggregierbar sind.
Beispiele für SLO-Alerts, die viele Teams vergessen
Burn Rate ist der Kern, aber nicht alles. Drei Muster sind in anspruchsvollen Umgebungen häufig entscheidend.
Beispiel 4: „Traffic verschwindet“ als Symptom-Alert
SLO-Alerting setzt Traffic voraus. Wenn Ihr Traffic auf null fällt (Routing-Fehler, DNS, Auth-Blockade), kann ein SLO-Alert je nach SLI-Definition zu spät oder gar nicht feuern.
Ein symptomatischer Alert wie „Requests pro Minute unter Minimum“ ist deshalb legitim. Er ist kein Anti-SLO-Alert, sondern ein Guardrail. Setzen Sie ihn sparsam ein, klar begründet und auf Service-Ebene, nicht für jede einzelne Instanz.
Beispiel 5: Dependency-SLOs für kritische Downstreams
Viele Incidents entstehen nicht im eigenen Code, sondern an Abhängigkeiten: Payment-Provider, Message Broker, Identity, Datenbank.
Wenn Sie nur ein End-to-End-SLO messen, wissen Sie zwar, dass es brennt, aber nicht wo. Ergänzend helfen Dependency-SLOs, die ein klares „blame-aware“ Signal liefern, ohne Schuldzuweisungen zu institutionalieren.
Praxis: Ein Checkout-Service bekommt ein eigenes Availability-SLO, und zusätzlich ein SLO für „Successful calls to Payment API“. Alarmiert wird beim Payment-SLO zuerst als Ticket (weil Sie oft nur mitigieren können), beim Checkout-SLO ggf. als Page (weil das Produktziel leidet). Das ist differenzierte Betriebsführung statt Alarm-Spam.
Beispiel 6: SLO-Alerts nach User Journey statt nach Microservice
Microservices verleiten dazu, pro Service SLOs zu definieren. Für Betriebsergebnisse ist aber häufig die User Journey relevanter: Login, Suche, Checkout, Datenexport.
Wenn Sie OpenTelemetry-Tracing nutzen, können Sie SLIs auf der Journey-Ebene messen (z. B. End-to-End-Latenz von „Add to cart“ bis „Order created“). Das liefert ein Signal, das Produkt und Engineering gleichermaßen verstehen. Der Trade-off ist Mess-Komplexität und saubere Korrelations-IDs – es lohnt sich besonders bei umsatzkritischen Flows.
Schwellenwerte und Fenster: wie man „gute“ Alerts kalibriert
SLO-Alerting wirkt nur, wenn die Fenster und Burn-Rate-Schwellen zur Incident-Dynamik passen.
Ein gängiges Muster ist, für Paging eine Burn Rate zu wählen, die das Budget in wenigen Stunden bis maximal ein, zwei Tagen aufbrauchen würde, wenn der Zustand anhält. Für Ticketing ist die Schwelle niedriger, damit Sie schleichende Probleme sehen, bevor sie operativ teuer werden.
In der Praxis müssen Sie aber Ihre „Response Capability“ einrechnen: Wenn Ihr Team nachts nicht on-call ist, bringt ein aggressives Paging nichts – dann ist ein frühes Ticket am Nachmittag besser. Umgekehrt: Bei 24/7-Services kann ein schneller Page die MTTR drastisch reduzieren.
Kalibrierung gelingt am besten empirisch: zwei bis vier Wochen mit bewusst konservativen Thresholds starten, Alarm-Qualität reviewen, dann nachziehen. Wichtig ist, pro Alert eine klare Erwartung zu dokumentieren: „Was soll die on-call Person als Erstes tun?“ Wenn die Antwort fehlt, ist der Alert meistens zu generisch.
Typische Fehler bei SLO-Alerting (und wie man sie vermeidet)
Der häufigste Fehler ist ein SLI, der nicht die Nutzerrealität abbildet. Wenn „Request erfolgreich“ heißt, dass ein 200 zurückkam, aber der Payload semantisch falsch ist, messen Sie am Problem vorbei. Gerade bei datengetriebenen Systemen (Recommendations, Scoring, Exporte) braucht es manchmal Business-SLIs wie „Quote gültiger Ergebnisse“ oder „Freshness unter X Minuten“.
Der zweite Fehler ist das Vermischen von Cause- und Symptom-Alerts. SLO-Alerts sind Symptome. CPU, Queue-Länge, GC-Pausen sind Ursachenindikatoren. Ursachenindikatoren sind hilfreich für Diagnose, aber selten als Pager geeignet. Als Regel funktioniert: Paging über Symptome, Diagnose über Ursachen – und Ursachen nur dann alarmieren, wenn sie unmittelbar zu Nutzerimpact führen (z. B. „DB-Verbindungen erschöpft“ bei hartem Ausfall).
Der dritte Fehler ist fehlende Segmentierung. Ein globales SLO kann Ausfälle in einer Region oder einem Mandanten verdecken. Wenn Ihr Geschäft oder Ihre Compliance das verlangt, definieren Sie SLOs pro Region, Tier, oder kritischem Mandanten – aber mit Augenmaß, sonst explodiert die Zahl der Ziele.
Umsetzung in der Realität: Datenbasis, Compliance, Betriebsfähigkeit
SLO-Alerting ist nur so gut wie die Telemetrie. Prometheus-kompatible Metriken sind ein guter Standard, ergänzt um OpenTelemetry-Tracing für Journey-SLIs und strukturierte Logs für schnelle Ursachenanalyse. Entscheidend ist, dass Sie Metrik-Labels bewusst designen: zu viele Cardinality-Dimensionen machen Ihre Monitoring-Kosten und Query-Latenzen kaputt, zu wenige verhindern Segmentierung.
In deutschen und EU-regulierten Kontexten kommt hinzu: Telemetrie ist nicht „frei“. Pseudonymisierung, Datenminimierung und klare Aufbewahrungsfristen sind Pflicht, besonders wenn Traces oder Logs potenziell personenbezogene Daten enthalten. Das beeinflusst SLI-Design: oft ist es besser, technische Event-Zähler zu messen statt payload-nahe Inhalte.
Wenn Sie SLO-Alerting als Teil eines produktionsreifen Observability-Stacks aufbauen wollen, lohnt sich ein Ansatz, der Architektur, Tooling und Betriebsprozesse zusammen denkt. Genau an dieser Schnittstelle arbeitet Frontier Algorithmics typischerweise: messbare SLIs, saubere Instrumentierung, EU-rechtskonforme Telemetrie und ein Alerting, das MTTR reduziert statt Postfächer zu füllen.
Eine letzte, praktische Leitlinie
Behandeln Sie jeden Pager-Alert wie eine Kostenstelle: Wenn er nicht zuverlässig auf Nutzerimpact hinweist und eine klare erste Handlung auslöst, ist er zu teuer. Der beste SLO-Alert ist nicht der, der am „cleversten“ gerechnet ist, sondern der, der Ihr Team ruhig schlafen lässt und tagsüber die richtigen Entscheidungen erzwingt.