Was ist Observability?
Beobachtbarkeit
Observability, auf Deutsch Beobachtbarkeit, ist die Eigenschaft eines IT-Systems, dass sich sein innerer Zustand aus den Daten ableiten lässt, die es nach außen liefert, vor allem aus Metriken, Logs und Traces. Ist sie gegeben, kannst du auch eine Störung erklären, an die bei der Einrichtung der Überwachung niemand gedacht hat.
Die Störung, die dich um drei Uhr nachts weckt, steht selten in einem Dashboard, das jemand vorher für genau diesen Fall gebaut hat.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
- Drei Datenarten
- Metriken, Logs und Traces
- Ist
- Eine Eigenschaft des Systems, kein Werkzeug
- Steuert über
- SLI und SLO statt Bauchgefühl
- Erfassung
- OpenTelemetry, unabhängig vom Werkzeug
Was der Begriff bedeutet
Der Begriff stammt aus der Regelungstechnik. Der Ingenieur Rudolf E. Kálmán beschrieb 1960 ein System als beobachtbar, wenn sich sein innerer Zustand allein aus den Messwerten an seinen Ausgängen bestimmen lässt. In die IT kam das Wort mit verteilten Anwendungen aus vielen Diensten, bei denen klassische Überwachung nicht mehr ausreichte, um Fehler zu finden.
Wichtig ist der Unterschied zwischen Eigenschaft und Werkzeug. Observability kaufst du nicht als Produkt, du baust sie in deine Anwendungen ein, indem sie aussagekräftige Daten liefern. Werkzeuge wie Prometheus, Grafana, Jaeger, Elastic, Datadog oder Dynatrace speichern und visualisieren diese Daten. Sind die Daten dünn oder nicht miteinander verknüpft, hilft auch das teuerste Werkzeug nicht.
Drei Datenarten, die erst zusammen etwas taugen
Die drei Datenarten werden oft die drei Säulen der Observability genannt. Jede beantwortet eine andere Frage:
| Datenart | Beantwortet | Beispiel | Typische Werkzeuge |
|---|---|---|---|
| Metriken | Stimmt etwas nicht? | Fehlerquote steigt auf 4 Prozent | Prometheus, Grafana Mimir |
| Logs | Was genau ist passiert? | Zeitüberschreitung beim Zahlungsdienst | Loki, Elasticsearch, OpenSearch |
| Traces | Wo geht die Zeit verloren? | Anfrage hängt 2 Sekunden im Lagerdienst | Jaeger, Grafana Tempo |
Der Nutzen entsteht durch die Verbindung. Wenn in der Metrik eine Fehlerspitze auftaucht, willst du von dort direkt zu den betroffenen Traces springen und von einem Trace zu den Logs des passenden Dienstes. Dafür muss eine gemeinsame Kennung, die Trace-ID, durch alle drei Datenarten laufen. Fehlt sie, hast du drei nebeneinanderstehende Werkzeuge und trotzdem kein zusammenhängendes Bild. Zunehmend kommt als vierte Datenart das Profiling dazu, das zeigt, welche Codezeilen Rechenzeit und Speicher verbrauchen.
Überwachung beantwortet bekannte Fragen, Observability unbekannte
Klassische Überwachung prüft vorher festgelegte Bedingungen: Ist die Platte voll, antwortet der Dienst, überschreitet die Last einen Wert. Das funktioniert gut, solange die Fehlerbilder bekannt sind. Bei verteilten Systemen sind sie das selten, dort scheitert eine Anfrage etwa, weil ein bestimmter Aufruf nur für bestimmte Kunden in einer bestimmten Region langsam wird.
Observability zielt darauf, solche Fragen nachträglich stellen zu können, ohne vorher eine passende Messung eingebaut zu haben. Die Voraussetzung dafür sind ausreichend detaillierte Daten mit brauchbaren Merkmalen wie Kunde, Version oder Region. Genau diese Merkmale treiben allerdings auch die Kosten, weil in einer Metrik jede zusätzliche Ausprägung eine neue Zeitreihe erzeugt. Angaben mit sehr vielen möglichen Werten, etwa eine Benutzer- oder Anfragekennung, gehören deshalb in Logs und Traces, nicht in Metriken.
SLI und SLO statt Schwellenwert aus dem Bauch
Ein Service Level Indicator (SLI) ist eine Messgröße, die dem Nutzererlebnis entspricht, etwa der Anteil erfolgreicher Anfragen, die in unter einer Sekunde beantwortet werden. Das Service Level Objective (SLO) ist das Ziel dazu, beispielsweise 99,5 Prozent über 30 Tage. Der verbleibende Rest ist das Fehlerbudget: Bei 99,5 Prozent Verfügbarkeit über 30 Tage sind das rund 3,6 Stunden, in denen der Dienst gestört sein darf.
Alarme auf dieser Grundlage schlagen an, wenn das Budget schnell verbraucht wird, und nicht bei jeder überschrittenen CPU-Auslastung. Das reduziert nächtliche Meldungen ohne Handlungsbedarf erheblich, weil nur noch das gemeldet wird, was Nutzer tatsächlich betrifft.
Wie lange Logs, Traces und Metriken aufbewahren?
Eine gesetzlich vorgeschriebene Einheitsfrist für Betriebsdaten gibt es nicht. Auch NIS2 und das BSI-Gesetz verlangen Protokollierung und die Fähigkeit, Vorfälle aufzuklären, nennen aber keine feste Zahl an Monaten. Die Dauer leitest du deshalb aus dem Zweck jeder Datenklasse ab, nicht aus dem Speicherplatz:
| Datenklasse | Wofür gebraucht | Orientierung |
|---|---|---|
| Traces | Fehlersuche bei aktuellen Störungen | Kurz: Tage bis wenige Wochen, oft nur eine Stichprobe |
| Betriebslogs | Fehleranalyse, Vergleich vor und nach einem Release | Wochen, so lange wie ein typischer Analysezeitraum |
| Sicherheitsrelevante Logs | Aufklärung von Angriffen, die oft erst spät auffallen | Deutlich länger, häufig Monate, schriftlich begründet |
| Metriken | Trends und Kapazitätsplanung | Fein aufgelöst kurz, verdichtet über ein Jahr und länger |
Gegen zu lange Speicherung steht der Datenschutz. Logs enthalten fast immer personenbezogene Daten wie IP-Adressen oder Benutzerkennungen, und nach dem Grundsatz der Speicherbegrenzung in Art. 5 DSGVO dürfen sie nur so lange liegen, wie der Zweck es verlangt. Lassen sich mit den Daten Leistung oder Verhalten von Beschäftigten auswerten, hat der Betriebsrat nach § 87 Abs. 1 Nr. 6 BetrVG mitzubestimmen. Halte die Fristen je Datenklasse deshalb in einem Löschkonzept fest und stimme sie mit Datenschutz und gegebenenfalls Betriebsrat ab.
OpenTelemetry trennt Erfassung vom Werkzeug
OpenTelemetry ist ein herstellerunabhängiger Standard für das Erfassen und Übertragen von Metriken, Logs und Traces, mit Bibliotheken für die gängigen Programmiersprachen und einem Sammeldienst, dem Collector. Der Vorteil ist handfest: Die Instrumentierung im Code bleibt gleich, auch wenn das auswertende System gewechselt wird.
In der Umsetzung lohnt es sich, den Collector als eigene Instanz zu betreiben statt direkt an das Zielsystem zu senden. Dort lassen sich Daten anreichern, personenbezogene Felder entfernen, Aufbewahrungsklassen zuordnen und die Menge über eine Stichprobenregel begrenzen, ohne jede Anwendung erneut anzufassen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Observability und was oft damit gleichgesetzt wird
Überwachung prüft vorher definierte Bedingungen und alarmiert bei Abweichung. Observability ist die Eigenschaft eines Systems, auch unvorhergesehene Fragen beantworten zu können. Das eine schließt das andere nicht aus, gute Überwachung bleibt die Grundlage.
Application Performance Monitoring ist die auf Anwendungen gerichtete Ausprägung, meist mit fertiger Instrumentierung eines Herstellers. Observability ist der breitere Anspruch und schließt Infrastruktur, Netzwerk und das Zusammenspiel der Dienste ein.
Protokollierung ist eine der drei Datenarten. Wer nur Logs sammelt, hat viel Text und wenig Übersicht, weil Zeitreihen für Trends und Traces für den Weg einer Anfrage über mehrere Dienste fehlen.
Ein SIEM sammelt ebenfalls Logs, wertet sie aber auf Sicherheitsvorfälle hin aus, etwa Anmeldeversuche oder verdächtige Zugriffe. Observability dient dem Betrieb und der Fehlersuche. Oft speisen dieselben Quellen beide Systeme.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Gesammelt wird alles, zusammengeführt wird nichts
Drei Werkzeuge, drei Zeitachsen, keine gemeinsame Kennung: Dann springst du bei einer Störung zwischen Oberflächen hin und her und rätst, welcher Ausschlag zu welchem Protokolleintrag gehört. Der wirksamste einzelne Schritt ist eine Kennung, die eine Anfrage von der ersten Komponente bis zur letzten begleitet und in jedem Protokolleintrag mitsteht. Danach ist der Sprung vom langsamen Aufruf zum passenden Fehler ein Klick statt einer Suche.
Die Kosten kippen fast immer über Merkmale mit zu vielen möglichen Werten und über ungeplante Aufbewahrung. Wer Benutzerkennung, Sitzung oder eine vollständige Adresse als Merkmal an eine Metrik hängt, erzeugt für jede Kombination eine eigene Zeitreihe, und die Datenbank wächst, bis sie kippt. Stichproben für Traces, die Fehlerfälle vollständig behalten und den Rest ausdünnen, und Fristen je Datenklasse legst du besser vorher fest als nach der ersten Rechnung.
Und Instrumentierung wird zu oft erst nach dem großen Vorfall nachgerüstet. Für die meisten Sprachen erfasst OpenTelemetry Aufrufe von Webframeworks, Datenbanken und HTTP-Clients automatisch, ohne dass der Code geändert werden muss. Wer das beim nächsten Release einschaltet, hat bei der nächsten Störung schon Traces, statt sie sich zu wünschen.
Observability lernen
Wie du Messwerte erhebst, sinnvoll darstellst und Alarme so schneidest, dass sie nicht ignoriert werden, üben die Kurse zu Prometheus, Grafana und Checkmk.
Weil die meisten verteilten Systeme heute auf Containerplattformen laufen, ergänzen sich diese Inhalte gut mit den Kursen zum Betrieb von Kubernetes-Umgebungen.
Sitzt Observability schon?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Kurse, die Observability behandeln
Häufige Fragen
Brauche ich Traces, wenn ich nur eine große Anwendung betreibe?
Welche Aufbewahrungsdauer sollte ich für Traces und Logs setzen?
Was gehört in einen Alarm, der nachts jemanden weckt?
Ist Observability nur etwas für Cloud und Kubernetes?
Passt thematisch dazu
Wie du Aufbewahrungsfristen und Unveränderbarkeit zentraler Logs unter NIS2 konkret umsetzt, zeigt eine eigene Anleitung.
Den nächsten Schritt, die Einführung von OpenTelemetry im laufenden Betrieb, beschreibt ein Beitrag mit Collector-Aufbau und Stichprobenregeln.
Deine Ansprechpartner
Du willst das Thema nicht nur nachschlagen, sondern anwenden können? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Ordnet mit dir ein, welcher Kurs zu deinem Vorwissen passt.
Norbert Jansen
Beratung & Inhouse
Plant Inhouse-Trainings, die an euren eigenen Daten und Abläufen ansetzen.
Observability im Kurs statt im Lexikon
Nachschlagen bringt dich bis zum Verstehen. Anwenden lernst du an echten Aufgaben.