OpenTelemetry hat die Observability-Kriege gewonnen. Jetzt kommt der schwierige Teil.

Das Problem, über das niemand genug spricht

Sie betreiben ein verteiltes System in der Produktion. Etwas stimmt nicht – die Latenz ist gestiegen, Fehlerraten sind hoch, ein Benutzer erstellt ein Support-Ticket. Ihr erster Instinkt ist, in Logs zu schauen. Aber welcher Dienst? Sie haben zwölf davon. Die Logs sind da, irgendwo, verstreut über drei verschiedene Tooling-Stacks, die von Entwicklern hinterlassen wurden, die inzwischen weitergezogen sind. Sie grep-en. Sie pivotieren. Zwanzig Minuten später finden Sie die Ursache: Eine Datenbankabfrage, die anfing, Zeitüberschreitungen zu verursachen, weil eine Schema-Migration auf dem falschen Host ausgeführt wurde.

Das ist das Observability-Problem. Nicht die Alarmierung. Nicht die Dashboards. Das grundlegende Problem: zu verstehen, was tatsächlich in Ihren Systemen passiert, wenn etwas schiefgeht – und zunehmend, bevor es schiefgeht. Die drei kanonischen Signale sind Logs (diskrete Ereignisse), Metriken (numerische Messungen über die Zeit) und Traces (der Weg einer Anfrage durch ein verteiltes System). Vor OpenTelemetry war es wirklich mühsam, alle drei auf kohärente, portable Weise zu sammeln.

Die Lock-in-Ära

Jeder Observability-Anbieter – Datadog, New Relic, Dynatrace, Honeycomb, Jaeger – lieferte sein eigenes SDK aus. Seinen eigenen Agenten. Sein eigenes Wire-Protokoll. Wenn Sie Ihren Python-Dienst mit dem Datadog-Tracer instrumentiert und später beschlossen hatten, Honeycomb zu evaluieren, standen Sie vor der Aufgabe, Ihre Instrumentierungsschicht neu zu schreiben. Nicht, weil die Anbieter böswillig waren, sondern weil es keinen Standard gab. Die Telemetrie-Erfassungsschicht war der Burggraben.

Das war keine kleine Unannehmlichkeit. Es bedeutete, dass Teams frühzeitig Anbieterentscheidungen trafen, bevor sie genügend Produktionsdaten hatten, um zu wissen, was sie eigentlich brauchten. Es bedeutete, dass Plattformteams Entwicklungszyklen damit verbrachten, mehrere Telemetrie-Pipelines zu warten. Es bedeutete, dass die Wechselkosten hoch genug waren, dass die meisten Teams einfach nicht wechselten – selbst wenn ein besseres Tool auftauchte.

Wo OpenTelemetry herkam

Im Jahr 2019 fusionierten zwei konkurrierende Open-Source-Observability-Projekte – OpenCensus (unterstützt von Google) und OpenTracing (ein CNCF-Projekt) – zu OpenTelemetry. Die Fusion verhinderte, was eine schädliche Fragmentierung des Ökosystems gewesen wäre. OpenTelemetry wurde ein CNCF-Projekt und wuchs schnell. Gemessen an der Anzahl der Mitwirkenden ist es jetzt das zweitaktivste CNCF-Projekt nach Kubernetes.

Das Wertversprechen war einfach: einmal instrumentieren, überall exportieren. Ein SDK pro Sprache. Ein Wire-Protokoll – OTLP (OpenTelemetry Protocol). Ein Collector – otel-collector – zum Empfangen, Verarbeiten und Exportieren von Telemetrie an jedes Backend. Anbieter konkurrieren bei Analyse und Visualisierung, nicht bei der Instrumentierungs-Lock-in.

Der Stand von OTel im Jahr 2026

Die Wette hat sich ausgezahlt. OpenTelemetry wird in der Produktion bei Google, Microsoft, Shopify, Uber und Tausenden anderen Organisationen eingesetzt. Jedes große Observability-Backend – Datadog, Grafana, Elastic, Honeycomb, Dynatrace, New Relic, Splunk – akzeptiert OTLP nativ. Die CNCF berichtet, dass OpenTelemetry bei 83 % der Fortune-500-Unternehmen in irgendeiner Form genutzt wird. Das ist kein Nischenprojekt mehr. Das ist Infrastruktur.

Die Go-, Java-, Python- und JavaScript-SDKs sind stabil und gut gewartet. Die Auto-Instrumentierung für gängige Frameworks – Django, Express, Spring Boot, Rails – funktioniert zuverlässig. Sie können eine einzige Abhängigkeit hinzufügen, ein paar Umgebungsvariablen setzen und haben Traces, die zu Ihrem Backend fließen, ohne Anwendungscode zu berühren. Für Greenfield-Projekte ist dies der offensichtliche Ausgangspunkt.

Was tatsächlich funktioniert

Traces sind der stärkste Teil der OTel-Geschichte. Die Tracing-Spezifikation ist ausgereift. Die SDKs sind stabil. Die Auto-Instrumentierung für HTTP, Datenbankaufrufe und Messaging-Systeme deckt die häufigsten Instrumentierungsanforderungen ab. Wenn Sie heute mit OTel beginnen, beginnen Sie hier.

Der otel-collector ist leistungsstark und produktionserprobt. Er kann Telemetrie von Dutzenden von Quellen empfangen, Transformationen anwenden, Rauschen filtern und an mehrere Backends gleichzeitig weiterleiten. Teams, die komplexe Multi-Cloud-Umgebungen betreiben, nutzen den Collector als Telemetrie-Routing-Schicht – exportieren Sie alles an den Collector, lassen Sie den Collector das Backend-Routing übernehmen.

Das Ökosystem ist ebenfalls um den Collector herum gereift. Contrib-Receiver und -Exporter decken die meisten Unternehmensdatenquellen ab. Der Operator für Kubernetes ist solide. Anbieter-Distributionen des Collectors (wie die AWS Distro for OpenTelemetry oder der Grafana Agent) bieten getestete, unterstützte Builds mit vorkonfigurierten anbieterspezifischen Exportern.

Was immer noch schwierig ist

Logs sind erst seit Kurzem in der OTel-Spezifikation stabil. Das Logging-Signal hinkte den Traces und Metriken deutlich hinterher, und obwohl es jetzt stabil ist, hat das Ökosystem noch nicht vollständig aufgeholt. Die Korrelation von Logs mit Traces mittels TraceId und SpanId – was der ganze Sinn ist – erfordert in den meisten Frameworks immer noch bewusste Verkabelung. Es funktioniert, aber es ist noch nicht null Aufwand.

Die semantischen Konventionen für Metriken sind sprachübergreifend inkonsistent. Eine Metrik, die im Java-SDK einen Namen hat, heißt im Python-SDK leicht anders. Dies wird angegangen, aber langsam. Teams, die sprachübergreifende Dashboards erstellen, stoßen auf diese Reibung.

Die Collector-Konfiguration ist komplex. Die otel-collector-YAML-Konfiguration – Receiver, Prozessoren, Exporter, Pipelines – ist flexibel, aber ausführlich. Wenn die Topologien wachsen, hat man es mit YAML-Dateien zu tun, die wirklich schwer zu durchschauen sind. Es gibt noch keine gute Lösung dafür. Einige Teams verwenden jsonnet oder cue, um Collector-Konfigurationen zu generieren. Andere schreiben Konfigurationsmanagement-Tooling. Es ist ein lösbares Problem, aber es ist echte operative Arbeit.

Tail-basiertes Sampling ist leistungsstark, aber operativ schwer. Head-basiertes Sampling (die Sampling-Entscheidung zu Beginn eines Traces treffen) ist einfach und zustandslos. Tail-basiertes Sampling (die Sampling-Entscheidung treffen, nachdem man den vollständigen Trace gesehen hat) ermöglicht es, 100 % der Fehler-Traces und langsamen Traces zu behalten, während routinemäßige verworfen werden – aber es erfordert zustandsbehaftete Infrastruktur. Der tailsampling-Prozessor im OTel-Collector funktioniert, erfordert aber eine sorgfältige Bereitstellungsarchitektur, um sicherzustellen, dass alle Spans eines bestimmten Traces auf derselben Collector-Instanz landen.

Das Kardinalitätsproblem, das OTel nicht gelöst hat

OpenTelemetry macht es einfach, Attribute zu Ihrer Telemetrie hinzuzufügen. Das ist eine Funktion. Es ist auch ein Schuss ins eigene Knie. Das Hinzufügen von Attributen mit hoher Kardinalität – Benutzer-IDs, Anfrage-IDs, Sitzungstoken – zu Metriken ist ein klassischer Fehler, der zu Kostenexplosionen bei Backends führt, die pro Metrik-Serie abrechnen (was die meisten tun).

OTel schützt Sie nicht davor. Es leitet getreu alle Attribute weiter, die Sie anhängen. Die Kardinalitätsexplosion ist ein Backend-Problem, aber OTel ist der Mechanismus, mit dem Sie sie erzeugen. Teams, die OTel einführen, müssen dies früh verstehen: Metrik-Kardinalitäts-Governance ist nicht optional, sondern operative Hygiene. Verwenden Sie Attribute mit hoher Kardinalität bei Spans und Logs, wo sie hingehören. Halten Sie Metrik-Dimensionen niedrig und bewusst begrenzt.

Das vierte Signal: Profiling

OpenTelemetry arbeitet an einem vierten Observability-Signal: kontinuierliches Profiling. Profiling-Daten – CPU-Flamegraphs, Speicherallokations-Traces – lebten historisch in separaten Tools (pprof, async-profiler, py-spy) ohne Standardformat oder Korrelation mit den anderen drei Signalen.

Das OTel-Profiling-Signal ist noch experimentell, aber Grafana, Elastic und mehrere andere Anbieter setzen bereits darauf. Das Ziel ist dasselbe wie bei den anderen Signalen: ein Standardformat, ein Standard-Wire-Protokoll, Korrelation mit Traces. Wenn es sich stabilisiert, wird es die letzte große Lücke in der OTel-Observability-Geschichte schließen.

Praktische Ratschläge für Teams, die OTel heute einführen

• Beginnen Sie mit Traces. Das Tracing-Signal ist am ausgereiftesten. Verwenden Sie zuerst die Auto-Instrumentierung – instrumentieren Sie nicht manuell, bevor Sie gesehen haben, was die Auto-Instrumentierung Ihnen liefert.
• Wählen Sie Ihr Backend, bevor Sie den Collector konfigurieren. Die Pipeline-Konfiguration des Collectors hängt davon ab, wohin Sie exportieren. Bauen Sie keine komplexe Collector-Topologie, bevor Sie Ihr Backend kennen. Ein einzelner Exporter ist für den Anfang in Ordnung.
• Bauen Sie nicht voreilig eine benutzerdefinierte Collector-Topologie. Die verwalteten OTLP-Endpunkte der meisten Anbieter sind für die meisten Teams gut genug. Der Collector fügt operativen Overhead hinzu. Fügen Sie ihn hinzu, wenn Sie Fan-Out, Filterung oder Anreicherung benötigen – nicht vorher.
• Verstehen Sie Kardinalität, bevor Sie Metrik-Attribute hinzufügen. Führen Sie ein Gespräch mit demjenigen, der die Observability-Rechnung verwaltet, bevor Sie Ihre erste benutzerdefinierte Metrik ausliefern. Definieren Sie Ihren erlaubten Label-Satz explizit.
• Verwenden Sie die SDKs, nicht direkt die API. Die OTel-API ist der stabile Vertrag; das SDK ist die Implementierung. Hängen Sie im Anwendungscode vom SDK ab. Hängen Sie nur dann direkt von der API ab, wenn Sie eine Bibliothek schreiben, die Verbrauchern keine SDK-Wahl aufzwingen soll.

Der Krieg ist gewonnen. Die Arbeit ist nicht getan.

OpenTelemetry hat etwas erreicht, das in der Infrastruktur-Software wirklich selten ist: Es hat das Instrumentierungs-Lock-in-Problem beseitigt. Anbieter konkurrieren um die Qualität ihrer Analyse, ihrer Abfragesprachen, ihrer Alarmierung, ihrer Benutzererfahrung – nicht darum, Sie in ihrem SDK gefangen zu halten. Das ist eine bessere Welt.

Aber „Der Standard hat gewonnen“ ist der Anfang der Geschichte, nicht das Ende. Der schwierige Teil – konsistente sprachübergreifende Konventionen, zugängliche Collector-Konfiguration, stabile Logs, Kardinalitäts-Governance, Profiling – wird noch bearbeitet. Teams, die OTel heute einführen, tun dies in einem reifen, aber sich noch entwickelnden Ökosystem. Das ist in Ordnung. Das Fundament ist solide. Bauen Sie bewusst darauf auf.