Observability vs. Monitoring beschreibt zwei sich ergänzende Ansätze: Monitoring erfasst vordefinierte Metriken und alarmiert, wenn bekannte Bedingungen verletzt werden – es zeigt, dass etwas nicht stimmt. Observability ist die Fähigkeit, reichhaltige, korrelierte Telemetrie zu untersuchen, um zu verstehen, warum etwas nicht stimmt, auch bei unvorhergesehenen Fehlerbildern.
Das Wichtigste in Kürze
- Monitoring beantwortet bekannte Fragen (Known Unknowns) mit Dashboards und Schwellwert-Alerts; Observability ermöglicht die Untersuchung neuer Fragen (Unknown Unknowns).
- Beide sind keine Konkurrenten: Monitoring ist eine Praxis, die auf beobachtbaren Systemen aufsetzt und für das Alerting unverzichtbar bleibt.
- Die praktischen Unterschiede liegen im Datenmodell (Aggregate vs. Events mit hoher Kardinalität), in der Korrelation der Signale und im Tempo der Ad-hoc-Analyse.
- Teams entwickeln sich meist schrittweise vom Monitoring zur Observability: einheitliche Instrumentierung, korrelierte Signale, SLO-basiertes Alerting.
Observability vs. Monitoring: die kurze Antwort
Die Diskussion um Observability vs. Monitoring klingt oft wie ein Streit zwischen alter und neuer Idee. Das ist sie nicht. Monitoring ist die Praxis, ein System gegen vorab definierte Erwartungen zu überwachen: Sie legen fest, welche Metriken wichtig sind, setzen Schwellwerte und werden alarmiert, wenn diese überschritten werden. Observability ist eine Eigenschaft des Systems und seiner Telemetrie: wie gut sich sein Verhalten aus den erzeugten Daten erklären lässt – auch Verhalten, mit dem niemand gerechnet hat.
Kurz gesagt: Monitoring zeigt Ihnen, dass etwas nicht stimmt; Observability hilft zu verstehen, warum. Monitoring deckt die Known Unknowns ab, also absehbare Fehlerbilder wie eine volle Festplatte oder einen Anstieg von HTTP-500-Fehlern. Observability zielt auf die Unknown Unknowns, etwa eine Latenzverschlechterung, die nur einen Mandanten nach einem bestimmten Deployment bei kaltem Cache trifft.
Was Monitoring ist und was es gut kann
Monitoring gehört seit Jahrzehnten zum IT-Betrieb, lange vor der Cloud. Ein typisches Monitoring-Setup sammelt eine kuratierte Auswahl an Metriken von Hosts, Services und Netzwerkgeräten, stellt sie in Dashboards dar und wertet Alert-Regeln aus. Uptime-Checks, CPU- und Speichergraphen, Alerts auf Queue-Längen und Schwellwerte für Fehlerraten sind klassisches Monitoring.
Für mehrere Aufgaben ist Monitoring hervorragend geeignet:
- Bekannte Fehlerbilder schnell erkennen. Wenn Sie wissen, dass eine volle Platte die Datenbank lahmlegt, ist ein Alert auf die Plattenbelegung das richtige Werkzeug.
- Trends verfolgen. Kapazitätsplanung, Kostenentwicklung und saisonale Lastmuster sind typische Monitoring-Aufgaben.
- Zustand auf einen Blick. Wenige, gut gewählte Dashboards geben Bereitschaftsdienst und Management ein gemeinsames Lagebild.
- Compliance und Reporting. Verfügbarkeitsberichte und SLA-Nachweise beruhen auf konsistenten, langfristigen Metriken.
Die Grenze ist struktureller Natur: Monitoring kann nur Fragen beantworten, die jemand vor dem Incident gestellt hat. Die Daten sind meist voraggregiert, sodass einzelne Requests in Durchschnitten und Perzentilen verschwinden. Kontext wie Nutzer, Mandant oder Build-Version wird häufig entfernt, damit die Kardinalität der Metriken bezahlbar bleibt.
Was Observability ergänzt
Observability erweitert dieses Fundament um Daten und Werkzeuge, die für die Untersuchung gebaut sind. Statt nur Aggregate zu speichern, erzeugt ein beobachtbares System detaillierte, strukturierte Telemetrie – Traces mit Spans für jeden Hop, strukturierte Logs und Continuous Profiles – mit aussagekräftigen Attributen und gemeinsamen IDs, die die Signale miteinander verknüpfen.
Das verändert den Debugging-Ablauf grundlegend. Statt zwischen Dashboards hin- und herzuspringen und zu hoffen, dass eines die Ursache zeigt, beginnt ein Engineer beim Symptom und stellt immer präzisere Fragen: Welche Endpunkte sind langsam, für welche Kunden, seit welchem Deployment und in welchem nachgelagerten Aufruf? Jede Antwort verkleinert den Suchraum, bis die Ursache isoliert ist. Entscheidend: Keine dieser Fragen musste vorab vorhergesehen werden.
Der direkte Vergleich
| Dimension | Monitoring | Observability |
|---|---|---|
| Kernfrage | Funktioniert das System wie erwartet? | Warum verhält sich das System so? |
| Art von Problemen | Known Unknowns, vorhersehbare Ausfälle | Unknown Unknowns, neuartige und emergente Fehler |
| Charakter | Eine Tätigkeit bzw. Praxis | Eine Eigenschaft des Systems und seiner Telemetrie |
| Typische Daten | Voraggregierte Metriken, Health Checks, einige Logs | Korrelierte Metriken, Logs, Traces, Profile und Events mit hoher Kardinalität |
| Hauptwerkzeug | Dashboards und Schwellwert-Alerts | Ad-hoc-Abfragen, Trace-Analyse, Drill-down über Signale hinweg |
| Kontext | Meist pro Komponente (Host, Service) | Ende-zu-Ende über Services, Nutzer und Deployments |
| Passt am besten zu | Stabilen, gut verstandenen Systemen und Infrastruktur-Health | Verteilten, sich schnell ändernden Cloud-nativen Systemen |
| Ergebnis | Alerts und Status | Erklärungen und Grundursachen |
Wie Monitoring und Observability zusammenspielen
Die Gegenüberstellung „Observability vs. Monitoring“ kann in die Irre führen, denn reife Teams nutzen beides täglich. Monitoring ist der Rauchmelder; Observability ist die Fähigkeit, durch das Gebäude zu gehen und den Brandherd zu finden. Ein typischer Incident durchläuft beide Welten:
- Erkennen. Ein Alert schlägt an, idealerweise auf eine SLO-Burn-Rate oder ein Golden Signal wie die Fehlerrate der Checkout-API. Das ist Monitoring.
- Eingrenzen. Die Bereitschaft prüft, welche Services, Regionen und Kundensegmente betroffen sind – mit Topologie und Aufschlüsselungen nach Feldern mit hoher Kardinalität.
- Untersuchen. Langsame oder fehlerhafte Traces führen zum konkreten nachgelagerten Aufruf; korrelierte Logs zeigen die Fehlermeldung; ein Profil oder Deployment-Marker erklärt, was sich geändert hat.
- Beheben und prüfen. Nach Rollback oder Fix bestätigen dieselben Monitoring-Signale die Erholung, und das SLO-Budget wird nicht weiter verbraucht.
- Lernen. Im Post-Incident-Review wird das neu entdeckte Fehlerbild zu einem bekannten, oft mit neuem Alert oder SLO. Erkenntnisse aus der Observability fließen zurück ins Monitoring.
Observability macht Monitoring also klüger, und Monitoring hält Observability-Daten handlungsfähig. Ohne Alerts weiß niemand, wann er hinschauen soll; ohne beobachtbare Daten führt der Alert ins Rätselraten.
Ein Praxisbeispiel: ein Incident, zwei Herangehensweisen
Nehmen wir einen Onlineshop mit rund 40 Microservices auf Kubernetes. Am Freitagnachmittag sinkt die Conversion leicht, einige Kunden melden, dass der Checkout „hängt“.
Nur mit Monitoring
Die Dashboards sind überwiegend grün. Die durchschnittliche Checkout-Latenz liegt etwa 15 Prozent höher als sonst, aber deutlich unter dem Alert-Schwellwert. CPU und Speicher aller Nodes sind unauffällig. Die Fehlerrate bleibt flach, weil die Requests am Ende doch erfolgreich sind. Die Bereitschaft prüft die Logs des Payment-Service, findet nichts Auffälliges und startet auf Verdacht Pods neu. Erst Stunden später fällt jemandem auf, dass das Problem nur bei Bestellungen mit einer bestimmten Produktkategorie auftritt.
Mit Observability
Ein SLO-Alert schlägt an, weil der Anteil der Checkout-Requests innerhalb des Latenzziels das Fehlerbudget schneller als üblich aufbraucht. Die Engineerin gruppiert die langsamen Traces nach Attributen und sieht: Die p99-Latenz ist nur bei Requests mit cart.category = "furniture" erhöht, und zwar erst seit dem Deployment des Shipping-Service um 13:05 Uhr. Das Trace-Wasserfalldiagramm zeigt, dass der Shipping-Service nun synchron eine externe Frachtkosten-API aufruft – mit fünf Sekunden Timeout und zwei Retries. Die korrelierten Logs zeigen die Timeouts, der Deployment-Marker die Änderung. Ein Rollback stellt die Latenz innerhalb weniger Minuten wieder her.
Weder das Kategorie-Attribut noch die externe Abhängigkeit tauchte auf irgendeinem Dashboard auf. Den Unterschied machten nicht mehr Alerts, sondern Daten mit genügend Kontext, um im Nachhinein die richtige Frage stellen zu können.
Wo APM und AIOps einzuordnen sind
Application Performance Monitoring (APM) liegt zwischen beiden Welten. Klassische APM-Tools instrumentieren Anwendungen, um Antwortzeiten, Durchsatz und Fehler pro Transaktion zu messen. Das ist reichhaltiger als Infrastruktur-Monitoring, war historisch aber auf vordefinierte Ansichten einzelner Anwendungen ausgerichtet. Modernes APM auf Basis von Distributed Tracing und OpenTelemetry ist heute einer der zentralen Bausteine von Observability.
AIOps, also der Einsatz von Machine Learning im IT-Betrieb, wirkt auf beiden Seiten. Anomalieerkennung und Alert-Korrelation verbessern das Monitoring, weil sie Rauschen reduzieren; KI-gestützte Root-Cause-Analyse beschleunigt den investigativen Teil der Observability. Beides funktioniert nur so gut, wie Telemetrie und Topologie vollständig und korreliert sind.
Der Weg vom Monitoring zur Observability
Die meisten Organisationen ersetzen ihr Monitoring nicht, sondern wachsen darüber hinaus. Ein praxistauglicher Weg:
- Instrumentierung vereinheitlichen mit OpenTelemetry, damit Traces, Metriken und Logs dieselben Ressourcenattribute und Semantic Conventions nutzen.
- Distributed Tracing einführen, zuerst für die geschäftskritischsten User Journeys, inklusive Context Propagation über Queues und asynchrone Jobs.
- Logs mit Traces verknüpfen, indem Trace- und Span-IDs in jede strukturierte Logzeile geschrieben werden.
- Kontext mit hoher Kardinalität erhalten, etwa Kunden-ID, Region, Version und Feature-Flag, und einen Speicher wählen, der diese Daten bezahlbar abfragen kann.
- Auf Symptome alarmieren, nicht auf Ursachen. Ersetzen Sie lange Listen von Ressourcen-Schwellwerten durch SLO-basierte Alerts auf nutzerrelevante Latenz und Fehler.
- Tools konsolidieren, wo zwischen ihnen Kontext verloren geht, damit die Analyse an einem Ort bleibt.
Typische Stolpersteine auf diesem Weg: eine bestehende Dashboard-Sammlung in „Observability“ umzubenennen, ohne Traces oder Kontext zu ergänzen; so aggressiv zu sampeln, dass seltene Fehler verschwinden; und alles zu sammeln, ohne Filter- und Aufbewahrungsstrategie, bis die Kosten schmerzhafte Kürzungen erzwingen.
Messen Sie den Fortschritt nicht an der Zahl der Dashboards, sondern an Ergebnissen: Wie lange dauert es vom Alert bis zur eingegrenzten Ursache? Wie viele Incidents werden zuerst von Kunden statt vom eigenen Alerting gemeldet? Wie oft endet ein Post-Incident-Review mit der Erkenntnis, dass die nötigen Daten fehlten? Diese Kennzahlen zeigen ehrlich, wie beobachtbar Ihre Systeme tatsächlich sind.
Wie Obseria unterstützt
Obseria deckt beide Seiten in einer Plattform ab. Für das Monitoring stehen Dashboards, Alerting, SLOs und Anomalieerkennung auf Metriken aus über 700 integrierten Technologien bereit. Für die Observability speichert Obseria Lake Logs, Traces, Metriken und Profile indexfrei mit Schema-on-Read, sodass Sie Felder mit hoher Kardinalität per OQL, PromQL oder SQL abfragen können, ohne vorab Indizes festzulegen. Obseria TopoGraph bildet Abhängigkeiten automatisch ab, und Obseria Intelligence führt Root-Cause-Analysen mit sichtbarer Beweiskette durch. Die Instrumentierung ist OpenTelemetry-nativ, ein Export per OTLP ist jederzeit möglich.