OpenTelemetry hat sich als Observability-Standard durchgesetzt – jetzt kommt der schwierige Teil: die tatsächliche Nutzung

Vor drei Jahren standen Engineering-Teams vor der schmerzhaften Wahl, entweder proprietäre Agents eines Anbieters zu übernehmen und sich damit zu binden, oder verschiedene Open-Source-Tools zusammenzustückeln und den Wartungsaufwand zu akzeptieren. OpenTelemetry – das CNCF-Projekt, das 2019 OpenCensus und OpenTracing vereinte – hat diese Entscheidung weitgehend obsolet gemacht. Bis 2026 hat es sich zum De-facto-Standard für die Telemetriedatenerfassung in der gesamten Branche entwickelt.

Datadog, Honeycomb, Grafana, New Relic, Dynatrace und Splunk akzeptieren alle nativ OpenTelemetry-Daten. Cloud-Anbieter wie AWS, Google Cloud und Azure bieten native OpenTelemetry-Integration. Die SDKs für Python, Java, Go, JavaScript und .NET haben stabile Releases erreicht. Der OpenTelemetry Collector – die Pipeline-Komponente, die Telemetrie empfängt, verarbeitet und exportiert – ist produktiv bei Unternehmen von kleinen Startups bis zu Hyperscalern im Einsatz.

OpenTelemetry hat den Kampf um die Instrumentierung gewonnen. Nun geht es darum, es richtig einzusetzen.

Was OpenTelemetry tatsächlich standardisiert

OpenTelemetry definiert drei Telemetriesignale: Traces (den Weg einer Anfrage durch verteilte Dienste), Metriken (numerische Messwerte über die Zeit) und Logs (strukturierte Ereignisprotokolle). Das Projekt bietet SDKs zur Generierung dieser Signale, ein Drahtformat (OTLP – OpenTelemetry Protocol) zur Übertragung und den Collector zur Weiterleitung an Backends.

Was es nicht standardisiert, ist, was man mit den Daten macht, sobald man sie hat. Die Abfragesprachen, Alerting-Modelle, Dashboard-Tools und Analyse-Workflows sind alle backend-spezifisch. Der Wechsel von Datadog zu Grafana erfordert immer noch das Neuschreiben von Dashboards und Alerts – die Datenerfassungsebene ist portabel, die Analyseebene nicht. Das ist das "Observability-Portabilitäts"-Problem, an dem die Industrie noch arbeitet.

Wo Teams hängen bleiben

Die häufigste Fehlerquelle ist, OpenTelemetry als Abhakübung zu betrachten, statt als Praxis. Teams instrumentieren ihre Dienste, sehen Traces in ihrem Observability-Backend und erklären den Erfolg für vollendet. Sechs Monate später, bei einem Produktionsvorfall, stellen sie fest, dass die Traces unvollständig sind (einige Dienste wurden nicht instrumentiert), die Spans keine nützlichen Attribute enthalten (keine Benutzer-IDs, keine Feature-Flags, kein Geschäftskontext) und die Kardinalität ihrer Metriken die Grenzen des Backends gesprengt hat.

Die Qualität der Instrumentierung ist die erste Lücke. Die Auto-Instrumentierung – bei der das SDK automatisch Spans für HTTP-Aufrufe, Datenbankabfragen und Message-Queue-Operationen generiert – erfasst das strukturelle Gerüst einer Anfrage, aber nichts von der Geschäftslogik. Ob ein API-Call für einen Premium-Kunden oder einen Free-Tier-Kunden war, welches Feature-Flag aktiv war, wie hoch der Warenkorb war: Dies sind Attribute, die eine manuelle Instrumentierung erfordern. Die Teams, die den größten Nutzen aus OpenTelemetry ziehen, behandeln Span-Attribute als Ergebnis bewussten Designs und nicht automatischer Generierung.

Kardinalität ist die zweite Lücke. Jede eindeutige Kombination von Attributwerten erzeugt eine neue Zeitreihe in einem Metrik-Backend. Eine Metrik, die mit Benutzer-ID, Region, Feature-Flag und HTTP-Statuscode getaggt ist, kann Millionen verschiedener Reihen erzeugen – und viele Observability-Backends berechnen nach Zeitreihen oder setzen harte Limits. Teams, die Metriken instrumentieren, ohne sich Gedanken über die Kardinalität zu machen, zahlen entweder unerwartet hohe Observability-Rechnungen oder stoßen genau dann auf Datenverlustgrenzen, wenn sie die Daten am dringendsten benötigen.

Der Collector als strategisches Gut

Der OpenTelemetry Collector ist wohl die am meisten untergenutzte Komponente im Ökosystem. Die meisten Teams setzen ihn als einfachen Weiterleiter ein – empfangen OTLP von Diensten, exportieren an das Backend. Die Prozessor-Pipeline des Collectors kann jedoch wesentlich mehr: Herausfiltern von Hochkardinalitätsdaten, bevor sie das Backend erreicht, Sampling von Traces basierend auf Geschäftsregeln (100% Sampling von Fehler-Traces, 1% von erfolgreichen), Anreicherung von Spans mit Metadaten aus Kubernetes oder Service Discovery, und Routing verschiedener Signale an verschiedene Backends.

Eine gut konfigurierte Collector-Pipeline kann die Observability-Kosten um 60–80 % senken, ohne wichtige Signale zu verlieren, indem sie aggressive Daten mit geringem Wert (Health-Check-Traces, routinemäßige Hintergrundjobs) verwirft, während sie alles für das Debugging und die Business Analysis Relevante bewahrt. Teams, die den Collector als sorgfältig zu konfigurierende Infrastruktur betrachten und nicht als einmaliges Deployment, extrahieren aus dem gleichen Budget deutlich mehr Wert.

Semantische Konventionen: der unterschätzte Standard

OpenTelemetrys semantische Konventionen – eine Spezifikation zur Benennung und Strukturierung von Attributen auf Spans und Metriken – sind der am meisten unterschätzte Beitrag des Projekts. Wenn jedes Team die Attribute seiner Datenbank-Spans anders benennt, kann man keine generischen Dashboards oder Alerts schreiben, die über Dienste hinweg funktionieren. Wenn alle denselben Konventionen folgen (db.system, db.statement, http.method, http.status_code), können Tools Telemetrie ohne dienstspezifische Konfiguration verstehen.

Die Übernahme der semantischen Konventionen ist in der Praxis noch unvollständing. Die stabilen Konventionen decken HTTP, Datenbanken, Messaging-Systeme und RPC ab – die häufigsten Infrastrukturmuster. Viele anwendungsspezifische Muster sind entweder nicht abgedeckt oder befinden sich noch im Experimentierstatus. Teams, die auf OpenTelemetry aufbauen, sollten Zeit investieren, um eigene Attributkonventionen für den Anwendungskontext zu definieren, den vom Projekt etablierten Namensmustern folgend, um dieselben Vorteile der Composability auf der Anwendungsebene zu erzielen.

Wie eine gute Umsetzung im Jahr 2026 aussieht

Die Teams, die 2026 den größten Nutzen aus OpenTelemetry ziehen, haben einige gemeinsame Merkmale. Sie haben ein Platform-Team oder einen Observability-Champion, der die Collector-Konfiguration und die Instrumentierungsstandards verwaltet. Sie haben einen Satz erforderlicher Span-Attribute für neue Dienste definiert und setzen diese im Code-Review durch. Sie haben eine explizite Kardinalitätsanalyse ihrer Metriken durchgeführt und bewusste Entscheidungen getroffen, welche Dimensionen beibehalten werden. Sie verwenden Tail-basiertes Sampling, um vollständige Traces für Fehler und langsame Anfragen zu erfassen, während sie Routineverkehr aggressiv sampeln.

Sie behandeln Observability-Daten auch als Produkt, nicht als Infrastruktur-Abgas. Die Frage lautet nicht „Sammeln wir Daten?", sondern „Kann der On-Call Engineer die Ursache eines Produktionsvorfalls in unter 10 Minuten finden?" Dieser Standard führt zu anderen Instrumentierungsentscheidungen als „Läuft der Collector?"

OpenTelemetry hat das schwierigste Koordinationsproblem in der Observability gelöst: die Industrie auf ein gemeinsames Datenformat zu bringen. Die nächste Schicht von Problemen – was instrumentiert werden soll, wie die Pipeline konfiguriert wird, was darauf aufgebaut wird – sind technische und organisatorische Herausforderungen, die jedes Team für sich selbst lösen muss. Die gute Nachricht: Das Fundament ist nun stabil genug, um darauf aufzubauen.