OpenTelemetry (kurz OTel) ist ein herstellerneutrales, offenes Framework zur Erfassung, Verarbeitung und Ausgabe von Telemetriedaten. Es hat sich inzwischen als De-facto-Standard für Observability in Cloud- und Kubernetes-Umgebungen etabliert: Dienste werden einmal instrumentiert, die Daten lassen sich danach an viele Backends ausliefern, ohne den Anwendungscode umzuschreiben.
Entstehung und Reifegrad
OpenTelemetry entstand 2019 durch die Zusammenlegung der beiden Projekte OpenTracing und OpenCensus, die zuvor getrennte Ansätze für verteiltes Tracing beziehungsweise Metriken verfolgt hatten. Im Mai 2019 wurde das Projekt in die Cloud Native Computing Foundation (CNCF) aufgenommen, 2021 erreichte es den Reifegrad Incubating. Im Mai 2026 wurde OpenTelemetry zum Graduated Project der CNCF erhoben – die höchste Reifestufe der Foundation, die Produktionsreife bescheinigt.
Die drei Signale: Traces, Metrics, Logs
OpenTelemetry deckt die drei klassischen Säulen der Telemetrie ab:
- Traces: verteilte Ablaufspuren über mehrere Dienste hinweg, mit Spans als Einzelschritten und Korrelations-IDs.
- Metrics: zeitreihenbasierte Messwerte wie Latenz, Fehlerrate oder Auslastung.
- Logs: strukturierte Ereignismeldungen, die über Trace- und Span-IDs mit den Spuren verknüpft werden können.
Die gemeinsame Modellierung aller drei Signale ist der Kernunterschied zu älteren, getrennten Werkzeugen: Zusammenhänge zwischen Logs, Metriken und Traces lassen sich direkt herstellen.
Aufbau: SDK, OTLP und Collector
OpenTelemetry besteht aus mehreren Ebenen. Die APIs und SDKs gibt es für praktisch alle gängigen Sprachen wie Java, Go, Python, JavaScript, .NET oder Rust. Über Auto-Instrumentierung werden gängige Bibliotheken und Frameworks oft ohne Codeänderung angebunden. Das OTLP (OpenTelemetry Protocol) ist das standardisierte Transportprotokoll für die Telemetriedaten. Der Collector ist eine zentrale Komponente, die Daten empfängt, anreichert, filtert und an ein oder mehrere Backends exportiert – entweder als Agent direkt neben der Anwendung oder als zentraler Gateway. Dazu kommen Semantic Conventions, die Attributnamen für Dienste, Operationen und Ressourcen vereinheitlichen.
Abgrenzung zu verwandten Werkzeugen
Während Observability das Konzept beschreibt, ist OpenTelemetry dessen konkrete technische Umsetzung. Prometheus bleibt ein wichtiges Backend für Metriken (etwa per OTLP-Import), Grafana das übliche Dashboard dazu; OpenTelemetry selbst ist bewusst backendneutral und exportiert auch nach Jaeger, Datadog, Elastic oder kommerziellen Observability-Plattformen. Gegenüber klassischem Monitoring, das vor allem Systemzustände beobachtet, legt OpenTelemetry den Schwerpunkt auf anwendungsnahe, verteilte Signale inklusive Logging.
In Kubernetes-Clustern wird der Collector häufig per Helm als Chart ausgerollt; die Instrumentierung betrifft vor allem containerisierte Dienste, die auf Kubernetes und Docker laufen.