Was ist Observability?
Beobachtbarkeit
Observability beschreibt, wie gut sich der innere Zustand eines Systems aus seinen Ausgaben ableiten lässt: 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
- Beantwortet
- Auch Fragen, die vorher niemand stellte
- Steuert über
- SLI und SLO statt Bauchgefühl
- Erfassung
- OpenTelemetry, unabhängig vom Werkzeug
Drei Datenarten, die erst zusammen etwas taugen
Metriken sind Zahlenreihen über die Zeit, etwa Antwortzeiten oder Fehlerquoten. Sie sind billig zu speichern und zeigen zuverlässig, dass etwas nicht stimmt. Logs sind Einzelereignisse mit Kontext und beantworten, was genau passiert ist. Traces verfolgen eine einzelne Anfrage über alle beteiligten Dienste hinweg und zeigen, wo die Zeit verloren geht.
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 durch alle drei Datenarten laufen. Fehlt sie, hast du drei nebeneinander stehende Werkzeuge und trotzdem kein zusammenhängendes Bild.
Ü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, 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, etwa Kunde, Version, Region. Genau diese Merkmale treiben allerdings auch die Kosten, weil jede zusätzliche Ausprägung neue Zeitreihen erzeugt.
SLI und SLO statt Schwellenwert aus dem Bauch
Ein Service Level Indicator ist eine Messgröße, die dem Nutzererlebnis entspricht, etwa der Anteil erfolgreicher Anfragen unter einer Sekunde. Das Service Level Objective ist das Ziel dazu, beispielsweise 99,5 Prozent über 30 Tage. Der verbleibende Rest ist das Fehlerbudget und macht sichtbar, wie viel Störung noch verkraftbar ist.
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.
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 Sprachen und einem Sammeldienst dazwischen. Der Vorteil ist handfest: Die Instrumentierung im Code bleibt gleich, auch wenn das auswertende System gewechselt wird.
In der Umsetzung lohnt es sich, den Sammeldienst als eigene Instanz zu betreiben statt direkt an das Zielsystem zu senden. Dort lassen sich Daten anreichern, personenbezogene Felder entfernen und die Menge über eine Auswahlregel 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 und Netzwerk 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 die Verteilung über Dienste fehlen.
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. 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. Solche Angaben gehören in Protokolle und Traces, nicht in Metriken, und Stichproben und Aufbewahrungsfristen legst du besser vorher fest als nach der ersten Rechnung.
Alarme auf Auslastung wecken Leute, ohne dass ein Kunde etwas gemerkt hat, und schulen alle darin, Meldungen wegzuklicken. Sinnvoller ist der Bezug auf das, was zugesagt wurde: Wie viele Anfragen sind schneller als die vereinbarte Grenze beantwortet worden, und wie viel von der zulässigen Abweichung ist diesen Monat noch übrig?
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 Kurse 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.
Häufige Fragen
Brauche ich Traces, wenn ich nur eine große Anwendung betreibe?
Warum werden die Kosten so schnell hoch?
Was gehört in einen Alarm, der nachts jemanden weckt?
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.