# Was ist Observability? Praxisleitfaden für Entwicklerteams URL: https://codebasechat.com/de/journal/was-ist-observability Type: blog Locale: de Published: 2026-10-27 Updated: 2026-10-28 --- > Was ist Observability, und worin unterscheidet sie sich von Monitoring? Ein praxisnaher Leitfaden zu Logs, Metriken, Traces und OpenTelemetry für Teams mit 5 bis 50 Ingenieuren. 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. ![Gedruckte Logs neben einer handgezeichneten Skizze verbundener Services](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/f0aa73-i1.webp) Die Observability-Umfrage von Grafana Labs aus dem Jahr 2025 mit 1.255 Befragten zeigt, wo Teams tatsächlich stehen. Laut [Grafanas Observability-Umfrage](https://grafana.com/blog/2025/03/25/observability-survey-takeaways) 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](https://opentelemetry.io/docs/concepts/observability-primer/) 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. ![Trace-Wasserfall auf dem Bildschirm eines Laptops](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/fb03e7-i2.webp) 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: - Observability sagt Ihnen **wo** zur Laufzeit: welcher Service, welcher Span, welcher Mandant. - 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. ![Entwickler mit Code-Editor und Metrik-Dashboard nebeneinander](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/5fe138-i3.webp) ## 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: - **Wählen Sie einen kritischen Nutzerablauf.** Checkout, Registrierung, der zentrale API-Aufruf. Nicht das gesamte System. - **Fügen Sie strukturierte Logs mit einer Request-ID hinzu.** JSON, ein Ereignis pro Zeile, Trace- oder Request-ID in jeder Zeile. - **Instrumentieren Sie diesen Ablauf mit OpenTelemetry-Traces.** Mit Mandanten-, Versions- und Flag-Attributen aus dem Beispiel oben. - **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. - **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. ## FAQ ### Was ist Observability in einfachen Worten? Observability beschreibt, wie gut Sie verstehen können, was in einem System passiert, anhand der Daten, die es erzeugt. Wenn Sie die Ursache eines nicht vorhergesehenen Problems mit Logs, Metriken und Traces finden, ohne neuen Code auszurollen, ist das System beobachtbar. ### Worin unterscheidet sich Observability von Monitoring? Monitoring überwacht bekannte Probleme anhand vordefinierter Metriken und Schwellenwerte. Observability erlaubt es, unbekannte Probleme anhand detaillierter Telemetriedaten zu untersuchen. Monitoring ist die Alarmierungsschicht, Observability ist das Werkzeug, mit dem Sie nach einem Alarm die Ursache finden. ### Was sind die drei Säulen der Observability? Metriken, Logs und Traces. Metriken sind Zahlen über die Zeit, Logs sind Einträge einzelner Ereignisse, und Traces verfolgen eine einzelne Anfrage über Services hinweg. Am nützlichsten sind sie, wenn gemeinsame IDs sie miteinander verbinden. ### Brauche ich OpenTelemetry, um beobachtbar zu sein? Nein, aber es hilft. OpenTelemetry ist ein herstellerneutraler Standard für die Ausgabe von Logs, Metriken und Traces. Wenn Sie damit instrumentieren, können Sie das Observability-Backend später wechseln, ohne Ihre Services neu zu instrumentieren. ### Ist Observability nur für Microservices relevant? Nein. Verteilte Systeme profitieren am meisten, weil eine einzelne Anfrage viele Services berührt. Aber auch ein Monolith mit einer Datenbank, einer Warteschlange und einigen externen APIs profitiert von strukturierten Logs und Traces. ### Was kostet Observability? Das hängt vom Datenvolumen und vom Tool ab. Gehostete Plattformen rechnen meist nach Nutzung ab, die Kosten wachsen also mit dem Traffic. Open-Source-Stacks tauschen Lizenzkosten gegen Engineering-Zeit. Die zwei häufigsten Wege, Ausgaben zu begrenzen, sind das Verwerfen ungenutzter Logs und das Sampling von Traces.