SLO Monitoring, das Zuverlässigkeit messbar macht

Was ist SLO Monitoring?

SLO Monitoring überwacht, ob ein Service seine Service Level Objectives erfüllt. Ein Service Level Indicator (SLI) misst einen Aspekt der Nutzererfahrung, meist als Anteil guter Ereignisse an allen Ereignissen, etwa erfolgreiche Requests oder Requests unter 300 ms. Ein Service Level Objective (SLO) legt ein Ziel für diesen SLI über ein Zeitfenster fest, zum Beispiel 99,9 Prozent über 28 Tage. Die Differenz zwischen Ziel und 100 Prozent ist das Fehlerbudget, englisch Error Budget: das Maß an Unzuverlässigkeit, das ein Service haben darf, bevor Nutzer spürbar beeinträchtigt sind.

SLOs verlagern die Diskussion von einzelnen Alerts und Charts auf eine einzige Frage: Sind wir gerade zuverlässig genug für unsere Nutzer, und wie viel Risiko können wir noch eingehen?

Warum SLO Monitoring wichtig ist

Ohne SLOs ist Zuverlässigkeit entweder gar nicht definiert oder stillschweigend auf 100 Prozent gesetzt. Teams reagieren dann auf jede Spitze, alarmieren auf Ursachen statt auf Symptome und streiten darüber, ob ein Release zu riskant ist. SLOs ersetzen das durch eine vereinbarte Zahl. Ist das Fehlerbudget gesund, können Teams schneller liefern und experimentieren. Ist es aufgebraucht, hat Zuverlässigkeitsarbeit Vorrang.

SLOs verbessern auch die Alarmierung. Statt statischer Schwellwerte auf einzelnen Metriken messen Burn-Rate-Alerts, wie schnell das Fehlerbudget verbraucht wird, und das hängt direkt mit der Beeinträchtigung der Nutzer zusammen.

SLIs, SLOs und Fehlerbudgets in der Praxis

• Verfügbarkeits-SLI: Anteil der Requests mit erfolgreichem Statuscode.
• Latenz-SLI: Anteil der Requests, die unter einem definierten Schwellwert abgeschlossen werden.
• Qualitäts-SLI: Anteil vollständiger und korrekter Antworten, etwa Suchergebnisse ohne Fallback.
• Aktualitäts-SLI: Anteil der Datenaktualisierungen innerhalb einer Zielverzögerung, hilfreich für Pipelines und Queues.

Ein SLO von 99,9 Prozent über 28 Tage erlaubt rund 40 Minuten vollständigen Ausfall oder entsprechend mehr Teilfehler, verteilt über den Zeitraum. Obseria berechnet Budget und Verbrauch fortlaufend.

Multi-Window-Burn-Rate-Alerts

Die Burn-Rate beschreibt, wie schnell das Fehlerbudget im Verhältnis zum SLO-Zeitfenster verbraucht wird. Eine Burn-Rate von 1 verbraucht das Budget genau zum Ende des Fensters; eine Burn-Rate von 14,4 würde ein 28-Tage-Budget in etwa zwei Tagen aufzehren. Multi-Window-Alerts kombinieren ein langes Fenster, das bestätigt, dass das Problem erheblich ist, mit einem kurzen Fenster, das bestätigt, dass es noch andauert. So werden ernste Incidents schnell erkannt, und kurze, bereits abgeklungene Spitzen lösen keine Page aus.

(1 - sum(rate(http_requests_total{service="checkout",code!~"5.."}[1h]))
   / sum(rate(http_requests_total{service="checkout"}[1h]))) / (1 - 0.999) > 14.4

Obseria legt für jedes SLO automatisch Fast-Burn- und Slow-Burn-Alerts an und routet sie über dieselben Alert-Regeln, On-Call-Integrationen und Incident-Workflows wie alle anderen Alerts.

So funktioniert SLO Monitoring mit Obseria

SLIs in Obseria können jedes Signal in Obseria Lake nutzen: Prometheus- und OpenTelemetry-Metriken, Trace-Spans, Logs oder synthetische Checks. TopoGraph verknüpft jedes SLO mit seinem Service, sodass Sie sehen, welche Abhängigkeiten zum Budgetverbrauch beigetragen haben und welche Deployments vorausgingen. Sinkt ein SLO zu schnell, kann Obseria Intelligence eine Ursachenanalyse starten und ihre Beweiskette vorlegen.

Release Gates verbinden Fehlerbudgets mit der Auslieferung. Ihre CI/CD-Pipeline fragt vor dem Deployment bei Obseria an, ob ein Service im Budget liegt, und kann warnen oder blockieren, wenn es aufgebraucht ist. SLOs definieren Sie über die Oberfläche, die API, die CLI oder Terraform, sodass sie im selben Repository wie der Service liegen können.

Best Practices für SLO Monitoring

1. Mit wenigen SLOs starten. Ein Verfügbarkeits- und ein Latenz-SLO pro kritischer User Journey reichen für den Anfang.
2. Nah am Nutzer messen. Daten von Load Balancer, Gateway oder Client spiegeln die Erfahrung besser wider als interne Metriken.
3. Realistische Ziele setzen. Orientieren Sie sich an der aktuellen Leistung und den Erwartungen der Nutzer, nicht an 100 Prozent.
4. Budget-Richtlinien vereinbaren. Legen Sie vorab fest, was passiert, wenn das Budget aufgebraucht ist.
5. Regelmäßig überprüfen. Passen Sie SLIs und Ziele an, wenn sich Produkt und Nutzer verändern, etwa nach größeren Architekturänderungen.