Was ist Observability? Definition, Signale und Kosten

Was ist Observability? Es ist die Fähigkeit, mit den Telemetriedaten, die ein System ohnehin ausgibt, zu erklären, warum es sich verhält, wie es sich verhält, auch bei Fehlern, die niemand vorhergesehen hat. Monitoring meldet, dass die Checkout-Latenz die Grenze von 800 ms überschritten hat. Observability lässt Sie fragen, welcher Mandant, welche Abhängigkeit oder welches Deployment die Ursache ist, ohne mitten in der Nacht neuen Code auszuliefern, nur um das herauszufinden.

Hier ist die Situation, an der sich der Unterschied zeigt. Der Alarm schlägt an: Das p99 der Payments-API ist von 180 ms auf 1,4 s gestiegen. Das Dashboard ist grün bei CPU, Speicher und Fehlerrate. Jedes vorgefertigte Panel sagt, dass der Dienst in Ordnung ist, und jeder Kunde sagt das Gegenteil. Was Sie in den nächsten zehn Minuten tun, ist das eigentliche Thema dieses Artikels.

Warum die Definition vor den Tools zählt

Der Begriff stammt aus der Regelungstechnik: Ein System ist beobachtbar, wenn Sie seinen inneren Zustand aus seinen äußeren Ausgaben ableiten können. Die Softwarebranche hat ihn übernommen und dann so lange gedehnt, bis er nur noch ein Dashboard-Produkt bezeichnete. Diese Dehnung können Sie ignorieren.

Für ein Engineering-Team ist die brauchbare Definition enger und nützlicher. Ein System ist beobachtbar, wenn Sie im Produktivbetrieb eine neue Frage zu seinem Verhalten beantworten können, ohne neue Instrumentierung auszurollen. Das entscheidende Wort ist »neu«. Ein Schwellenwert-Alarm beantwortet eine Frage, die jemand im letzten Quartal aufgeschrieben hat. Ein beobachtbares System beantwortet die Frage, die Sie gerade stellen.

Das ist kein Reinheitstest. Niemand betreibt ein perfekt beobachtbares System, und das Ziel ist kein Punktwert. Das Ziel ist ein kürzerer Weg von »etwas ist kaputt« zu »diese Änderung hat es verursacht«. Mean Time to Detect und Mean Time to Understand sind verschiedene Kennzahlen, und die meisten Teams messen nur die erste.

Worin sich Observability vom Monitoring unterscheidet

Monitoring besteht aus Prüfungen gegen Fehlerbilder, die Sie bereits kennen: CPU über 90 % für fünf Minuten, Fehlerrate über 1 %, Warteschlange über 10.000 Einträge. Es ist günstig, zuverlässig, und Sie brauchen es weiterhin. Observability ersetzt es nicht.

Der Unterschied zeigt sich bei neuartigen Fehlern. Monitoring entsteht aus Ihren vergangenen Vorfällen. Observability wird für den nächsten gebaut, den Sie per Definition noch nicht gesehen haben.

Ein brauchbarer Test: Sehen Sie sich Ihre letzten drei Vorfälle an und fragen Sie, wie die Ursache gefunden wurde.

• Hat jemand ein vorgefertigtes Dashboard gelesen und stand die Antwort darauf, hat das Monitoring seine Aufgabe erfüllt.

• Hat jemand Logs auf sechs Hosts durchsucht, eine Hypothese gebildet, eine Log-Zeile ergänzt und neu deployt, um sie zu bestätigen, dann war das eine Lücke in der Observability.

• Kam die echte Antwort aus dem Screenshot eines Kunden, haben Sie beide Probleme.

Monitoring und Observability sind keine Rivalen, sondern Schichten. Monitoring ist der Rauchmelder. Observability ist die Fähigkeit, hinterher durch das Gebäude zu gehen und herauszufinden, welcher Stromkreis den Brand ausgelöst hat.

Welche drei Signale es gibt und wo jedes versagt

Logs, Metriken und Traces bilden das Standard-Trio. Jedes beantwortet eine andere Frage, und jedes hat einen Fehlermodus, den Anbieterleitfäden gern auslassen.

Metriken sind numerische Messwerte, über die Zeit aggregiert: Anfragerate, Fehlerrate, Latenz-Perzentile, Auslastung. Sie sind günstig zu speichern und schnell abzufragen, deshalb sitzen Alarme auf ihnen. Der Fehlermodus ist die Aggregation. Ein p99 von 1,4 s sagt Ihnen, dass etwas langsam ist. Es kann nicht sagen, dass jede langsame Anfrage zu einem einzigen Kunden auf einem einzigen Shard gehört.

Logs sind zeitgestempelte Datensätze einzelner Ereignisse. Sie enthalten die meisten Details und die wenigste Struktur, solange Sie ihnen keine aufzwingen. Der Fehlermodus sind Volumen und Kosten. Unstrukturierte Logs lassen sich nur von Menschen durchsuchen, die schon wissen, nach welcher Zeichenkette sie suchen müssen. Damit sind sie ein Monitoring-Werkzeug im Kostüm eines Debugging-Werkzeugs.

Traces verfolgen eine einzelne Anfrage über Dienstgrenzen hinweg, mit einem Span für jeden Schritt und dessen Dauer. Sie sind das einzige Signal, das die Form einer Anfrage zeigt: Dieser Aufruf hat 900 ms auf eine nachgelagerte Abhängigkeit gewartet, die dreimal wiederholt wurde. Der Fehlermodus ist die Abdeckung. Ein einziger Dienst, der den Trace-Kontext verliert, unterbricht die Kette, und ein Trace mit einem Loch ist schlechter als gar keiner, weil er vertrauenswürdig aussieht.

Alle drei zu haben ist nicht dasselbe wie beobachtbar zu sein. Entscheidend ist die Korrelation. Sie müssen von einem Metrik-Ausschlag zu den Traces gelangen, die dazu beigetragen haben, und von einem Trace zu den Logs genau dieser Anfrage. Liegen die drei in getrennten Werkzeugen ohne gemeinsamen Identifikator, haben Sie drei Monitoring-Systeme und einen Engineer, der als Join fungiert.

Warum die Kardinalität darüber entscheidet, ob Sie überhaupt debuggen können

Kardinalität ist die Anzahl unterschiedlicher Werte, die ein Feld annehmen kann. status_code hat vielleicht zwanzig. customer_id hat Hunderttausende. request_id hat einen pro Anfrage.

Die Felder, die Sie während eines Vorfalls am dringendsten brauchen, sind die mit hoher Kardinalität. »Welcher Kunde ist betroffen?« ist eine customer_id-Frage. »Welcher Build liefert die langsamen Anfragen aus?« ist eine deploy_version-Frage. Bestraft Ihr Speichermodell Felder mit hoher Kardinalität, indem es pro eindeutiger Serie abrechnet oder sie still verwirft, können Sie die Frage nicht stellen, die den Vorfall aufklärt.

Hier verläuft die eigentliche Architekturgrenze zwischen einem reinen Metrik-Setup und einem beobachtbaren. Vorab aggregierte Metriken werfen die Dimensionen weg, die Sie später brauchen würden. Breite, strukturierte Ereignisse behalten sie, und Sie schneiden nachträglich.

So sieht ein brauchbares Ereignis an der Kante eines Dienstes aus: ein strukturierter Datensatz pro Anfrage, mit genug Kontext, um nach allem zu filtern, was Sie später interessieren wird.

logger.info("request.completed", {
  trace_id: span.traceId,
  route: "/v1/payments",
  customer_id: ctx.customerId,
  deploy_version: process.env.BUILD_SHA,
  flag_variant: flags.get("new-ledger-path"),
  db_ms: timings.db,
  upstream_ms: timings.upstream,
  status: res.statusCode,
  duration_ms: elapsed,
});

Beachten Sie die Feature-Flag-Variante darin. Ein großer Teil der Vorfälle in veröffentlichten Post-Mortems beginnt mit einer Änderung, und eine Flag-Auswertung ist eine Änderung. Steht die Variante nicht im Ereignis, können Sie nicht fragen, ob die langsamen Anfragen gerade die auf dem neuen Pfad sind.

Wie sieht ein Vorfall mit und ohne Observability aus?

Nehmen Sie das Payments-Szenario noch einmal. Derselbe Alarm, dieselben 1,4 s p99.

Ohne Observability sieht der Ablauf so aus: Sie öffnen das Service-Dashboard und finden nichts, dann das Datenbank-Dashboard, wieder nichts, und fragen im Incident-Channel, ob etwas deployt wurde. Jemand erinnert sich an eine Konfigurationsänderung, ein anderer widerspricht. Vierzig Minuten später rollen Sie das letzte Deployment zurück, um zu sehen, ob es hilft. Es hilft nicht, weil die Ursache ein Flag-Rollout auf eine Teilmenge der Mandanten war.

Mit Observability sieht der Ablauf anders aus. Sie gruppieren die langsamen Anfragen nach flag_variant und sehen, dass 100 % davon auf new-ledger-path laufen. Sie gruppieren nach customer_id und sehen, dass drei große Mandanten den Großteil des Volumens stellen. Sie öffnen einen Trace und sehen, wie der Ledger-Aufruf in 40 sequentielle Abfragen zerfällt. Gesamtzeit: wenige Minuten. Sie schalten das Flag ab, nicht das Deployment.

Beachten Sie, was der zweite Ablauf nicht brauchte. Er brauchte kein vorbereitetes Dashboard. Er brauchte niemanden, der »Flag-Variante« im Voraus als interessante Dimension vorhergesagt hätte. Er brauchte Daten, die vorhanden, breit und abfragbar waren.

Das ist das Honeycomb-Argument in einem Absatz, und es hält stand. Es sagt allerdings nicht, dass das kostenlos ist.

Was kostet es, und wer sollte die teure Variante auslassen?

Telemetrie ist zuerst ein Datenvolumenproblem und erst danach ein Werkzeugproblem. Laut der Observability-Umfrage von Grafana Labs 2025 unter 1.255 Praktikern betreibt eine Organisation im Schnitt acht verschiedene Observability-Werkzeuge, und die Kosten sind das am häufigsten genannte Kriterium bei der Auswahl neuer. Beide Fakten hängen zusammen. Teams häufen Werkzeuge an, weil jedes einen Ausschnitt löst, und zahlen dann für überlappende Datenaufnahme in allen.

Praktische Regeln, die für die meisten Teamgrößen gelten:

• Instrumentieren Sie mit OpenTelemetry statt mit einem proprietären Agenten. Der Collector gibt Ihnen einen Ort für Sampling, Filterung und Routing. Ein Wechsel des Backends wird dann zu einer Konfigurationsänderung statt zu einem Instrumentierungsprojekt.

• Samplen Sie Traces bewusst. Behalten Sie jeden Fehler und jede langsame Anfrage, und samplen Sie die gesunden, schnellen. Head-basiertes Sampling mit einheitlich 1 % verwirft genau den Trace, den Sie brauchen.

• Strukturieren Sie Logs beim Schreiben. Freitext erst zur Abfragezeit zu parsen ist der teure Weg, an Felder zu kommen.

• Legen Sie pro Signal eine Aufbewahrungsfrist fest. Metriken ein Jahr, breite Ereignisse zwei Wochen, Debug-Logs drei Tage. Niemand hat je die Debug-Logs des letzten Quartals gebraucht.

Verzichten Sie auf den Full-Platform-Ansatz, wenn Sie eine Handvoll Dienste und eine einzige Bereitschaftsrotation betreiben. Ein kleines Team holt den größten Nutzen aus strukturierten Logs, RED-Metriken und Traces auf den zwei oder drei heißen Pfaden. Der teure Alles-in-einem-Vertrag lohnt sich, wenn so viele Dienste existieren, dass niemand die gesamte Topologie im Kopf hält. Nach unserer Erfahrung ist das irgendwo jenseits von 30 bis 40 Diensten der Fall.

Welche Werkzeuge lohnen einen Blick?

Die Wahl hängt davon ab, wie viel Sie selbst betreiben wollen, wie Ihre Kardinalität aussieht und was Ihre Rechnung verkraftet. Eine kurze, meinungsstarke Übersicht:

Datadog ist die breiteste kommerzielle Option: Metriken, Logs, Traces und Profiling unter einem Dach, mit starker Korrelation zwischen ihnen. Der Preis dieser Integration ist eine Rechnung, die mit Hosts, benutzerdefinierten Metriken und Log-Volumen wächst. Lohnt sich, wenn Sie einen Anbieter wollen und das Budget dafür haben. Prüfen Sie die Position für benutzerdefinierte Metriken, bevor Sie sich festlegen.

Grafana ist die Standardwahl, wenn Sie offene Komponenten wollen, die Sie selbst hosten oder als Managed-Stack kaufen können. Es passt gut zu Prometheus-artigen Metriken und OpenTelemetry-Pipelines. Der Preis ist operativ: Sie besitzen mehr vom Zusammenbau, und die Wildwuchs-Zahl aus der Umfrage oben betrifft auch Sie.

SigNoz ist eine Open-Source-Option auf OpenTelemetry-Basis, die Logs, Metriken und Traces in einem Datenspeicher vereint. Das ist für den Korrelationspunkt von vorhin wichtig, denn ein gemeinsamer Speicher macht den Sprung von Metrik über Trace zu Log zu einer Abfrage statt zu einem Tab-Wechsel. Geeignet für Teams, die selbst hosten wollen, ohne vier Projekte zusammenzuflicken.

Better Stack kombiniert Uptime-Monitoring, Incident-Alarmierung und Log-Management zu einem Preis, der auf kleinere Teams zielt. Es ist ein vernünftiger erster Schritt, wenn Sie von »Wir erfahren es von Kunden« zu etwas Strukturiertem wechseln wollen. Weniger geeignet ist es für ein großes Service-Mesh mit hohen Anforderungen an Traces.

Wie fangen Sie an, ohne das Meer zu kochen?

Beginnen Sie nicht mit einer Tool-Evaluierung. Beginnen Sie mit Ihren letzten drei Vorfällen und einer ehrlichen Frage: Was hätten wir gern fragen können?

Eine Reihenfolge, die für ein Team mit 50 bis 200 Ingenieuren funktioniert:

1. Wählen Sie einen kritischen Anfragepfad und instrumentieren Sie ihn Ende-zu-Ende mit OpenTelemetry. Checkout, Login, was auch immer Sie um drei Uhr nachts weckt.

2. Senden Sie ein breites, strukturiertes Ereignis pro Anfrage an der Kante des Dienstes, mit Kunde, Version, Flag-Varianten und nachgelagerten Zeiten.

3. Definieren Sie ein SLO auf diesem Pfad und alarmieren Sie über die Burn Rate statt über rohe Schwellenwerte. Burn-Rate-Alarme wecken Sie wegen Nutzerwirkung, und die Telemetrie aus Schritt zwei sagt Ihnen, warum.

4. Führen Sie einen Game Day durch. Injizieren Sie einen Fehler, auf den Sie nicht alarmiert sind, und messen Sie, wie lange jemand braucht, der den Code nicht geschrieben hat, um ihn zu finden. Diese Zahl ist Ihre Basislinie.

5. Erweitern Sie Pfad für Pfad, und zwar erst, nachdem der erste Pfad sich in einem echten Vorfall bezahlt gemacht hat.

Observability wird als Plattform gekauft und als Gewohnheit eingeführt. Die Gewohnheit ist, beim Code-Review zu fragen: »Was müsste ich wissen, um das zu erklären?« Und zwar vor dem Vorfall, nicht während er läuft.

Schauen Sie sich Ihr letztes Incident-Review an. Suchen Sie den Satz »dann haben wir Logging ergänzt, um es zu bestätigen«. Jeder davon ist eine Frage, auf die Ihr System im Produktivbetrieb nicht antworten konnte. Wie viele haben Sie dokumentiert, und welche davon wären heute noch unbeantwortbar?