SLIs und SLOs definieren, die bedeutungsvolle Alerts auslösen

Einführung

In dem Bestreben, Alert Fatigue zu eliminieren, erkennen viele Teams, dass schwellenwertbasiertes Alerting grundlegend fehlerhaft ist. Wenn Sie einen Alert auslösen, wenn Fehlerraten 2% erreichen, der Datenverkehr aber so gering ist, dass 2% nur einer einzigen fehlgeschlagenen synthetischen Probe entspricht, haben Sie einen Ingenieur wegen einer statistischen Anomalie alarmiert.

Der Industriestandard als Ersatz für veraltete Schwellenwerte ist das auf Service Level Objectives (SLOs) basierte Alerting. Durch die Definition strenger SLIs, das Aushandeln von Error Budgets und das ausschließliche Alerting auf Burn Rates stellen SREs sicher, dass sie nur alarmiert werden, wenn Benutzer bedeutenden, anhaltenden Schmerz erleiden.

Problemübersicht: Warum 100% Zuverlässigkeit das falsche Ziel ist

Eine der schwierigsten psychologischen Hürden in der Entwicklung ist die Akzeptanz, dass eine Anwendung keine 100% Verfügbarkeit benötigt. Das Streben nach 100% Zuverlässigkeit blockiert die Geschwindigkeit von Feature-Deployments und löst endlose Alert-Stürme für mikroskopische Probleme aus.

Typischerweise ist ein Ziel zwischen 99,9% (Drei Neunen, ungefähr 43 Minuten Ausfallzeit pro Monat) und 99,99% ideal. Die verbleibenden 0,1% sind Ihr Error Budget. Es ist eine Toleranz für akzeptable Unzuverlässigkeit. Wenn Sie innerhalb Ihres Budgets sind, laufen Deployments weiter und der Pager bleibt stumm. Wenn Sie es zu schnell aufbrauchen, klingelt der Pager, um die Blutung zu stoppen.

Technischer Einblick: Die SLI-Formel

Ein Service Level Indicator (SLI) ist eine streng definierte, messbare Metrik, die die Benutzererfahrung repräsentiert. Das Google SRE-Buch definiert eine generische Formel, die fast alle SLI-Berechnungen vereinfacht:

Wenden wir dies auf eine Web-API an:

• Gesamtereignisse: Alle eingehenden HTTP-Anfragen an den Zahlungsendpunkt.
• Gute Ereignisse: HTTP-Anfragen, die einen 2xx-Statuscode zurückgaben UND in unter 400ms abgeschlossen wurden.

Wenn wir 10.000 Anfragen erhalten und 9.900 schnell und erfolgreich sind, beträgt unser SLI 99%.

Fehlermodi: Die Gefahren statischer Schwellenwerte

Stellen Sie sich vor, Sie setzen einen statischen Schwellenwert-Alert: Alarmiere mich, wenn der SLI über ein 5-Minuten-Fenster unter 99% fällt.

Sie werden auf zwei Fehlermodi stoßen:

1. Der katastrophale Einbruch

Wenn die Datenbank hart abstürzt und Ihr SLI auf 0% einbricht, ist das 5-Minuten-Fenster viel zu langsam! Sie mussten 30 Sekunden nach Beginn des Ausfalls alarmiert werden, nicht 5 Minuten tief in der Ausfallzeit.

2. Das schleichende Leck

Wenn ein langsames Speicherleck konsistent 1,5% der Anfragen zum Scheitern bringt, beträgt Ihr SLI 98,5%. Da er nie drastisch abfällt, löst der Alert nie aus. Dennoch erleben Benutzer über 30 Tage konstant Frustration, und Sie zerstören leise Ihr monatliches Error Budget.

Überwachungsstrategie: Burn Rate Alerting

Die Lösung für diese Fehlermodi ist Burn Rate Alerting. Anstatt absolute Schwellenwerte zu prüfen, berechnen Sie, mit welcher Geschwindigkeit Ihr monatliches Error Budget aufgebraucht wird.

Eine Burn Rate von 1 bedeutet, dass das Budget in genau 30 Tagen aufgebraucht sein wird.

Eine Burn Rate von 14,4 bedeutet, dass das Budget in genau 2 Tagen vollständig aufgebraucht sein wird.

Wir konfigurieren Multi-Window Burn Rate Alerts, um sowohl schnelle als auch langsame Verbrennung zu erkennen:

• Schnelle Verbrennung (PAGER): Burn Rate > 14,4 über 1 Stunde. Dies zeigt einen schwerwiegenden Ausfall an, der sofortiges menschliches Eingreifen erfordert.
• Langsame Verbrennung (TICKET): Burn Rate > 1,5 über 3 Tage. Der Pager bleibt stumm, aber ein Jira-Ticket wird erstellt, damit das Team die Degradierung während der normalen Arbeitszeiten untersuchen kann.

Debugging-Workflow: Praktische PromQL-Implementierung

Hier ist ein Beispiel-PromQL-Snippet für einen schnellen Verbrennungsalert (Rate 14,4) über ein 1-Stunden-Fenster für ein 99,9%-SLO. Die manuelle Erstellung dieser Abfragen kann komplex sein, daher werden Tools wie Sloth oder Prometheus Operator empfohlen.

sum(rate(http_requests_total{status=~"5.."}[1h]))
/
sum(rate(http_requests_total[1h]))
> (1 - 0.999) * 14.4

Dies fragt genau das ab, was Sie interessiert: Verbrauchen wir unsere erlaubte Fehlertoleranz zu schnell, um den Monat zu überstehen?

Fazit

Die Migration von rohen Schwellenwerten zu SLO Burn Rate Alerting erfordert einen Reifesprung für Monitoring-Kulturen. Es akzeptiert die Realität, dass kleine Ausreißer akzeptabel sind, während eine sofortige Reaktion garantiert wird, die direkt proportional zum tatsächlichen Benutzerschmerz ist.

Um SLIs sicher aufzubauen, müssen Sie die wahren Grenzen Ihrer Infrastruktur messen. Die globalen synthetischen HTTP-Checks und DNS-Anomalie-Sonden von Heimdall generieren perfekte Top-of-Funnel-SLI-Metriken und stellen sicher, dass Sie absolut sicher sein können, dass der Benutzer tatsächlich betroffen ist, wenn Heimdall ein fehlschlagendes Ziel meldet.