Das Ziel ist es, Probleme zu erfassen, bevor die Seite ausfällt — Verschlechterungen zu finden, während noch Puffer vorhanden ist. Das bedeutet, führende Indikatoren zu überwachen, SLOs mit Fehlerbudgets zu definieren und das System aktiv zu testen, anstatt auf seinen Ausfall zu warten.
Ein SLO wandelt Zuverlässigkeit in eine Zahl um (z. B. 99,9% der Anfragen erfolgreich). Die restlichen 0,1% sind dein Fehlerbudget. Das Verfolgen der Burn Rate ermöglicht es dir, zu warnen, wenn du das Budget zu schnell aufbrauchst — lange bevor du die SLO tatsächlich verletzt und Benutzer es bemerken.
SLO 99.9% → 0.1% error budget/month (~43 min of downtime)
burn rate rising fast → you'll exhaust it in 2 days → alert NOW, while it's fixable
SYNTHETIC MONITORING scripted checks hit critical paths on a schedule
(login, checkout) → fails even at 3am with zero real traffic
HEALTH CHECKS /healthz endpoints + dependency checks → load balancer
pulls bad instances before users hit them
RUM (real-user mon.) measure latency/errors from actual browsers/devices →
catches issues only some users/regions see
Synthetisches Monitoring ist leistungsstark, weil es nicht auf einen Benutzer wartet — es testet das System kontinuierlich, sodass ein defekter Checkout um 3 Uhr morgens gefunden wird, nicht wenn der morgendliche Ansturm sich beschwert.
Die frühesten Anzeichen finden sich in Ressourcen, nicht in benutzergerichteten Fehlern. Warne bei Trends, nicht nur bei einer statischen Linie.
LEADING INDICATORS saturation (CPU/mem climbing), queue depth growing,
connection-pool nearing limit, latency CREEPING up
ANOMALY DETECTION flag deviation from the normal baseline / seasonality
TREND ALERTS "disk will fill in 4h at this rate" → act before it's full
Ein langsam steigender p99 oder eine wachsende Queue ist ein Warnschuss: Durch das Handeln gegen das allmähliche Wachstum verhinderst du den Ausfall, auf den das Wachstum zusteuerte.
Reaktives Monitoring bedeutet, dass Benutzer dein Alerting-System sind — wenn sie sich beschweren, läuft der Incident bereits und dein Fehlerbudget ist aufgebraucht. Proaktive Erkennung (SLO-Burn Rate, Synthetics, Health Checks, RUM, führende Indikatoren, Trend-/Anomalienwarnungen) kauft dir Zeit: Du behebst eine gesättigte Queue oder steigende Latenz, bevor es um 2 Uhr morgens anruft und ein wütender Kunde ist. Diese Zeit ist der Unterschied zwischen einer ruhigen Behebung und einem Ausfall.