API Monitoring: SLIs/SLOs, Alerts, Dashboards.
API-Monitoring: SLIs, SLOs und Alerts, die wirklich triggern
Ein Dashboard, das niemand schaut, hilft nicht. Alerts, die zu oft feuern, werden ignoriert.
SLI und SLO – kurz erklärt
SLI (Service Level Indicator): Eine messbare Eigenschaft des Services. Z.B.: Latenz-Percentile, Error Rate, Availability (Uptime).
SLO (Service Level Objective): Das Ziel für diesen SLI. Z.B.: P99 Latenz < 500ms. Error Rate < 0,1%. Availability > 99,9%.
SLOs sind Verträge mit euch selbst. Wenn sie verletzt werden, muss jemand reagieren.
Was gemessen werden sollte
Die vier goldenen Signale (aus dem Google SRE Buch): Latency (wie schnell?), Traffic (wie viel?), Errors (wie viele Fehler?), Saturation (wie ausgelastet?).
Für APIs konkret: Request Rate per Endpoint, P50/P95/P99 Response Time, Error Rate per Status Code, Dependency-Latenz (Datenbank, externe Services).
Alert-Design: Symptome, nicht Ursachen
Gute Alerts warnen bei Symptomen, die Nutzer bemerken. Nicht bei internen Metriken, die niemanden interessieren. "CPU > 80%" ist eine Ursache – oft kein Handlungsbedarf. "P99 Response Time > 2s" ist ein Symptom – jetzt muss jemand handeln.
Alert-Müdigkeit vermeiden
Zu viele Alerts = niemand reagiert mehr. Jeder Alert muss folgendes haben: eindeutigen Schweregrad, klaren Handlungsauftrag, und einen Runbook-Link (was mache ich jetzt?).
Und: Alerts regelmäßig überprüfen. Was seit Monaten nie angeschlagen hat und nie nötig war – kann es weg?
Checkliste API-Monitoring
SLIs und SLOs pro kritischer API definiert
Dashboards für die vier goldenen Signale
Alerts auf Symptome, nicht interne Metriken
Runbooks für jeden kritischen Alert verlinkt
Alert-Review-Zyklus definiert
API-Monitoring aufsetzen?
markom.digital richtet SLI/SLO-basiertes Monitoring für APIs ein – mit Dashboards und Alerting, das im Ernstfall wirklich hilft.
