OpenTelemetry ist jetzt der Standard für Observability – was das für deinen Stack wirklich bedeutet

OpenTelemetry hat 2026 eine Schwelle überschritten, die wichtiger ist als jede einzelne Downloadzahl: Es ist kein Evaluierungskandidat mehr, sondern wird zur Selbstverständlichkeit. Wenn du einen neuen Backend-Engineer einstellst und dieser nach deinem Observability-Stack fragt, ist OTel die Antwort, die er erwartet. Wenn du einen neuen Service hochziehst und nach Instrumentierung greifst, ist OTel die Bibliothek, die du nimmst. Das CNCF-Projekt, das 2019 aus der Fusion von OpenCensus und OpenTracing entstand, hat sieben Jahre später den Instrumentierungs-Standardkrieg eindeutig für sich entschieden.

Die Zahlen untermauern diese Einschätzung. Anfang 2026 nutzen 48,5 % der Organisationen aktiv OpenTelemetry, weitere 25 % planen die Implementierung. 81 % betrachten es als produktionsreif. Allein das Python SDK verzeichnete im Januar 2026 224 Millionen Downloads – 6 Millionen pro Tag. Die CNCF selbst berichtete für 2025 einen Anstieg der Commits um 43 % und der gemergten Pull Requests um 50 %. OpenTelemetry ist kein Nischenwerkzeug für Observability-Enthusiasten, es ist Infrastruktur.

Was OTel tatsächlich standardisiert – und was nicht

OpenTelemetry standardisiert drei Dinge: die APIs zur Instrumentierung von Code (wie du Telemetriedaten aussendest), die SDKs zum Sammeln und Verarbeiten dieser Daten sowie das OTLP-Protokoll zur Übertragung an ein Backend. Nicht standardisiert wird hingegen, wohin die Daten gehen oder was du damit machst, sobald sie angekommen sind.

Das ist die entscheidende architektonische Unterscheidung. OTel ist eine Pipeline, keine Datenbank oder Visualisierungsschicht. Du kannst OTel-Daten an Grafana, Datadog, Honeycomb, Dynatrace, Elastic, Jaeger, Prometheus oder jedes andere Backend senden, das OTLP spricht – und das sind 2026 praktisch alle. Der 36-prozentige Anstieg der von Anbietern stammenden OTel-Distributionen im Jahresvergleich (Anbieter, die eigene OTel-kompatible Collector und SDKs ausliefern) spiegelt die Marktrealität wider: Wenn dein Observability-Backend OTel nicht nativ unterstützt, bist du im Wettbewerbsnachteil.

Die drei Telemetriesignale, die OTel abdeckt, sind Traces (verteilte Abläufe durch einen Request über mehrere Services), Metrics (numerische Messungen im Zeitverlauf – Latenz, Fehlerraten, Durchsatz) und Logs (strukturierte Ereignisaufzeichnungen). 2026 sind Traces am ausgereiftesten und am weitesten verbreitet (50,2 % der OTel-Nutzer), gefolgt von Metrics (57 %) und Logs (48,4 %). Profiles – kontinuierliche Profiling-Daten – sind ein viertes aufstrebendes Signal, das bereits 9,2 % der Nutzer instrumentieren – ein früher Indikator dafür, wohin sich OTel entwickelt.

Der Collector: Hier liegt die meiste Produktionskomplexität

Der OpenTelemetry Collector ist die Komponente, die die eigentliche Datenverarbeitung übernimmt – Telemetrie von instrumentierten Services empfangen, Transformationen und Filter anwenden und an ein oder mehrere Backends weiterleiten. 65 % der OTel-Nutzer in der Produktion betreiben mehr als 10 Collector; große Deployments nutzen hunderte. Kubernetes bleibt die dominierende Deployment-Umgebung (81 %), wobei VM-basierte Deployments deutlich zugenommen haben (von 33 % auf 51 %), was die Adoption in Umgebungen widerspiegelt, die nicht alles containerisiert haben.

Das Pipeline-Modell des Collectors – Receiver, Processor, Exporter – verleiht ihm eine Flexibilität, die sowohl mächtig als auch operativ komplex ist. Ein gängiges Produktionsmuster: ein Sidecar-Collector pro Pod, der die anfängliche Datensammlung und grundlegende Filterung übernimmt, und ein Gateway-Collector-Cluster, das Sampling, Anreicherung und Routing-Logik anwendet, bevor es an die Backends weitergeleitet wird. Diese zweistufige Architektur trennt per-Service-Instrumentierungsbelange von clusterweiten Verarbeitungsbelangen – ein entscheidender Faktor für Skalierbarkeit.

Das häufigste operative Problem in OTel-Deployments im großen Maßstab ist das Kardinalitätsmanagement. Hochkardinale Labels auf Metrics – etwa User-IDs, Request-IDs oder andere unbegrenzte Werte als Metric-Label-Dimensionen – können zu einer Explosion der Metrikreihen führen, was Speicher- und Kostenprobleme verursacht, die die Observability teurer machen als die beobachteten Systeme selbst. Die Filter- und Transform-Processor des Collectors können Kardinalitätsgrenzen durchsetzen, aber das erfordert eine bewusste Konfiguration, die Teams oft erst priorisieren, wenn das Problem auftritt.

Instrumentierung: automatisch vs. manuell

Die Auto-Instrumentierungsbibliotheken von OTel decken den Großteil der üblichen Instrumentierungsanforderungen ab – ohne Codeänderungen. Für Java-Anwendungen instrumentiert der Java Agent automatisch HTTP-Clients und -Server, JDBC, gRPC, Kafka, Redis und Dutzende anderer Bibliotheken auf JVM-Ebene. Für Python, Node.js, .NET, Go und andere unterstützte Sprachen deckt die Auto-Instrumentierung die Frameworks und Bibliotheken ab, die die meisten Anwendungen nutzen.

Mit Auto-Instrumentierung bekommst du 80 % des Werts bei minimalem Aufwand. Die restlichen 20 % – die eigentliche Geschäftslogik instrumentieren, benutzerdefinierte Attribute mit Domänenkontext hinzufügen, Spans für Operationen erstellen, die sich nicht auf Bibliotheksaufrufe abbilden – erfordern manuelle Instrumentierung mit den OTel-APIs. Die Disziplinen sind unterschiedlich: Auto-Instrumentierung ist ein Deployment-Konfigurationsproblem, manuelle Instrumentierung ein Problem der Codequalität und des architektonischen Verständnisses.

Die wertvollsten Ziele für manuelle Instrumentierung sind nicht allgemeine „Füge überall Spans hinzu“-Ratschläge – sie sind spezifisch für das, was das Verhalten deines Systems beobachtbar macht. Welche Operationen benötigen eine Latenzverteilung, die du verstehen musst? Welche Attribute auf Domänenebene (Kundenstufe, Feature-Flag-Werte, Ressourcenkennungen) musst du serviceübergreifend korrelieren, wenn du einen Incident untersuchst? Manuelle Instrumentierung, die diese Fragen beantwortet, ist weitaus wertvoller als eine gleichmäßige Abdeckung von allem.

Sampling: das ungelöste Spannungsfeld

Jeden Request in einem hochvolumigen Produktionssystem im Detail zu tracen, ist wirtschaftlich nicht praktikabel. Ein Service, der 10.000 Requests pro Sekunde verarbeitet, erzeugt enorme Trace-Volumen, wenn jeder Request einen vollständigen Trace produziert. Sampling – nur einen Bruchteil der Traces aufzeichnen – ist eine praktische Notwendigkeit, erzeugt aber eine grundlegende Spannung: Genau die Traces, die du zum Debuggen am dringendsten brauchst (Fehlerpfade, langsame Ausreißer, ungewöhnliche Sequenzen), sind die Traces, die du bei naivem Sampling am ehesten verpasst.

Head-based Sampling (Entscheidung zu Beginn, ob ein Request getraced wird) ist einfach zu implementieren, aber blind für das Ergebnis – du kannst nicht wissen, ob ein Request interessant wird, bis er abgeschlossen ist. Tail-based Sampling (Entscheidung im Nachhinein, Traces behalten, die Kriterien wie Fehlerauftreten oder Latenzschwellen erfüllen) ist intelligenter, erfordert aber die Pufferung vollständiger Traces, bevor Sampling-Entscheidungen getroffen werden können, was Latenz und Speicheraufwand für den Collector erhöht.

Der Tail Sampling Processor von OTel implementiert Tail-based Sampling im Collector und ist produktionsreif verfügbar. Die Konfiguration ist nicht trivial – du musst Richtlinien definieren (alle Fehler behalten, Requests über X Millisekunden behalten, eine Basis-Zufallsstichprobe von allem anderen) und die Puffergrößen entsprechend abstimmen. Teams, die in die Einrichtung von Tail Sampling investieren, erhalten ein drastisch besseres Signal-Rausch-Verhältnis bei ihren Traces. Teams, die Head-based Sampling mit einer festen Rate verwenden, bekommen eine ausreichende Abdeckung für die meisten Zwecke, verpassen aber den langen Schwanz interessanter Ereignisse.

Wohin OTel sich entwickelt: Profiles und mehr

Die CNCF hat OpenTelemetry für den Graduierten-Projektstatus im Jahr 2026 vorgesehen – die höchste Reifegradbezeichnung im CNCF-Lebenszyklus, die derzeit Projekte wie Kubernetes, Prometheus und Envoy innehaben. Die Graduierung von OTel signalisiert, dass das Projekt stabil, weit verbreitet ist und die Governance-Reife bewiesen hat, um als fundamentale Infrastruktur zu gelten.

Die nächste Fähigkeitsgrenze ist Continuous Profiling – das vierte Telemetriesignal, das OpenTelemetry nun abdeckt. Continuous Profiling erfasst CPU-, Speicher- und Goroutine-/Thread-Level-Daten von laufenden Prozessen in regelmäßigen Abständen und ermöglicht so die Korrelation zwischen Trace-Level-Performance und dem tatsächlich ausgeführten Code während langsamer Requests. Die Korrelation eines langsamen Traces mit einem CPU-Profil, das zeigt, welche Funktion während dieses Request-Fensters Rechenleistung verbraucht hat, ist genau die Art von Multisignal-Analyse, die OTel durch sein einheitliches Datenmodell möglich macht.

Wenn du 2026 nicht OTel einsetzt, bist du nicht hinter einer Technologiekurve zurück – du bist hinter einem Industriestandard. Die Evaluierungsphase ist vorbei. Die Frage ist, wie du deine Telemetriedaten effektiv instrumentierst, sammelst und weiterleitest – mit Werkzeugen, die sich nun weitgehend auf OTel als Fundament geeinigt haben.