Observability (Beobachtbarkeit) ist die Fähigkeit, den inneren Zustand eines Softwaresystems anhand seiner Telemetrie zu verstehen, also anhand von Metriken, Logs, Traces und Profilen. Ein beobachtbares System erlaubt es Engineers, neue und unerwartete Fragen zu seinem Verhalten zu beantworten, ohne neuen Code auszurollen – entscheidend für verteilte Cloud-native Anwendungen.
Das Wichtigste in Kürze
- Observability beschreibt, wie gut sich das Verhalten eines Systems aus seinen Ausgaben erklären lässt – auch bei Fehlerbildern, die niemand vorhergesehen hat.
- Die Grundlage ist korrelierte Telemetrie: Metriken, Logs, Traces und zunehmend Continuous Profiles, verbunden durch gemeinsamen Kontext.
- Monitoring zeigt, dass etwas nicht stimmt; Observability hilft herauszufinden, warum – besonders wichtig bei Microservices und Kubernetes.
- OpenTelemetry ist der herstellerneutrale Standard für diese Telemetrie geworden, Instrumentierung ist damit nicht mehr an ein Tool gebunden.
Observability: eine präzise Definition
Observability ist eine Eigenschaft eines Systems, kein Produkt, das man kauft. Der Begriff stammt aus der Regelungstechnik: Rudolf Kálmán nannte ein System beobachtbar, wenn sich sein innerer Zustand aus seinen äußeren Ausgaben ableiten lässt. In der Softwareentwicklung sind diese Ausgaben Telemetrie – die Kennzahlen, Ereignisse und Request-Pfade, die ein Service im Betrieb erzeugt. Ein System ist gut beobachtbar, wenn diese Telemetrie so reichhaltig und so gut verknüpft ist, dass ein Engineer jedes Verhalten erklären kann, auch solches, an das beim Bau der Dashboards niemand gedacht hat.
Genau dieser letzte Punkt ist entscheidend. Klassisches Monitoring beantwortet vorab definierte Fragen: Liegt die CPU-Auslastung über 90 Prozent, die Fehlerrate über 1 Prozent? Observability zielt auf die Unknown Unknowns: Warum steigt die Checkout-Latenz nur für Nutzer einer bestimmten App-Version, nur in einer Region und nur bei aktivem Feature-Flag? Für jede solche Kombination lässt sich kein Alert im Voraus schreiben. Sie brauchen Daten mit genügend Dimensionen und Kontext, um sie zu filtern, zu vergleichen und bis zur Ursache zu verfolgen.
Warum Observability heute unverzichtbar ist
Vor zehn Jahren lief eine Anwendung oft als Monolith auf wenigen Servern. Bei einer Störung genügte meist ein Blick in eine Logdatei. Heutige Systeme sehen anders aus:
- Verteilte Architekturen. Ein einzelner Request durchläuft API-Gateway, ein Dutzend Microservices, Message Queues, Managed Databases und externe APIs.
- Kurzlebige Infrastruktur. Container und Serverless-Funktionen existieren Minuten oder Sekunden. Wenn Sie mit der Analyse beginnen, ist der betroffene Pod womöglich längst verschwunden.
- Continuous Delivery. Teams deployen mehrmals täglich – das System von heute ist nicht das von letzter Woche.
- Hohe Kardinalität. Probleme betreffen oft nur einen schmalen Ausschnitt des Traffics, definiert durch Nutzer, Mandant, Region, Version oder Flag. Aggregierte Metriken verdecken genau das.
Nicht zu wissen, was passiert, wird in diesem Umfeld teuer: längere Incidents, eine höhere Mean Time to Resolution (MTTR), verfehlte Service Level Objectives (SLOs) und Engineers, die raten statt analysieren. Observability verkürzt den Weg vom Symptom zur Ursache und gibt Teams die Sicherheit, schneller auszuliefern.
Die Signale: Metriken, Logs, Traces und Profile
Häufig ist von den „drei Säulen“ der Observability die Rede. Das ist hilfreiches Vokabular, doch der eigentliche Nutzen entsteht erst durch Korrelation. Heute zählen die meisten Praktiker vier zentrale Signaltypen:
| Signal | Was es ist | Ideal für | Typische Grenze |
|---|---|---|---|
| Metriken | Numerische Messwerte, über die Zeit aggregiert (Counter, Gauges, Histogramme) | Trends, Alerting, SLOs, Kapazitätsplanung | Aggregation verbirgt Einzel-Requests; hohe Kardinalität kostet |
| Logs | Zeitgestempelte Einträge zu einzelnen Ereignissen, idealerweise strukturiert (JSON, Key-Value) | Detaillierter Kontext, Fehler, Audit-Trails | Volumen und Kosten; ohne IDs schwer über Services hinweg zu verfolgen |
| Traces | Der Weg eines einzelnen Requests durch die Services, bestehend aus Spans mit Timing und Attributen | Latenzaufschlüsselung, Abhängigkeiten, langsamen oder fehlerhaften Hop finden | Erfordert Context Propagation; meist gesampelt |
| Profile | Kontinuierliche Stichproben, wo Code CPU, Speicher oder Lock-Zeit verbraucht | Erklären, warum eine Funktion langsam oder teuer ist – bis auf Codezeile | Jüngeres Signal; Tools und Standards reifen noch |
Daneben liefern Real-User-Monitoring-Events (RUM), synthetische Checks, Kubernetes-Events, Deployment-Marker und Business-Events zusätzlichen Kontext. Zu Observability wird dieser Datenbestand erst durch Korrelation: eine Trace-ID in jeder Logzeile, dieselben Ressourcenattribute (Service-Name, Version, Host, Pod) auf jedem Signal und ein Topologiemodell, das weiß, welcher Service von welchem abhängt. Dann gelangen Sie mit wenigen Klicks von einem Latenzanstieg im Metrik-Chart zu den langsamen Traces dahinter, zu den Logs des fehlerhaften Spans und zum Profil der betroffenen Funktion.
So funktioniert Observability in der Praxis
Eine Observability-Praxis besteht aus vier Stufen. Schwächen in einer Stufe begrenzen das Gesamtergebnis:
- Instrumentierung. Code und Infrastruktur erzeugen Telemetrie – über Auto-Instrumentierung, SDKs wie OpenTelemetry, eBPF-basierte Erfassung, Cloud-APIs und Log-Shipper. Gute Instrumentierung liefert konsistente, aussagekräftige Attribute statt nur nackter Zahlen.
- Erfassung und Verarbeitung. Pipelines wie der OpenTelemetry Collector empfangen Daten, bündeln sie, filtern Rauschen, reichern sie an (etwa mit Kubernetes-Labels), maskieren personenbezogene Daten und leiten sie an ein oder mehrere Backends weiter.
- Speicherung und Abfrage. Ein Backend speichert die Signale so, dass sie schnell und flexibel abfragbar sind, auch nach Feldern mit hoher Kardinalität. Das Speicherdesign bestimmt, welche Fragen Sie stellen können und was das kostet.
- Analyse und Handeln. Dashboards, Alerts, SLOs, Trace-Ansichten, Log-Suche und zunehmend KI-gestützte Root-Cause-Analyse machen aus Daten Entscheidungen: jemanden alarmieren, ein Deployment zurückrollen, skalieren, eine Query optimieren.
Ein hilfreiches Denkmodell ist die Debugging-Schleife: Symptom bemerken (oft über einen SLO-Burn-Alert), Hypothese bilden, Daten passend filtern, um sie zu prüfen, und wiederholen, bis die Ursache isoliert ist. Je schneller jede Iteration, desto beobachtbarer ist Ihr System in der Praxis.
Grundbegriffe, die Sie kennen sollten
Einige technische Konzepte entscheiden darüber, ob ein Observability-Setup unter Druck tatsächlich funktioniert.
Kardinalität und Dimensionalität
Kardinalität ist die Anzahl eindeutiger Werte, die ein Feld annehmen kann. Ein Statuscode hat eine Handvoll, eine Nutzer- oder Container-ID womöglich Millionen. Dimensionalität ist die Anzahl der Felder pro Ereignis. Observability braucht beides in hohem Maß, denn schmale Fehlerbilder werden nur sichtbar, wenn Sie nach genau dem Feld gruppieren können, das sie definiert. Backends gehen damit sehr unterschiedlich um: Viele Metrikdatenbanken legen pro eindeutiger Label-Kombination eine eigene Zeitreihe an, was schnell teuer wird. Spaltenorientierte und Lakehouse-artige Speicher können breite Events mit hoher Kardinalität deutlich wirtschaftlicher abfragen.
Context Propagation
Distributed Tracing funktioniert, weil jeder Service einen Trace-Kontext an den nächsten weitergibt, meist über den W3C-Trace-Context-Header traceparent oder entsprechende Metadaten in Nachrichten. Verliert ein Hop diesen Header, zerfällt der Trace in Fragmente. Die Weitergabe des Kontexts über Queues, asynchrone Jobs und Aufrufe externer Dienste ist in realen Systemen eine der häufigsten Lücken.
Sampling
Jeden Trace zu speichern ist im großen Maßstab selten wirtschaftlich. Head-based Sampling entscheidet zu Beginn eines Requests – günstig, aber ohne Wissen über das Ergebnis. Tail-based Sampling wartet, bis ein Trace vollständig ist, und behält Fehler, langsame Requests und seltene Pfade. Das ist für das Debugging wertvoller, erfordert aber eine Collector-Schicht, die Spans zwischenspeichert.
Service Level Objectives
SLOs legen fest, was für Nutzer „gut genug“ bedeutet, etwa dass 99,9 Prozent der Checkout-Requests innerhalb von 30 Tagen in unter 400 ms erfolgreich sind. Sie verbinden Observability-Daten mit geschäftlichen Prioritäten und zeigen Teams, wann Zuverlässigkeitsarbeit Vorrang vor neuen Features haben sollte.
Topologie
Ein aktuelles Abhängigkeitsmodell aus Services, Hosts, Pods und Cloud-Ressourcen beantwortet die Frage, welche Komponenten von einer Störung betroffen sind und welche sie verursacht haben könnten. Ohne Topologie bleibt Korrelation Handarbeit.
Best Practices für Observability
- Auf OpenTelemetry standardisieren. Herstellerneutrale Instrumentierung und Semantic Conventions sorgen für einheitliche Attribute über Teams hinweg und halten das Backend austauschbar.
- Strukturierte Daten mit Kontext. Schreiben Sie strukturierte Logs mit Trace- und Span-IDs. Behandeln Sie Attribute wie Kundensegment, Region und Build-Version als vollwertige Felder.
- Bei nutzernahen Signalen beginnen. Definieren Sie SLOs für Latenz und Fehlerrate kritischer User Journeys und alarmieren Sie auf SLO-Burn statt auf jede CPU-Spitze.
- Bewährte Frameworks nutzen. Golden Signals (Latenz, Traffic, Fehler, Sättigung), RED für Services und USE für Ressourcen helfen bei der Entscheidung, was zuerst gemessen wird.
- Datenvolumen bewusst steuern. Debug-Rauschen beim Ingest filtern, Tail-based Sampling für relevante Traces nutzen und Aufbewahrung nach Wert staffeln.
- Teil des Delivery-Prozesses machen. Instrumentierung gehört in die Definition of Done, Deployments werden in der Telemetrie markiert, Observability-Lücken in jedem Post-Incident-Review besprochen.
Typische Fehler und Stolpersteine
- Tool-Wildwuchs. Getrennte Tools für Metriken, Logs und Traces bedeuten manuelle Korrelation über viele Browser-Tabs – ausgerechnet im Incident, wenn die Zeit knapp ist.
- Dashboards statt Fragen. Hunderte ungenutzte Dashboards machen kein System beobachtbar. Explorative Abfragen sind wichtiger als statische Charts.
- Kardinalität aus Kostengründen streichen. Wer Nutzer-, Mandanten- oder Versionsdimensionen entfernt, spart Geld, verliert aber genau den Kontext für schmale Fehlerbilder.
- Alert-Müdigkeit. Schwellwert-Alerts auf jede Ressourcenmetrik führen dazu, dass Pages ignoriert werden. Wenige, symptombasierte Alerts wirken besser.
- Datenschutz vernachlässigen. Telemetrie enthält oft personenbezogene Daten in URLs, Headern und Logtexten. Die Maskierung muss vor der Speicherung erfolgen – gerade mit Blick auf die DSGVO.
Wie Obseria unterstützt
Obseria ist eine OpenTelemetry-native Observability-Plattform, die Metriken, Logs, Traces, Profile und Daten zur User Experience an einem Ort zusammenführt. Obseria Lake speichert alle Signale indexfrei mit Schema-on-Read, sodass Sie Felder mit hoher Kardinalität abfragen können, ohne vorab Indizes festzulegen. Obseria Pipeline filtert, reichert an und maskiert personenbezogene Daten beim Ingest, Obseria TopoGraph bildet Abhängigkeiten automatisch ab, und Obseria Intelligence führt agentische Root-Cause-Analysen mit nachvollziehbarer Beweiskette durch. Abfragen formulieren Sie in OQL, PromQL oder SQL. Da Daten per OTLP ankommen und jederzeit per OTLP exportiert werden können, bleibt Ihre Instrumentierung portabel.