Was ist Observability? Praxisleitfaden für Entwicklerteams

Es ist 2 Uhr nachts, der Checkout-Endpunkt liefert bei etwa jeder zwanzigsten Anfrage einen 500er, und alle Dashboards sind grün. Genau diese Lücke zwischen »Das System meldet alles in Ordnung« und »Nutzer sagen, es ist kaputt« soll Observability schließen. Was ist Observability? Sie beschreibt die Fähigkeit, den inneren Zustand eines Systems anhand der Daten zu verstehen, die es ausgibt: Logs, Metriken und Traces. Und zwar gut genug, um Fragen zu beantworten, die Sie vorher nicht geplant hatten.

Dieser letzte Halbsatz ist der eigentliche Kern. Alles Weitere in diesem Beitrag ist Detail.

Observability vs. Monitoring: Die Frage, für die Sie keinen Alert geschrieben haben

Monitoring beantwortet Fragen, die Sie schon kannten. CPU über 90 Prozent? Fehlerrate über 2 Prozent? Warteschlange wächst? Sie wählen die Metriken, setzen die Schwellenwerte, und wenn einer überschritten wird, klingelt der Pager.

Observability beantwortet die Frage, die Sie nicht kannten. Warum dauern nur Anfragen eines bestimmten Mandanten, auf einer bestimmten App-Version und nach einem bestimmten Deployment, vier Sekunden länger? Dafür gibt es keinen Alert, weil niemand dieses Problem vorhergesehen hat.

Die beiden sind also keine Rivalen. Monitoring ist die Alarmierungsschicht. Observability ist das, womit Sie nach dem Alarm untersuchen, oder wenn ein Kunde sich meldet und gar kein Alarm ausgelöst wurde. Wenn Ihr einziges Werkzeug eine Wand aus vorgefertigten Dashboards ist, haben Sie Monitoring. Wenn Sie Produktionsdaten nach beliebigen Dimensionen aufschlüsseln und eine Anfrage über mehrere Services verfolgen können, ohne neuen Code auszurollen, haben Sie Observability.

Die drei Signale: Metriken, Logs und Traces

Die meisten Definitionen beginnen mit den »drei Säulen«. Das Bild ist etwas steif, aber die drei Datentypen sind real, und jeder ist bei einer bestimmten Aufgabe gut.

• Metriken sind Zahlen über die Zeit: Anfragerate, p95-Latenz, Speicherverbrauch. Günstig zu speichern, schnell abzufragen, ideal für »Stimmt etwas nicht?«. Schwach bei »Welche Anfrage, und warum?«.

• Logs sind zeitgestempelte Einträge einzelner Ereignisse: Eine Zahlung ist fehlgeschlagen, ein Retry wurde ausgelöst, ein Feature-Flag wurde umgeschaltet. Sie enthalten das Detail, aber unstrukturierte Logs auf einem stark ausgelasteten Service werden schnell zum Heuhaufen.

• Traces verfolgen eine einzelne Anfrage über mehrere Services hinweg. Jeder Schritt ist ein Span mit Startzeit, Dauer und einigen Attributen. Ein Trace kommt einem Stack Trace für verteilte Systeme am nächsten.

Die Observability-Umfrage von Grafana Labs aus dem Jahr 2025 mit 1.255 Befragten zeigt, wo Teams tatsächlich stehen. Laut Grafanas Observability-Umfrage nutzen 95 Prozent der Befragten Metriken und 87 Prozent Logs, aber nur 57 Prozent Traces. Dabei sind Traces das Signal, das bei einem verteilten Fehler am ehesten hilft, und das am seltensten eingerichtet ist.

Verzichten Sie auf die Kurzformel, Metriken sagen was, Logs sagen warum, Traces sagen wo. Sie klingt aufgeräumt und scheitert in der Praxis: Ein gut strukturierter Log verrät oft mehr über das »Wo« als ein schlecht instrumentierter Trace.

Was ein System in der Praxis beobachtbar macht

Daten auszugeben ist notwendig, aber nicht hinreichend. Ein System ist beobachtbar, wenn die Daten drei Eigenschaften haben.

Hohe Kardinalität. Sie können nach Nutzer-ID, Mandant, Build-SHA, Region oder Feature-Flag filtern. Wenn Ihr Tool Sie zwingt, nach Servicename und Statuscode vorzuaggregieren, finden Sie den einen Mandanten im fehlerhaften Zustand nicht.

Kontext, der Signale verbindet. Eine Trace-ID in jeder Logzeile bedeutet, dass Sie von einem langsamen Span direkt zu den Logs springen können, die er erzeugt hat. Ohne diese Verbindung lesen Sie zwei getrennte Geschichten und raten, wie sie zusammenhängen.

Genug Detail, um nützlich zu sein, aber nicht so viel, dass es unbezahlbar wird. Hier scheitern die meisten Teams. In derselben Grafana-Umfrage nannten die Befragten zusammen mehr als 100 verschiedene Tools, Services und Projekte, und das durchschnittliche Team betrieb acht davon. Kosten gehörten zu den wichtigsten Kriterien bei der Toolauswahl. Alles zu erfassen ist einfach. Die Rechnung dafür kommt erst später.

Hier sehen Sie den Einstieg mit OpenTelemetry, dem herstellerneutralen Standard für Instrumentierung. Das folgende Python-Beispiel legt einen Span an und setzt die Attribute, die Sie um 2 Uhr nachts brauchen werden:

from opentelemetry import trace

tracer = trace.get_tracer("checkout")

def charge(order):
    with tracer.start_as_current_span("charge_card") as span:
        span.set_attribute("order.id", order.id)
        span.set_attribute("tenant.id", order.tenant_id)
        span.set_attribute("app.version", APP_VERSION)
        result = payment_client.charge(order)
        span.set_attribute("payment.provider", result.provider)
        return result

Drei Attribute machen den Unterschied zwischen »Checkout ist langsam« und »Checkout ist langsam für Mandant 4412 auf Version 3.8.1«. Die OpenTelemetry-Einführung in Observability erklärt die Konzepte dahinter ausführlicher. Sie lohnt sich einmal, auch wenn Ihr Anbieter die Verkabelung übernimmt.

Wo sich Observability-Tools unterscheiden (und wo nicht)

Unter dem Marketing nehmen die meisten Plattformen dieselben drei Signale auf. Sie unterscheiden sich im Preismodell, in der Abfragestärke und darin, wie viel Instrumentierung sie Ihnen abnehmen.

• All-in-one-Plattformen bündeln Metriken, Logs, Traces, Alerting und mehr. Bequem, mit dem Nachteil nutzungsabhängiger Rechnungen, die mit Ihrem Traffic wachsen.

• Open-Source-Stacks wie Prometheus, Loki, Tempo und Grafana geben Ihnen Kontrolle und keine Lizenzgebühr pro Host. Dafür betreiben und optimieren Sie sie selbst.

• OpenTelemetry-native Backends nehmen das Standardformat direkt an. Ein Anbieterwechsel bedeutet dann nicht, jeden Service neu zu instrumentieren.

Datadog ist der Referenzpunkt der All-in-one-Kategorie: breite Abdeckung, eine polierte Oberfläche und eine Rechnung, die eine monatliche Prüfung verdient. Lohnt sich, wenn Sie einen Anbieter wollen und das Budget dafür haben. Lassen Sie es, wenn planbare Kosten Ihre wichtigste Vorgabe sind.

Grafana ist die pragmatische Open-Source-Wahl. Sie können mit Dashboards auf den Daten starten, die Sie schon haben, und Logs und Traces ergänzen, wenn Sie sie brauchen. Rechnen Sie mit einigem Aufwand an Engineering-Zeit.

SigNoz ist von Anfang an auf OpenTelemetry aufgebaut und bringt Metriken, Logs und Traces in einer Open-Source-Oberfläche zusammen. Eine vernünftige Wahl für ein Team, das alles in einem Fenster will, ohne den Preis einer All-in-one-Plattform.

New Relic liegt zwischen beiden Welten: eine gehostete Plattform mit einem kostenlosen Tarif, der großzügig genug für eine echte Evaluierung ist. Bewerten Sie, ob Ihr eigenes Team darin eine echte Produktionsfrage beantworten kann, nicht die Demo.

Keines dieser Tools macht Sie allein beobachtbar. Das Tool ist eine Abfrageoberfläche. Die Instrumentierung ist das eigentliche Produkt.

Der Teil, den die meisten Anleitungen auslassen: Observability endet an der Code-Grenze

Hier ist eine Lücke, die Ihnen beim ersten ernsthaften Einsatz eines dieser Tools auffallen wird. Ein Trace sagt Ihnen, dass charge_card 3,9 Sekunden gedauert hat und der langsame Teil ein Aufruf von payment_client war. Er sagt Ihnen nicht, was payment_client tatsächlich tut, wer es geschrieben hat oder warum es dreimal ohne Backoff wiederholt.

Dafür verlassen Sie das Observability-Tool und lesen Code. In einem kleinen Service dauert das zehn Minuten. In einem Repo mit 100K Zeilen, das vier Teams gehört, ist das Lesen oft der längste Teil des Vorfalls. Sie wissen genau, welcher Span langsam ist, und verbringen trotzdem eine Stunde damit, herauszufinden, wie der Code dahinter verdrahtet ist.

Das ist das Übergabeproblem zwischen Laufzeitdaten und Quellcode. Deshalb betrachten wir Observability und Code-Verständnis als zwei Hälften desselben Workflows:

1. Observability sagt Ihnen wo zur Laufzeit: welcher Service, welcher Span, welcher Mandant.

2. Code-Verständnis sagt Ihnen warum im Quellcode: welche Funktion, welche Retry-Richtlinie, welche Konfiguration.

Teams, die diese Schleife schließen (ein Span-Name führt zu einer Datei, eine Datei zu einem Verantwortlichen und einer Erklärung), verkürzen die Zeit zwischen »Alarm ausgelöst« und »Fehler verstanden«. Es ist vor allem ein Disziplinproblem. Benennen Sie Spans nach Funktionen, legen Sie den Repo-Pfad als Span-Attribut ab und pflegen Sie pro Service eine kurze Architekturnotiz. Ein KI-Assistent, der Fragen zu Ihrem Repo beantwortet, etwa »Wo ist die Retry-Richtlinie für Zahlungsaufrufe gesetzt?«, hat dann etwas Konkretes, woran er sich orientieren kann.

Drei Fehler, durch die Teams glauben, Observability funktioniert nicht

Dashboards als Ziel betrachten. Ein Dashboard ist eine gespeicherte Antwort auf eine alte Frage. Teams, die vierzig davon bauen und nie ad hoc abfragen, landen bei Monitoring in einer schöneren Verpackung. Fragen Sie bei jedem Vorfall: Haben wir das aus einem Dashboard beantwortet oder durch Erkunden der Rohdaten?

Zu früh oder gar nicht sampeln. 100 Prozent der Traces auf einem stark ausgelasteten Service zu behalten, wird schnell teuer. 1 Prozent zufällig zu behalten, wirft dagegen genau die seltene fehlschlagende Anfrage weg, die Sie interessiert. Tail-based Sampling, das langsame und fehlerhafte Traces behält und die meisten gesunden verwirft, ist der übliche Kompromiss. Entscheiden Sie das vor der ersten Rechnung, nicht danach.

Attributnamen auseinanderlaufen lassen. Ein Service schreibt user_id, ein anderer userId, ein dritter uid. Jetzt liefert die Abfrage, die alle drei umfassen sollte, ein Drittel des Bildes. Vereinbaren Sie eine kleine Namenskonvention für Mandant, Nutzer, Version und Flags, und schreiben Sie sie ins Repo, wo die Leute sie finden.

Keines dieser Probleme ist ein Werkzeugproblem. Es sind Gewohnheiten, und Gewohnheiten zu ändern ist billiger, als den Anbieter zu wechseln.

Ein realistischer Start, ohne den Ozean kochen zu wollen

Wenn Sie heute nichts haben, widerstehen Sie dem Drang, in der ersten Woche alles zu instrumentieren. Eine Reihenfolge, die für Teams mit 5 bis 50 Ingenieuren funktioniert:

1. Wählen Sie einen kritischen Nutzerablauf. Checkout, Registrierung, der zentrale API-Aufruf. Nicht das gesamte System.

2. Fügen Sie strukturierte Logs mit einer Request-ID hinzu. JSON, ein Ereignis pro Zeile, Trace- oder Request-ID in jeder Zeile.

3. Instrumentieren Sie diesen Ablauf mit OpenTelemetry-Traces. Mit Mandanten-, Versions- und Flag-Attributen aus dem Beispiel oben.

4. Definieren Sie zwei oder drei Service-Level-Ziele (SLOs). Zum Beispiel: 99,5 Prozent der Checkout-Anfragen sind in weniger als 800 ms erfolgreich. Alarme hängen an diesen Zielen, nicht an der CPU.

5. Prüfen Sie einen echten Vorfall anhand der Daten. Hätten Sie die Ursache ohne neuen Code finden können? Wenn nicht, ist die Lücke, die Sie gefunden haben, Ihre nächste Instrumentierungsaufgabe.

Schritt 5 wird am ehesten übersprungen, und er ist der einzige, der Ihnen sagt, ob Sie beobachtbar sind. Alles andere ist Verkabelung.

Was wir an Ihrer Stelle tun würden

Wenn Ihr Team weniger als 20 Ingenieure hat, starten Sie mit OpenTelemetry-Instrumentierung und einem Backend, dessen Preise Sie vorhersagen können. Die Instrumentierung ist portabel, die Wahl des Backends also umkehrbar. Kaufen Sie nicht die größte Plattform, nur weil ein Wettbewerber sie gekauft hat.

Wenn Sie bereits für ein All-in-one-Tool zahlen, reißen Sie es nicht heraus. Prüfen Sie, was Sie einlesen, werfen Sie die Logs weg, die niemand abfragt, und investieren Sie die Ersparnis in die Instrumentierung der Abläufe, die wirklich zählen.

Und egal, welchen Weg Sie wählen: Halten Sie schriftlich fest, wie ein Span auf den Code zurückführt. Das Dashboard zeigt Ihnen den Brand. Jemand muss trotzdem den Quellcode lesen, um herauszufinden, warum er ausgebrochen ist.