Der echte Test von Monitoring sind nicht Dashboards
Jedes Team kann Dashboards bauen. Der echte Test eines Monitoring-Systems ist 3 Uhr morgens, wenn ein Pager losgeht: Weiß der Engineer sofort, was zu tun ist — oder verbringt er die ersten 20 Minuten in irrelevanten Graphen? Wenn Letzteres, ist Ihr Monitoring Theater.
Dieser Leitfaden ist ein strukturierter Gang durch Monitoring, das keinen Fehlalarm schlägt: vier goldene Signale als Fundament, SLI/SLO/Error Budgets in Klartext, Alert-Hygiene-Regeln und eine Audit-Checkliste für bestehendes Monitoring.
Gliederung
- Die vier goldenen Signale
- SLI, SLO und Error Budgets ohne Jargon
- Alert-Hygiene — Regeln, die Menschen schützen
- Logs vs. Metriken vs. Traces: wann was
- Synthetisches Monitoring und Real-User-Monitoring
- Tool-Stack wählen
- Vernünftiges On-Call für kleine Teams
- Audit-Checkliste für bestehendes Monitoring
1. Die vier goldenen Signale
Für jeden nutzerorientierten Service messen Sie diese vier zuerst — und nichts anderes:
- Latency — Zeit für eine erfolgreiche Antwort. p50, p95, p99.
- Traffic — Requests pro Sekunde oder Business-Äquivalent (Bestellungen/min).
- Errors — fehlgeschlagene Requests als Rate, nach Kategorie aufgeschlüsselt.
- Saturation — wie voll das System ist (CPU, RAM, Queue-Tiefe, Connection-Pools).
Diese vier richtig — und Sie haben 80 % der Incidents abgedeckt. Infrastruktur-Metriken (Disk, Netz, Host-Health) erst, wenn sie wirklich Business-Impact vorhersagen.
2. SLI, SLO und Error Budgets in Klartext
- SLI ist, was Sie messen: „% der Requests unter 300 ms".
- SLO ist das Ziel: „99,5 % der Requests unter 300 ms über 30 Tage".
- Error Budget ist, was Sie ausgeben dürfen: 0,5 % in diesem Beispiel.
Error Budgets sind keine Strafe. Sie machen den Trade-off zwischen Stabilität und Feature-Geschwindigkeit explizit. Wenn das Budget des Monats verbrannt ist, friert man neue Features ein und investiert in Stabilität — eine Leadership-Entscheidung, kein Engineer-Drama.
3. Alert-Hygiene — Regeln, die Menschen schützen
- Jeder Alert braucht ein Runbook. Sonst ist es ein Ticket, kein Alert.
- Jeder Alert weckt einen Menschen oder geht ins Backlog. Keine dritte Kategorie.
- Akku-Alerts (Rate-of-Change) statt fester Schwellen, wo Baselines sauber sind.
- Symptom-Alerts vor Ursache-Alerts. „Service antwortet nicht" schlägt „CPU > 80 %".
- Wöchentlich die Top-5 lautesten Alerts prüfen und drei abschalten oder tunen.
Ein Team, das zweimal pro Woche mit echten, actionable Incidents gepaged wird, ist gesünder als eines mit 30 Pages voll Rauschen.
4. Logs vs. Metriken vs. Traces
| Signal | Am besten für | Am schlechtesten für |
|---|---|---|
| Metriken | Alerting, SLOs, Dashboards | Warum ein bestimmter Request fehlschlug |
| Logs | Forensik, Audit, Debug | High-Cardinality-Dashboards (Kosten explodieren) |
| Traces | Latenz-Root-Cause über Services | Günstige Langzeitspeicherung |
Loggen Sie nicht, was eine Metrik sein sollte. Tracen Sie nicht, was ein Log sein sollte.
5. Synthetisches Monitoring und Real-User-Monitoring
Synthetisch (gescriptete Checks von extern, jede Minute) fängt Ausfälle und Zertifikatsabläufe, bevor Nutzer es merken. Real-User-Monitoring (RUM) zeigt, was Nutzer tatsächlich erleben — inklusive langsamer Netze und alter Browser, die Ihr Staging nicht hat.
Beides laufen lassen. Aus synthetisch alerten. Aus RUM investigieren.
6. Tool-Stack wählen
Keinen einzig richtigen Stack. Die ehrliche Matrix:
- Prometheus + Grafana + Loki + Tempo — beste TCO für Teams mit einem Engineer, der das gern betreibt. Schlimmste TCO für Teams ohne.
- Zabbix — stark für infrastruktur-lastige Umgebungen, On-Prem, gemischte Linux/Windows-Flotten. Schwächer bei Application-Observability.
- Datadog / New Relic / Dynatrace — schnellste Time-to-Value, höchster Preis, Lock-in über proprietäres Datenmodell. Oft korrekt für 20–100-Personen-Firmen, die die Plattform nicht selbst betreiben wollen.
- Hyperscaler-nativ (CloudWatch, Azure Monitor, GCP Cloud Monitoring) — bequem, schwächer cross-cloud oder cross-on-prem.
Drei Kriterien: 3-Jahres-TCO (inkl. Engineer-Zeit), Datenportabilität, Wollen die On-Call-Engineers das Tool nutzen?
7. Vernünftiges On-Call für kleine Teams
- Mindestens zwei On-Call-Engineers. Einer ist Single Point of Failure.
- Primary rotiert wöchentlich. Secondary deckt Primary ab. Kein 24/7-Single-Pager-Held.
- Übergabe jeden Montag: offene Incidents, lauteste Alerts, was diese Woche zu fixen ist.
- Vergütungsregel schriftlich.
- Nach jedem Incident: fünfzeilige Postmortem in Shared Docs. Blameless, fokussiert auf Systeme.
8. Audit-Checkliste für bestehendes Monitoring
- Sind die vier goldenen Signale für jeden nutzerorientierten Service vorhanden?
- Hat jeder aktive Alert ein schriftliches Runbook?
- Wöchentliches Alert-Volumen vs. menschliche Eingriffe?
- Wann wurde der letzte synthetische Monitor Ihres kritischsten Flows erfolgreich ausgeführt?
- Sind Logs und Metriken am selben Ort (mindestens in derselben UI)?
- Kostet Ihr Tool in 12 Monaten bei prognostiziertem Wachstum noch das, was es soll?
- Ist die On-Call-Rotation dokumentiert, vergütet und ohne Single-Point-of-Failure?
Können Sie eine davon nicht in einem Satz beantworten — da fängt die Arbeit an.
Kernaussagen
- Bauen Sie auf den vier goldenen Signalen auf, nicht auf Infrastruktur-Trivia.
- Error Budgets sind ein Leadership-Gespräch über Geschwindigkeit vs. Stabilität.
- Jeder Alert braucht Runbook und Aktion; alles andere ist ein Ticket.
- Logs, Metriken und Traces ergänzen sich — sie ersetzen sich nicht.
- Tool-Wahl ist eine 3-Jahres-TCO-Entscheidung, keine Feature-Checkbox.
Wenn Sie eine externe Prüfung Ihres aktuellen Monitorings gegen diese Checkliste wünschen, nehmen Sie Kontakt auf — Sie sprechen mit einem Ingenieur, nicht mit einem Vertriebler.