Monitoring und Observability werden in vielen Diskussionen als Synonyme verwendet. Das ist ein Missverständnis, das zu falschen Erwartungen und suboptimalen Entscheidungen bei der Werkzeugwahl führt. Monitoring beantwortet die Frage: Ist das System gesund? Observability beantwortet: Warum verhält sich das System so? Wer den Unterschied versteht, kann bessere Entscheidungen darüber treffen, welche Fähigkeiten sein Team wirklich braucht – und wie es sie aufbaut.
Was klassisches Monitoring leistet
Klassisches Monitoring prüft, ob bekannte Bedingungen eingehalten werden. Ein Monitor überprüft, ob eine URL erreichbar ist und eine korrekte Antwort zurückgibt. Ein weiterer Monitor prüft, ob eine Datenbank auf Verbindungen reagiert. Wieder ein anderer überwacht, ob CPU-Auslastung unter einem definierten Schwellwert bleibt. Wenn eine dieser Bedingungen verletzt wird, entsteht ein Alarm.
Monitoring ist in seiner Natur reaktiv und vordefiniert: Es kann nur Probleme erkennen, die vorher als mögliche Problemart beschrieben wurden. Ein Monitor für HTTP-500-Fehler findet HTTP-500-Fehler – aber keine Datenbankabfragen, die zehnmal langsamer als normal laufen, wenn dafür kein Schwellwert konfiguriert wurde. Das ist keine Schwäche des Monitorings. Es ist einfach seine Aufgabe: bekannte Problemtypen zuverlässig und automatisch erkennen.
Was Observability leistet
Observability beschreibt die Eigenschaft eines Systems, aus seinen eigenen Ausgaben heraus vollständig verstanden werden zu können. Ein System gilt als observable, wenn Ingenieure beliebige Fragen über sein internes Verhalten stellen können – auch solche, die vorher nicht antizipiert wurden. Das Konzept stammt aus der Kontrolltheorie: Ein System ist beobachtbar, wenn sein interner Zustand vollständig aus seinen Ausgaben rekonstruiert werden kann.
In der Software bedeutet das: Ein gut observable System produziert strukturierte Logs, aussagekräftige Metriken und verteilte Traces, die es ermöglichen, jeden Aspekt seines Verhaltens zu analysieren. Die entscheidende Eigenschaft ist die Flexibilität: Nicht nur die Fragen zu beantworten, die schon gestellt wurden, sondern auch die, die erst durch einen Vorfall entstehen.
Die drei Säulen der Observability
Observability stützt sich traditionell auf drei Datentypen. Logs sind zeitgestempelte Ereignisaufzeichnungen: Was ist wann passiert? Gut strukturierte Logs – etwa im JSON-Format – lassen sich maschinell auswerten, filtern und mit anderen Daten korrelieren. Sie sind besonders wertvoll für die Analyse seltener, unerwarteter Ereignisse. Metriken sind numerische Zeitreihendaten: CPU-Auslastung über Zeit, Anfragen pro Sekunde, Antwortzeiten als Histogramm. Metriken sind effizient zu speichern, gut für Dashboards und hervorragend geeignet für Alarme basierend auf Schwellwerten.
Distributed Traces schließlich verfolgen den Weg eines Requests durch alle beteiligten Dienste. In Microservice-Architekturen durchläuft eine einzige Nutzeranfrage möglicherweise zehn verschiedene Dienste. Ein Trace zeigt, welcher Dienst wie lange gebraucht hat und wo Fehler aufgetreten sind. Erst die Kombination aller drei Datentypen ergibt das vollständige Bild: Metriken zeigen, dass ein Problem existiert. Logs zeigen, was passiert ist. Traces zeigen, wo im System es passiert ist.
Die Grenze zwischen beiden Konzepten
Monitoring ist ideal für bekannte, wiederkehrende Fehlerbilder: Dienst nicht erreichbar, Zertifikat läuft ab, Antwortzeit überschritten, Heartbeat ausgeblieben. Diese Fälle lassen sich gut definieren und zuverlässig automatisiert erkennen. Für sie ist Monitoring das richtige Werkzeug: verlässlich, automatisch, mit klar definierten Reaktionen.
Observability wird wichtig bei unbekannten Problemen – in der SRE-Community oft als unknown unknowns bezeichnet. Ein Dienst ist erreichbar, antwortet korrekt und zeigt keine Alarme – aber ein bestimmtes Nutzersegment erlebt seltsame Fehler, die sich durch normale Monitoring-Checks nicht erkennen lassen. Oder ein Dienst ist nominell gesund, aber ein bestimmter Endpunkt ist seit zwei Stunden zehnmal langsamer als zuvor. Diese Probleme erfordern explorative Analyse und Hypothesenbildung – genau das, wofür Observability-Werkzeuge konzipiert sind.
Warum beide zusammen nötig sind
Ein häufiges Missverständnis: Observability ersetzt Monitoring. Das ist falsch. Beide Konzepte sind komplementär. Monitoring ist das automatische Sicherheitsnetz für bekannte Probleme: Es arbeitet rund um die Uhr, ohne dass jemand aktiv schauen muss, und benachrichtigt bei Abweichungen. Observability ist das Analyse-Werkzeug: Es ermöglicht tiefes Verstehen, wenn Probleme komplex oder neuartig sind. Teams, die nur auf Monitoring setzen, verlieren die Fähigkeit, unbekannte Probleme zu untersuchen. Teams, die nur auf Observability setzen, müssen aktiv schauen, anstatt automatisch benachrichtigt zu werden.
Die Reihenfolge des Aufbaus sollte pragmatisch sein: Zuerst solides Monitoring etablieren, das bekannte Probleme automatisch erkennt. Dann schrittweise Observability aufbauen: strukturierte Logs, Metriken, schließlich Distributed Tracing. Jeder Schritt liefert sofortigen Mehrwert und baut auf dem vorherigen auf.
Werkzeuge und Praktiken
Im Monitoring-Bereich haben sich externe Uptime-Checks, HTTP-Monitore, Heartbeat-Überwachung und DNS-Monitoring als Grundpfeiler etabliert. Sie bilden die erste Verteidigungslinie gegen Ausfälle. Im Observability-Bereich haben sich standardisierte Formate und offene Protokolle wie OpenTelemetry durchgesetzt, die eine Unabhängigkeit von einzelnen Anbietern ermöglichen. Wer heute Observability aufbaut, sollte auf offene Standards setzen, um später flexibel bei der Wahl der Analysetools zu bleiben.
Fazit
Observability und Monitoring sind keine konkurrierenden Konzepte, sondern verschiedene Schichten derselben Antwort auf die Frage: Was passiert in meinem System? Monitoring liefert die schnelle, zuverlässige Antwort auf bekannte Fragen. Observability liefert die flexible, tiefe Antwort auf unbekannte Fragen. Zusammen bilden sie die Grundlage für verlässliche, gut verstandene Software-Systeme. Den Unterschied zu kennen ist der erste Schritt, beide sinnvoll einzusetzen. In der Praxis beginnen die meisten Teams mit Monitoring und fügen Observability schrittweise hinzu. Das ist sinnvoll, weil Monitoring sofort greifbaren Nutzen liefert: Wenn ein Dienst ausfällt, erhält das Team sofort eine Benachrichtigung. Observability hingegen zeigt ihren Mehrwert erst in komplexen Situationen, wenn die einfachen Antworten des Monitorings nicht mehr ausreichen. Teams, die Observability von Anfang an priorisieren und Monitoring vernachlässigen, verlieren automatische Alarmierung und müssen ständig aktiv nachschauen. Die richtige Strategie ist deshalb: solides Monitoring als zuverlässige Basis zuerst aufbauen, und anschließend schrittweise, gezielt Observability-Fähigkeiten ergänzen – für tieferes Systemverständnis genau in den Bereichen, wo es am dringendsten gebraucht wird und den größten praktischen Mehrwert für das Team liefert.
