Observability liegt nicht mehr allein in der Verantwortung von Site-Reliability-Teams; Entwickler sind zunehmend aufgefordert, den von ihnen geschriebenen Code um Traces, Logs und Metriken zu ergänzen, damit sie Fehler diagnostizieren und das Verhalten von Anwendungen vor und nach deren Einführung in die Produktion verstehen können. In einem am 25. August 2026 im CNCF-Blog veröffentlichten Beitrag stellen Adriana Villela, OpenTelemetry-Community-Managerin und CNCF Ambassador, und Diana Todea, OpenTelemetry-Dokumentationsbeauftragte und CNCF Ambassador, einen praktischen Weg vor, um diese Aufgabe mithilfe von OpenTelemetry weniger aufwendig zu machen.
Die Autorinnen gehen von einem unter Entwicklern bekannten Einwand aus: Instrumentierung bedeutet zusätzlichen Code, der gepflegt werden muss, zusätzliche Komplexität und die Möglichkeit, dass Fehler oder technische Schulden entstehen. Sie verbinden diesen Aufwand jedoch mit unmittelbaren praktischen Vorteilen, darunter eine kürzere Zeit zur Fehlerbehebung, ein schnellerer Abschluss und eine schnellere Bereitstellung von Funktionen, das Aufdecken langsamer Pfade, unsichtbarer Wiederholungsversuche und von Randfällen sowie ein besseres Verständnis verteilter Systeme. Nach Ansicht der Autorinnen hilft Observability außerdem dabei, Anwendungen zu zerlegen, die mithilfe von KI-Tools erstellt wurden und deren Qualität unterschiedlich ausfallen kann.
Mit Automatisierung beginnen und anschließend Fehlendes ergänzen
Die erste Empfehlung lautet, Zero-Code-Instrumentierung zu verwenden, sofern sie verfügbar ist. Dieser Mechanismus fügt der Anwendung Instrumentierung hinzu, ohne den Quellcode zu ändern, indem Aufrufe gängiger Frameworks und Bibliotheken zur Laufzeit oder während der Kompilierung abgefangen werden. Dem Beitrag zufolge steht diese Unterstützung für Java, .NET, Python, JavaScript, PHP und Go zur Verfügung.
Die Autorinnen betrachten Automatisierung nicht als vollständige Lösung; sie weiß nicht unbedingt, was in der Anwendungslogik selbst wichtig ist. Daher sollte sie durch manuelle Instrumentierung ergänzt werden, um Traces, Metriken und Logs sowie Kontextweitergabe und für den Code spezifische Attribute hinzuzufügen. Außerdem schlagen sie Observability-driven Development vor, also Observability bereits beim Schreiben neuen Codes hinzuzufügen, statt dies erst Tage später nachzuholen, wenn die Einzelheiten des Designs weniger präsent sind.
Was ist messenswert?
- Wichtige Arbeitseinheiten: Füge Spans für eingehende Anfragen wie HTTP-Aufrufe und ausgehende Verbindungen zu Datenbanken, Caches, APIs und Queues sowie für geschäftskritische Vorgänge hinzu. Der Beitrag warnt davor, für jeden kleinen Aufruf einen Span zu erstellen, da dies Rauschen erzeugen kann, das wichtige Signale verdeckt.
- Einflussreiche Ereignisse: Verwende Logs, um zu erklären, warum etwas Bestimmtes passiert ist, und konzentriere dich auf Fehler, fehlgeschlagene Validierungen, Wiederholungs- und Fallback-Pfade sowie Sicherheitsereignisse wie fehlgeschlagene Authentifizierung und verweigerte Berechtigungen.
- Antwortzeit: Latenzmessungen helfen dabei, die Ursache dafür zu bestimmen, dass eine bestimmte Anfrage länger als üblich dauert, insbesondere bei mehrstufigen Abläufen wie dem Hinzufügen eines Artikels zum Warenkorb und dem anschließenden Abschluss des Kaufs.
- Interne Frameworks und Bibliotheken: Die Instrumentierung von Frameworks und Bibliotheken, die vom Team selbst entwickelt wurden, kann eine umfassende Abdeckung ermöglichen, da große Teile der Anwendung sie durchlaufen.
KI als Assistenten verwenden, nicht als Ersatz für Überprüfungen
Nach Ansicht der Autorinnen können KI-gestützte Programmierwerkzeuge die Zeit verkürzen, die für die Erkundung der verschiedenen OpenTelemetry-Schnittstellen und SDKs erforderlich ist, und außerdem beim Umgang mit Legacy-Code helfen. Ihre Nutzung erfordert jedoch eine präzise Anleitung. Sie schlagen vor, die Rolle des Assistenten, das Ziel, den Speicherort des Codes und die verwendete Sprache sowie die gewünschten Ergebnisse festzulegen und Links zur relevanten Dokumentation oder zu einschlägigen Codebeispielen beizufügen.
Außerdem empfehlen sie, den Agenten aufzufordern, seine Entscheidungen zu erklären, nach Möglichkeit einen weiteren Agenten als Richter einzusetzen, um diese Entscheidungen infrage zu stellen, und anschließend die Ergebnisse durch wiederholte Versuche zu verbessern, statt die erste von dem Tool vorgeschlagene Änderung zu akzeptieren. Diese Empfehlungen spiegeln die Ansicht und Erfahrung der Autorinnen wider und stellen keine Garantie dafür dar, dass der von einer KI erzeugte Code korrekt oder für die Anwendung geeignet sein wird.
Ein lokaler Weg zum Verständnis von Messdaten
Instrumentierung ist ohne eine Möglichkeit, die erzeugten Daten zu lesen, nicht vollständig. Der Beitrag erklärt, dass der OpenTelemetry Collector als herstellerneutrale Vermittlungsschicht arbeitet: Er empfängt Traces, Logs und Metriken aus mehreren Quellen, verarbeitet sie bei Bedarf und sendet sie anschließend an ein oder mehrere Ziele. Er besteht aus Receivern zum Empfangen der Daten, Processors zum Ändern oder Ausblenden von Attributen beziehungsweise zum Erstellen von Stichproben, Exporters zum Senden der Daten und Pipelines zum Festlegen des Pfads für jeden Signaltyp sowie aus Connectors zum Verbinden zweier Pipelines.
Für Entwicklungszwecke schlägt der Beitrag eine einfache Konfiguration vor, die Daten über OTLP mittels gRPC oder HTTP empfängt und an ein Debug-Modul exportiert. Dabei wird der SpanMetrics Connector verwendet, um die Span-Dauer in Metrikdaten umzuwandeln, die bei der Überwachung von Latenzproblemen helfen. Anschließend stellt der Beitrag drei Open-Source-Tools vor, die zusammen mit dem Collector und Docker Compose betrieben werden können: OTel Desktop Viewer zur Anzeige von Traces, otel-tui zur Anzeige von Traces, Logs und Metriken sowie von Servicebeziehungen über eine Terminaloberfläche und OTel Front zur Anzeige derselben drei Typen mit einem Dashboard.
Zu berücksichtigende Einschränkungen
Die Erfahrung zeigt, dass diese Tools nicht frei von Hindernissen sind. Ihre Einrichtung war für die Autorinnen aufgrund ihrer Vorerfahrung mit dem OpenTelemetry Collector und Docker einfacher, während Anfänger größere Schwierigkeiten haben könnten. Außerdem basieren die Tools auf Open-Source-Projekten von Drittanbietern und sind möglicherweise nicht immer mit den neuesten Versionen der OpenTelemetry-API und des SDKs kompatibel oder bieten keine vollständige Funktionsparität.
Der Beitrag hebt weiterreichende Herausforderungen im Ökosystem hervor, darunter die unterschiedlich starke Aktivität der Interest Groups für die einzelnen Sprachen, das Fehlen von Automatisierung für einige Sprachen wie Rust und Elixir, die große Auswahl zwischen SDKs, eBPF und Instrumentierung zur Kompilierungszeit sowie Probleme mit der Stabilität von APIs, der Aktualisierung von Abhängigkeiten und einer hohen Kardinalität bestimmter Attribute.
Redaktionelle Einordnung: Der praktische Wert liegt hier nicht im Hinzufügen eines weiteren Tools, sondern darin, Observability von einer aufgeschobenen Aufgabe in einen Bestandteil des Entwicklungszyklus von Code zu verwandeln. Der Leitfaden definiert einen reibungsarmen Ausgangspunkt und setzt anschließend klare Grenzen für das, was Automatisierung nicht wissen kann. Die Quelle liefert jedoch weder einen quantitativen Leistungsvergleich zwischen den Tools noch den Nachweis, dass ein einziger Weg für alle Sprachen oder Umgebungen geeignet ist. Daher sollten die Empfehlungen als Einstiegsrahmen verstanden werden, wobei Konfigurationen getestet und Datenvolumen, Kosten sowie die Eignung für die tatsächliche Anwendung überprüft werden sollten.