Ein SLI (Service Level Indicator) ist eine quantitative Messgröße dafür, wie gut ein Service aus Sicht der Nutzer funktioniert, meist als Verhältnis guter zu gültigen Ereignissen, zum Beispiel der Anteil der Requests, die erfolgreich in unter 300 ms beantwortet werden. SLIs sind die Messwerte, auf denen SLOs und Error Budgets aufbauen.
Was ist ein SLI (Service Level Indicator)?
Ein SLI (Service Level Indicator) ist eine präzise definierte Messung eines Aspekts der Servicequalität, der für Nutzer zählt. Typische SLIs messen Verfügbarkeit, Latenz, Korrektheit oder Aktualität. Ein SLI ist weder Ziel noch Versprechen, sondern der beobachtete Wert. Das Ziel dafür ist das SLO, eine vertragliche Zusage mit Konsequenzen ist ein SLA.
Die praktischste Form ist ein Verhältnis von Ereignissen:
SLI = gute_Ereignisse / gültige_Ereignisse * 100 %So formuliert liegen SLIs immer zwischen 0 und 100 Prozent, sind zwischen Services vergleichbar und ergeben direkt ein Error Budget: Alles, was nicht gut ist, verbraucht Budget.
Es gibt zwei verbreitete Zählweisen. Request-basierte SLIs zählen einzelne Ereignisse wie HTTP-Requests oder verarbeitete Nachrichten und gewichten jede Nutzerinteraktion gleich. Zeitfensterbasierte SLIs teilen die Zeit in kurze Intervalle, etwa eine Minute, und werten ein Intervall als gut, wenn eine Bedingung erfüllt war, zum Beispiel eine Fehlerrate unter 1 Prozent. Request-basierte SLIs sind bei Services mit viel Traffic genauer. Zeitfensterbasierte SLIs helfen bei geringem oder ungleichmäßigem Traffic, weil sonst wenige fehlgeschlagene Requests in der Nacht das Verhältnis dominieren würden.
Gängige Arten von SLIs
| SLI-Typ | Gutes Ereignis | Typisch für |
|---|---|---|
| Verfügbarkeit | Request ohne Serverfehler beantwortet | APIs, Web-Frontends |
| Latenz | Request schneller als ein Schwellenwert beantwortet, etwa 300 ms | Interaktive Anfragen |
| Korrektheit | Antwort enthält die richtigen Daten | Preise, Suche, Abrechnung |
| Aktualität (Freshness) | Daten innerhalb einer festgelegten Zeit aktualisiert | Datenpipelines, Caches, Dashboards |
| Durchsatz oder Abschluss | Job oder Nachricht erfolgreich verarbeitet | Batch-Jobs, Queues |
Die Golden Signals sind ein guter Ausgangspunkt für die Auswahl, doch nicht jede Metrik ist ein SLI. Die CPU-Auslastung etwa sagt wenig über das Nutzererlebnis aus und eignet sich eher für Diagnose und Kapazitätsplanung.
Einen guten SLI definieren
Eine brauchbare SLI-Spezifikation beantwortet vier Fragen:
- Was ist ein gültiges Ereignis? Welche Requests zählen überhaupt? Health Checks, Bot-Traffic und wegen fehlerhafter Eingaben abgelehnte Requests (4xx) werden oft ausgeschlossen.
- Was ist ein gutes Ereignis? Zum Beispiel ein Status unter 500 und eine Dauer unter 300 ms.
- Wo wird gemessen? Am Load Balancer, im Service, im Browser per Real User Monitoring oder durch synthetische Prüfungen. Je näher am Nutzer, desto realistischer, aber auch verrauschter.
- Über welches Zeitfenster? SLIs werden über ein rollierendes Fenster ausgewertet, häufig 28 oder 30 Tage, und für das Alerting zusätzlich über kurze Fenster.
Beispiel: Latenz- und Verfügbarkeits-SLI
Eine illustrative Checkout-API mit Histogramm-Metriken im Prometheus-Format könnte zwei SLIs definieren:
# Verfügbarkeit: Anteil der Requests ohne 5xx
sum(rate(http_server_requests_total{service="checkout",code!~"5.."}[5m]))
/
sum(rate(http_server_requests_total{service="checkout"}[5m]))
# Latenz: Anteil der Requests schneller als 300 ms
sum(rate(http_server_duration_seconds_bucket{service="checkout",le="0.3"}[5m]))
/
sum(rate(http_server_duration_seconds_count{service="checkout"}[5m]))Sind in 30 Tagen 9.990.000 von 10.000.000 gültigen Requests gut, liegt der Verfügbarkeits-SLI bei 99,9 Prozent. Der Latenz-SLI zählt Requests unter einem Schwellenwert, statt ein Perzentil auszuweisen. Schwellenwertbasierte Verhältnisse lassen sich korrekt über Instanzen und Zeitfenster aggregieren, gemittelte Perzentile dagegen nicht.
Dieselben Verhältnisse funktionieren für kurze und lange Fenster. Über 30 Tage ausgewertet zeigen sie, ob das SLO eingehalten wird. Über 5 Minuten oder 1 Stunde ausgewertet steuern sie Burn-Rate-Alerts, die warnen, wenn das Budget zu schnell verbraucht wird. So dient eine einzige Definition sowohl dem Reporting als auch dem Alerting.
Best Practices
- Beginnen Sie mit wenigen SLIs pro Nutzerpfad, etwa Login, Suche und Checkout, statt mit Dutzenden pro Service.
- Messen Sie so nah am Nutzer wie praktikabel und gleichen Sie serverseitige SLIs mit echten Nutzerdaten ab.
- Wählen Sie Histogramm-Buckets passend zu Ihren Latenzschwellen, damit sich der SLI exakt berechnen lässt.
- Versionieren Sie SLI-Definitionen und überprüfen Sie sie, wenn sich das Produkt ändert. Eine geänderte Definition bricht die Historie.
- Verknüpfen Sie jeden SLI mit einem SLO, einem Error Budget und einer Alerting-Regel. Sonst bleibt er nur ein weiteres Diagramm.
Häufige Fehler
- Mittelwerte wie die durchschnittliche Latenz zu verwenden, die genau die langsamen Requests verbergen, die Nutzer bemerken.
- Clientfehler als Ausfälle zu zählen, sodass fehlerhafte Clients Ihr Budget aufbrauchen.
- Nur innerhalb des Service zu messen und Fehler in Load Balancer, DNS oder CDN zu übersehen.
- SLIs danach auszuwählen, welche Daten leicht verfügbar sind, statt danach, was das Nutzererlebnis abbildet.
- Die SLI-Definition stillschweigend zu ändern, etwa durch neue Ausschlüsse, ohne dies zu dokumentieren. Dann sind alte und neue Werte nicht mehr vergleichbar.
Wie Obseria hilft
In Obseria definieren Sie SLIs als Verhältnis guter zu gültigen Ereignissen auf Basis von Metriken, Traces oder Real-User-Daten, mit PromQL, OQL oder SQL. Jeder SLI speist ein SLO mit Error-Budget-Verfolgung und Multi-Window-Burn-Rate-Alerts. Da Metriken 13 Monate aufbewahrt werden, können Sie SLI-Trends über mehrere Quartale vergleichen.
