Was ist Observability?

Was ist Observability?

Observability ist die Eigenschaft eines Systems, dass du seinen internen Zustand aus seinen externen Outputs verstehen kannst, ohne neuen Code shippen zu müssen, um zu untersuchen. Die drei externen Outputs sind Logs (welche Events passiert sind), Metriken (numerische Zeitreihen wie RPS, Latenz, CPU) und Traces (Request-Level Breakdown über Services). Ein System ist observable, wenn ein Engineer ohne Vorwissen beliebige Fragen zu einem Production-Incident allein aus diesen drei Signalen beantworten kann.

Der Begriff stammt aus der Control Theory: ein System ist observable, wenn sein interner Zustand aus einer endlichen Output-Historie vollständig bestimmbar ist. In Software ist die praktische Hürde niedriger, aber das Prinzip bleibt. Wenn ein Kunde Slow Checkout meldet und deine einzige Antwort ist, Log-Lines hinzuzufügen, neu zu deployen und auf Wiederauftreten zu warten, ist dein System nicht observable.

Observability vs Monitoring

Monitoring und Observability überlappen, sind aber nicht das Gleiche:

• Monitoring stellt vordefinierte Fragen: ist die Homepage up, CPU unter 80%, Error-Rate unter 1%? Du setzt Dashboards und Alerts im Voraus gegen Failure-Modes, die du vorhersagst. Beste Wahl für bekannte Failure-Modes.
• Observability stellt beliebige Fragen an High-Cardinality-Daten nachträglich: "zeig mir alle p99 Requests letzte Stunde gruppiert nach customer_id und Region, wo Downstream-Call zu stripe.com über 800 ms überschritt." Beste Wahl für unbekannte Failure-Modes.

Ein Monitoring-System kann dir sagen, dass etwas kaputt ist. Ein observables System lässt dich herausfinden, was. Gesunde Production braucht beides.

Die drei Pillars (und die Cardinality-Falle)

• Logs: diskrete Event-Records. Einfach zu schreiben, teuer at scale zu queryen, schwach in Korrelation über Services hinweg, außer du propagierst Trace-IDs in jede Log-Line.
• Metriken: numerische Zeitreihen. Billig zu speichern, schnell zu queryen, aber verlieren Per-Request-Context. Cardinality (Anzahl unique Tag-Kombinationen) ist der Cost-Driver.
• Traces: Per-Request Span-Bäume über Services. Stärkstes Signal für Incident-Investigation. Oft sampled (1-10%), weil jeden Trace zu speichern prohibitiv ist.

Moderne Observability-Tools (Honeycomb, Datadog, Grafana, Splunk, New Relic, Elastic) versuchen, die drei um eine geteilte Trace-ID zu vereinen, sodass ein Click von einer Metrik-Spike zum langsamen Trace zu den korrespondierenden Logs wechselt.

Was Observability in der Praxis abdeckt

1. Incident-Investigation: Production brennt, On-Call-Engineer korreliert Metrik-Spike zu Trace zu langsamer Query zu schlechtem Deploy in unter 10 Minuten.
2. SLO-Messung: Error-Rate und Latenz-Perzentile pro Endpoint, pro Customer-Tier, beliebig geslict.
3. Performance-Regression-Detection: p95 Latenz für Endpoint X vor und nach einem Deploy vergleichen, scoped auf eine einzelne Customer-Kohorte.
4. Customer-Support-Escalation: "dieser User meldet, sein Checkout war langsam um 14:32 UTC" gemappt auf den exakten Trace.
5. Capacity-Planning: historische Metriken mit Traffic-Pattern korreliert. Siehe Capacity Testing.

Wie observable werden

Starte mit Propagation einer Trace-ID durch jeden Request: HTTP-Header (W3C traceparent), in Queue-Messages, in Background-Jobs. Dann instrumentieren mit einem OpenTelemetry-SDK (Vendor-neutral) das Traces und Metriken an dein Backend deiner Wahl emittiert. Dann Log-Lines standardisieren, damit sie trace_id und customer_id enthalten.

Observability komplementiert Load Testing. Führe Load Testing oder Soak Testing gegen ein voll instrumentiertes Staging aus, und die gleichen Dashboards, die du in Production nutzt, werden deine Testresultate. Siehe auch Latenz.

Wenn dein Team Production-Shape Load-Test-Runs gegen deinen bestehenden Observability-Stack korrelieren muss, bietet LoadFocus Load-Testing-Services, wo Engineers die Scenarios designen und gegen APM- und Tracing-Daten dokumentieren.