Was ist OpenTelemetry?

OpenTelemetry erklärt

OpenTelemetry, kurz OTel, ist der offene Standard für die Erzeugung von Observability-Daten. Das Projekt der Cloud Native Computing Foundation (CNCF) entstand 2019 aus der Zusammenführung zweier Vorgänger, OpenTracing und OpenCensus. Inzwischen zählt es zu den aktivsten Projekten im Cloud-native-Ökosystem, mit Beiträgen von Anwenderunternehmen und praktisch allen großen Observability-Anbietern.

Das Problem, das OTel löst, ist schnell beschrieben: Früher lieferte jeder Monitoring-Anbieter eigene Agents, Bibliotheken und Datenformate. Wer eine Anwendung instrumentierte, legte sich auf einen Anbieter fest; ein Wechsel bedeutete, alles neu zu instrumentieren. OpenTelemetry trennt das Erzeugen von Telemetrie von ihrer Analyse. Sie instrumentieren einmal gegen eine herstellerneutrale API, und die Daten können an jedes Backend gehen, das das OpenTelemetry Protocol (OTLP) unterstützt.

Ebenso wichtig ist, was OpenTelemetry nicht ist: Es speichert keine Daten, zeichnet keine Dashboards und verschickt keine Alerts. Das übernimmt ein Observability-Backend. OTel ist die Infrastruktur und die gemeinsame Sprache davor.

Signale: Traces, Metriken, Logs und Profile

OpenTelemetry bezeichnet jede Art von Telemetrie als Signal. Jedes Signal hat ein eigenes Datenmodell, eine eigene API und einen eigenen Reifegrad:

Signal	Was es erfasst	Status
Traces	Den Weg eines Requests durch ein verteiltes System als Baum aus Spans mit Timing, Status und Attributen	Stabil
Metriken	Messwerte wie Counter, Gauges, Up-Down-Counter und Histogramme (inklusive exponentieller Histogramme), mit Exemplars als Verweis auf Traces	Stabil
Logs	Zeitgestempelte Einträge; OTel bindet bestehende Logging-Bibliotheken an und ergänzt Trace-Kontext	Stabil
Profile	Kontinuierliche Stack-Samples, die zeigen, wo Code CPU und Speicher verbraucht, verknüpfbar mit Traces	Public Alpha (2026)

Drei Konzepte verbinden die Signale. Context Propagation überträgt Trace- und Span-IDs über Prozessgrenzen hinweg, standardmäßig per W3C-Trace-Context-Header traceparent. Baggage transportiert frei definierbare Key-Value-Paare, etwa eine Mandanten-ID, auf demselben Weg. Resources beschreiben die Quelle der Telemetrie (Service-Name, Version, Host, Kubernetes-Pod, Cloud-Region) und hängen an jedem Signal – genau das macht signalübergreifende Korrelation möglich.

Die Komponenten von OpenTelemetry

API und SDKs

Die API legt fest, wie Code Spans erzeugt, Metriken erfasst und Logs schreibt. Sie ist bewusst schlank, damit Bibliotheken davon abhängen können, ohne ihren Nutzern eine Implementierung aufzuzwingen; ohne SDK sind API-Aufrufe wirkungslos. Das SDK ist die Implementierung, die Anwendungen konfigurieren: Sampler, Processors, Exporter und Resource Detection. OpenTelemetry pflegt SDKs für zahlreiche Sprachen, darunter Java, .NET, Python, Go, JavaScript/Node.js, C++, Rust, PHP, Ruby, Swift und Erlang/Elixir. Der Reifegrad unterscheidet sich je nach Sprache und Signal.

Instrumentierung

Telemetrie entsteht auf drei Wegen. Zero-Code-Instrumentierung (automatische Instrumentierung), etwa der Java-Agent oder die Auto-Instrumentierung für Python und .NET, klinkt sich zur Laufzeit in verbreitete Frameworks und Bibliotheken ein. Instrumentierungsbibliotheken ergänzen OTel-Unterstützung für bestimmte Frameworks, HTTP-Clients, Datenbanktreiber und Messaging-Systeme. Manuelle Instrumentierung nutzt die API direkt, um fachlich relevante Spans und Attribute wie Bestellwert oder Kundensegment hinzuzufügen. Auf Kubernetes kann der OpenTelemetry Operator Auto-Instrumentierung per Annotation in Workloads injizieren, und eBPF-basierte Ansätze erfassen einen Teil der Telemetrie ganz ohne Eingriff in den Anwendungscode.

Semantic Conventions

Semantic Conventions sind das gemeinsame Vokabular von OTel: standardisierte Namen und Bedeutungen für Attribute, Spans und Metriken. Beispiele sind service.name, http.request.method, http.response.status_code, db.system und k8s.pod.name. Weil alle Bibliotheken und Anbieter dieselben Namen verwenden, funktioniert eine Abfrage zur HTTP-Latenz unabhängig davon, welche Sprache oder welches Framework die Daten erzeugt hat. Konventionen gibt es für HTTP, Datenbanken, Messaging, RPC, Cloud-Provider, Kubernetes, Exceptions und inzwischen auch für generative KI.

OTLP

Das OpenTelemetry Protocol (OTLP) definiert, wie Telemetrie zwischen SDKs, Collectors und Backends kodiert und übertragen wird. Es nutzt Protocol Buffers über gRPC (Standardport 4317) oder HTTP (Standardport 4318, mit Protobuf- oder JSON-Payload). OTLP hat sich zum De-facto-Austauschformat für Observability-Daten entwickelt; die meisten kommerziellen und quelloffenen Backends akzeptieren es nativ.

Der Collector

Der OpenTelemetry Collector ist ein herstellerunabhängiger Dienst, der Telemetrie empfängt, verarbeitet und exportiert. Eine Collector-Konfiguration definiert Pipelines aus folgenden Bausteinen:

• Receivers nehmen Daten an, etwa per OTLP, Prometheus-Scraping, Host-Metriken, Kafka oder Logdateien.
• Processors bündeln, filtern, sampeln, schwärzen oder reichern Daten an, zum Beispiel mit Kubernetes-Metadaten oder per Tail-based Sampling.
• Exporters senden Daten an ein oder mehrere Backends.
• Connectors verbinden Pipelines, etwa um RED-Metriken aus Spans abzuleiten.
• Extensions übernehmen Health Checks, Authentifizierung und weitere betriebliche Aufgaben.

Collectors laufen typischerweise als Agent (Sidecar oder DaemonSet direkt bei den Workloads) und/oder als Gateway (zentrale, skalierbare Schicht). Das Projekt liefert eine Core- und eine Contrib-Distribution mit Hunderten Community-Komponenten; eigene Distributionen mit genau den benötigten Komponenten lassen sich ebenfalls bauen.

So funktioniert OpenTelemetry Ende zu Ende

1. Ein instrumentierter Service empfängt einen Request. Das SDK erzeugt einen Root-Span oder setzt einen bestehenden Trace fort, falls ein traceparent-Header mitgeliefert wird.
2. Instrumentierungsbibliotheken legen Child-Spans für ausgehende HTTP-Aufrufe, Datenbankabfragen und Nachrichten an und injizieren den Trace-Kontext in jeden ausgehenden Request.
3. Metriken werden über Instrumente erfasst; Logeinträge aus angebundenen Logging-Bibliotheken tragen automatisch die aktive Trace- und Span-ID.
4. Das SDK bündelt die Telemetrie und exportiert sie per OTLP, meist an einen lokalen Collector.
5. Der Collector reichert die Daten an, filtert, sampelt und maskiert sie und exportiert sie an ein oder mehrere Observability-Backends, wo sie gespeichert, korreliert und analysiert werden.

Eine minimale Collector-Pipeline, die OTLP empfängt, Kubernetes-Metadaten ergänzt, bündelt und alles per OTLP weiterleitet:

receivers:
  otlp:
    protocols:
      grpc:
      http:
processors:
  k8sattributes:
  batch:
exporters:
  otlphttp:
    endpoint: https://otlp.example.com
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [k8sattributes, batch]
      exporters: [otlphttp]

Warum Teams auf OpenTelemetry setzen

• Kein Vendor-Lock-in. Instrumentierung ist vom Backend entkoppelt; Anbieter lassen sich per Exporter-Konfiguration wechseln, kombinieren oder evaluieren.
• Konsistente Daten. Dank Semantic Conventions nutzen alle Teams und Sprachen dieselben Attributnamen – Voraussetzung für serviceübergreifende Abfragen und gemeinsame Dashboards.
• Eingebaute Korrelation. Gemeinsamer Kontext und Resources verknüpfen Traces, Metriken, Logs und Profile ohne selbst gebauten Klebecode.
• Breite Unterstützung. Frameworks, Cloud-Dienste und Infrastrukturprojekte liefern zunehmend nativ OTel-Daten.
• Kontrolle über die Daten. Mit dem Collector filtern, sampeln und schwärzen Sie Telemetrie, bevor sie Ihre Umgebung verlässt – gut für Kosten und Datenschutz gleichermaßen.

OpenTelemetry Schritt für Schritt einführen

Kaum ein Unternehmen beginnt auf der grünen Wiese; meist laufen bereits proprietäre Agents, Prometheus-Exporter und Log-Shipper. Ein pragmatischer Migrationspfad sieht so aus:

1. Zuerst Collectors ausrollen. Setzen Sie eine Collector-Schicht vor Ihr bisheriges Backend. Sie kann OTLP empfangen, Prometheus-Endpunkte scrapen und Logdateien lesen. Bestehende Daten fließen weiter, und Sie gewinnen einen zentralen Steuerungspunkt.
2. Eine kritische User Journey instrumentieren. Ergänzen Sie Zero-Code-Instrumentierung für die Services hinter Login oder Checkout und prüfen Sie, ob die Traces Ende zu Ende vollständig sind.
3. Konventionen vereinbaren. Veröffentlichen Sie einen kurzen internen Leitfaden zu Resource-Attributen, Benennung und den fachlichen Attributen, die Teams ergänzen sollen.
4. Ausweiten und ablösen. Rollen Sie die Instrumentierung Service für Service aus und entfernen Sie proprietäre Agents, sobald die OTel-Abdeckung gleichwertig ist.

Da der Collector parallel an mehrere Ziele exportieren kann, lassen sich altes und neues Backend während einer Evaluierung nebeneinander betreiben und auf identischen Daten vergleichen. So treffen Sie die Entscheidung auf Basis echter Messwerte statt auf Basis von Datenblättern.

Best Practices und typische Fehler

• Resource-Attribute bewusst setzen. Definieren Sie immer service.name, service.version und deployment.environment.name. Fehlende oder uneinheitliche Service-Namen sind die häufigste Ursache für verwirrende Daten.
• Mit Zero-Code starten, dann manuelle Spans ergänzen. Auto-Instrumentierung schafft schnell breite Abdeckung; manuelle Spans und Attribute liefern den fachlichen Kontext, der Traces erst wirklich nützlich macht.
• Einen Collector nutzen, auch in kleinen Setups. Er zentralisiert Retries, Batching, Sampling und Schwärzung und ermöglicht Backend-Wechsel ohne Änderungen an den Services.
• Tail-based Sampling für Debugging-Wert. Behalten Sie alle Fehler und langsamen Traces und sampeln Sie die gesunde Mehrheit. Dafür müssen alle Spans eines Traces beim selben Collector landen, etwa per Load Balancing nach Trace-ID.
• Kardinalität von Metrik-Attributen im Blick behalten. Nutzer-IDs oder vollständige URLs in Metrik-Attributen lassen die Zahl der Zeitreihen explodieren. Solche Felder gehören auf Spans und Logs.
• Context Propagation nicht unterbrechen. Prüfen Sie, ob der Trace-Kontext Message Queues, asynchrone Worker, Proxys und externe Gateways übersteht.
• Versionen der Semantic Conventions verfolgen. Manche Konventionen, insbesondere für HTTP, wurden bei der Stabilisierung umbenannt. Versionen festlegen und Migrationen planen, damit Dashboards nicht unbemerkt brechen.
• Sensible Daten früh maskieren. Entfernen oder hashen Sie personenbezogene Daten in URLs, Headern und Logtexten per Collector-Processor vor dem Export – ein wichtiger Baustein für die DSGVO-Konformität.

Wie Obseria unterstützt

Obseria ist OpenTelemetry-nativ: Die Plattform nimmt OTLP-Traces, -Metriken, -Logs und -Profile direkt aus Ihren bestehenden SDKs und Collectors an; der erste Trace ist typischerweise innerhalb von 15 Minuten sichtbar. Semantic Conventions werden ohne Zusatzkonfiguration verstanden, sodass Service-Maps in Obseria TopoGraph, RED-Metriken und signalübergreifende Korrelation ohne eigenes Mapping funktionieren. Obseria Pipeline ergänzt Filterung, Anreicherung, PII-Maskierung und Routing beim Ingest, Tail-based Sampling behält die relevanten Traces. Wo Sie nicht überall SDKs ausrollen möchten, ergänzt der Obseria Agent die OTel-Daten. Und da Sie jederzeit per OTLP exportieren können, bleibt Ihre Instrumentierung Ihre eigene.