Ein Alarm verlangt eine Entscheidung
- observability
- SLOs
- Prometheus
Bei den Nutzern beginnen
CPU-Auslastung ist ein Diagnosehinweis. Fehlgeschlagene Anfragen sind ein sichtbares Symptom. Nur bei Zuständen alarmieren, die eine zeitnahe menschliche Entscheidung erfordern. Erklärende Signale gehören auf ein Dashboard.
Ein Service-Level-Objective verwenden
Gute Ereignisse, alle relevanten Ereignisse und ein Messfenster definieren. Bei einem anfragebasierten Dienst kann Verfügbarkeit als erfolgreiche Anfragen geteilt durch relevante Anfragen gemessen werden. Explizit entscheiden, ob Client-Fehler zählen.
# Beispielhafte Fehlerquote; Selektoren an den Dienst anpassen.
sum(rate(http_requests_total{job="api",status=~"5.."}[5m]))
/
clamp_min(sum(rate(http_requests_total{job="api"}[5m])), 1e-9)Dies ist eine Diagnoseabfrage, keine vollständige Alarmregel. Ein Multi-Window-Burn-Rate-Alarm kombiniert anhaltenden Budgetverbrauch mit einem kürzeren Bestätigungsfenster. Fehlende Telemetrie braucht ein eigenes Signal: Eine fehlende Zeitreihe belegt keinen gesunden Zustand.
Die Entscheidung in den Alarm schreiben
- Welche Nutzererfahrung ist betroffen?
- Welches Dashboard bestätigt die Auswirkungen?
- Welches Runbook beschreibt den ersten hilfreichen Schritt?
- Wer verantwortet den Dienst, wenn die Erstreaktion nicht ausreicht?
Wenn keine sinnvolle Handlung folgt, prüfen, ob das Signal wirklich in den Bereitschaftskanal gehört.