Was unterscheidet Observability von Monitoring?
Monitoring prüft bekannte Metriken gegen Schwellwerte. Observability geht weiter: Durch die Kombination von Logs, Metriken und Traces lassen sich auch unbekannte Probleme diagnostizieren, ohne vorher zu wissen, wonach man sucht. Die drei Säulen Logs, Metrics und Traces ergeben zusammen ein vollständiges Bild des Systemverhaltens.
Auch bekannt als: Beobachtbarkeit · Observability Engineering · O11y
Ist Observability bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Der Begriff stammt aus der Regelungstechnik. Rudolf Kálmán nannte 1960 ein System beobachtbar, wenn sich sein innerer Zustand aus den messbaren Ausgängen rekonstruieren lässt. In der Software sind diese Ausgänge die Telemetriedaten, die eine Anwendung selbst erzeugt. Dafür wird der Code instrumentiert: Er schreibt strukturierte Logs, zählt Anfragen und Fehler als Metriken und vergibt jeder Anfrage eine Trace-ID, die sie über alle beteiligten Services begleitet. Ein Collector sammelt die Daten ein und schickt sie an Speicher und Oberflächen, in denen das Team später Fragen stellen kann, die beim Programmieren noch niemand kannte.
Den Standard für diese Instrumentierung setzt heute OpenTelemetry. Das Projekt der Cloud Native Computing Foundation (CNCF) entstand 2019 aus dem Zusammenschluss von OpenTracing und OpenCensus und liefert Programmbibliotheken, einen Collector und das Übertragungsprotokoll OTLP für Traces, Metriken und Logs. OpenTelemetry speichert selbst nichts. Es erzeugt und verschickt die Daten an Backends wie Prometheus, Jaeger oder kommerzielle Plattformen. Wer so instrumentiert, kann das Backend später wechseln, ohne den Code jeder Anwendung anzufassen.
Monitoring bleibt dabei ein Teil des Ganzen. Es prüft die Größen, deren Grenzwerte das Team kennt, und schlägt Alarm. Observability beginnt dort, wo der Alarm feuert und die Ursache unbekannt ist. In einer Architektur aus vielen Services und Containern gibt es zu viele mögliche Fehlerzustände, um für jeden vorab einen Alarm zu definieren. Deshalb braucht das Team Daten, in denen es nachträglich suchen kann.
In der Industrie entscheidet Observability darüber, wie lange eine Störung dauert. Ohne saubere Telemetrie beginnt die Suche mit SSH-Sitzungen auf fünf Servern und Logdateien ohne gemeinsame ID, während die Anlage steht. Der teure Fehler ist die unstrukturierte Datenflut: Logs ohne Korrelations-IDs und Metriken ohne Labels für Anlage und Standort kosten Speicher und liefern keine Antwort. Legen Sie die Namenskonventionen für Labels deshalb fest, bevor die ersten Services instrumentiert werden, denn nachträglich umzubenennen heißt, jedes Dashboard neu zu bauen.
Ein Trace findet die Latenzspitze, die monatelang ein Phantom war
Ein IT-Unternehmen sah sporadische Latenzspitzen in seiner Bestell-API und konnte sie in keinem Log wiederfinden. Es instrumentiert alle Services mit OpenTelemetry und verfolgt einzelne Anfragen über die Dienstgrenzen hinweg. Schon der erste aufgezeichnete Trace einer langsamen Anfrage zeigt die Ursache, einen überlasteten Downstream-Service, der bei jedem Aufruf mehrere Sekunden wartete.
Korrelations-IDs verbinden Maschinen-Log und IT-Ereignis
Ein Industrieunternehmen führte die Logs seiner Edge-Geräte und seiner IT-Systeme in getrennten Werkzeugen, und bei jedem Vorfall verglichen zwei Teams Zeitstempel per Telefon. Es versieht alle Logs mit einheitlichen Korrelations-IDs und Labels für Anlage und Linie. Ein Maschinenstopp und das fehlgeschlagene Konfigurations-Update, das ihn ausgelöst hat, erscheinen jetzt in derselben Suche.
Wo starten Sie mit Observability?
Observability macht Systeme durchschaubar — der beste Einstieg hängt an Ihrem heutigen Blick und Ihrem Ziel. Zwei Klicks geben die Richtung.
Wie viel Sicht haben Sie heute?
- Was sind die drei Säulen der Observability?
- Die drei Säulen sind Logs, Metrics und Traces. Logs erfassen einzelne Ereignisse, Metrics liefern Zeitreihen wie Auslastung oder Fehlerrate, und Traces zeigen den Weg einer Anfrage durch verteilte Systeme. Erst zusammen ergeben sie ein brauchbares Bild, weil etwa eine Metrik zeigt, dass Fehler zunehmen, und erst der Trace verrät, in welchem Service sie entstehen.
- Was ist der Unterschied zwischen Monitoring und Observability?
- Monitoring überwacht bekannte Größen gegen festgelegte Schwellwerte und meldet, dass etwas nicht stimmt. Observability erlaubt, auch unbekannte Probleme zu untersuchen und herauszufinden, warum etwas nicht stimmt. Monitoring ist damit ein Teil von Observability, der ohne die Daten dahinter bei neuartigen Störungen nicht weiterhilft.
- Was sind die vier Golden Signals?
- Die vier Golden Signals sind Latency, Traffic, Errors und Saturation, beschrieben im Google-SRE-Buch. Latency ist die Zeit für die Bearbeitung einer Anfrage, Traffic die Last auf dem System, Errors die Rate fehlgeschlagener Anfragen und Saturation, wie ausgelastet die knappste Ressource ist. Wer nur vier Werte pro Service überwachen kann, sollte laut Google diese vier nehmen.
- Ist Grafana ein Observability-Tool?
- Ja, Grafana ist die Oberfläche, in der viele Teams ihre Observability-Daten auswerten, speichert Telemetrie aber nicht selbst. Die Daten kommen aus Backends wie Prometheus für Metriken, Loki oder Elasticsearch für Logs und Jaeger oder Tempo für Traces. Grafana verbindet diese Quellen in einem Dashboard.
- Was ist OpenTelemetry?
- OpenTelemetry ist ein herstellerneutraler Open-Source-Standard der CNCF, um Traces, Metriken und Logs zu erzeugen und zu übertragen. Es besteht aus Bibliotheken für die Instrumentierung, dem Collector und dem Protokoll OTLP. Als Backend dient es nicht, die Daten landen in Werkzeugen wie Prometheus oder Jaeger.
Wo steht Ihr Team bei Observability?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Weiterführende Primärquellen zu Observability: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01OpenTelemetryWhat is OpenTelemetry?(externe Seite, öffnet in neuem Tab)
Der herstellerneutrale Standard für Traces, Metriken und Logs.
- /02Google SRE BookMonitoring Distributed Systems(externe Seite, öffnet in neuem Tab)
Die vier goldenen Signale und der Unterschied zwischen Symptom und Ursache.
- /03PrometheusPrometheus Overview(externe Seite, öffnet in neuem Tab)
Metrikmodell und Abfragesprache als praktischer Einstieg in die Messseite.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance