Was gehört zu echter Observability jenseits von reinem Monitoring?
Direkte Antwort
Monitoring beantwortet vordefinierte Fragen anhand bekannter Metriken ("ist die CPU-Auslastung zu hoch?"). Echte Observability erlaubt es zusätzlich, neue, zuvor nicht vorhergesehene Fragen an ein System zu stellen — durch die Kombination aus Metriken (Prometheus), strukturierten Logs und verteiltem Tracing, die gemeinsam in einem Tool wie Grafana zusammengeführt und korreliert werden.
"Monitoring sagt, ob ein bekanntes Problem vorliegt. Observability erlaubt es, ein unbekanntes Problem überhaupt erst zu finden.
Monitoring-Dashboards, die nur bekannte Kennzahlen zeigen, versagen genau dann, wenn ein unerwartetes Problem auftritt, das keine der vordefinierten Metriken abdeckt.
Die drei Säulen — Metriken, Logs und Traces
Prometheus sammelt numerische Metriken über Zeit (Antwortzeiten, Fehlerraten, Ressourcenverbrauch), strukturierte Logs liefern detaillierten Kontext zu einzelnen Ereignissen, und verteiltes Tracing (etwa mit Jaeger oder OpenTelemetry) zeigt den Weg einer einzelnen Anfrage durch mehrere Microservices.
Erst die Kombination aller drei Datenquellen erlaubt es, bei einem unerwarteten Problem systematisch von einer auffälligen Metrik über zugehörige Logs bis zum genauen Trace der betroffenen Anfrage zu navigieren, statt isoliert nur eine Datenquelle zu betrachten.
Warum reines Dashboard-Monitoring an seine Grenzen stößt
Ein klassisches Monitoring-Dashboard zeigt vordefinierte Kennzahlen, die auf bereits bekannte Fehlerbilder zugeschnitten sind — ein neuartiges Problem, für das noch keine passende Metrik existiert, bleibt dabei unsichtbar, bis es bereits spürbare Auswirkungen zeigt.
Observability-Tools wie Grafana erlauben stattdessen explorative Analyse — etwa das Aufschlüsseln einer Metrik nach beliebigen Dimensionen (Kunde, Region, API-Version), um die eigentliche Ursache eines Problems zu finden, ohne dass diese Aufschlüsselung im Voraus als Dashboard definiert werden musste.
High Cardinality und Kosten als praktische Grenzen
Detaillierte Observability-Daten mit vielen Dimensionen (High Cardinality) erzeugen deutlich mehr Datenvolumen als einfaches Dashboard-Monitoring, was sowohl Speicher- als auch Abfragekosten erhöht.
Ein pragmatischer Ansatz definiert bewusst, welche Dimensionen tatsächlich für die Fehlersuche relevant sind, statt unreflektiert jede denkbare Dimension zu erfassen, um die Kosten in einem vertretbaren Rahmen zu halten.
Wann passt es — wann nicht?
Passt gut
- ✓Das System besteht aus mehreren Services mit komplexen, sich ändernden Fehlerbildern
Passt nicht
- ✗Es gibt eine einzelne, einfache Anwendung mit stabilen, bekannten Fehlerbildern