Betrieb & Monitoring
OpenTelemetry
OpenTelemetry (OTel) ist ein herstellerneutrales Framework, das Telemetrie (Traces, Metriken, Logs) standardisiert erzeugt, sammelt und exportiert, nicht speichert.
- Herstellerneutraler Standard
- Drei Signale: Traces, Metriken, Logs
- OTLP als Übertragungsformat
- Collector als Datendrehscheibe
- CNCF graduated, Apache 2.0
OpenTelemetry (OTel) ist ein herstellerneutrales Framework, um Telemetriedaten zu erzeugen, zu sammeln und zu exportieren. Es entstand 2019 aus dem Zusammenschluss von OpenTracing und OpenCensus und ist heute ein CNCF-Projekt mit hohem Reifegrad. Die Kernidee ist Vendor-Neutralität: Anwendungen werden einmal instrumentiert und ihre Daten lassen sich an ein beliebiges Backend exportieren, ohne den Code zu ändern.
Dieser Artikel erklärt die drei Signale (Traces, Metriken, Logs), das Übertragungsprotokoll OTLP, den OpenTelemetry Collector mit seiner Pipeline, manuelle und automatische Instrumentierung, Semantic Conventions, die Kontext-Weitergabe über W3C Trace Context sowie die wichtige Abgrenzung, dass OTel kein Speicher- und Visualisierungs-Backend ist. Backends sind etwa Prometheus, Loki, Tempo/Jaeger und Grafana.
1. Die drei Signale
OTel deckt drei Arten von Telemetrie ab, die zusammen Observability ergeben:
- Traces verteilte Nachverfolgung einer Anfrage über Service-Grenzen hinweg; ein Trace besteht aus Spans (einzelne Arbeitseinheiten mit Trace-/Span-ID, Zeitstempeln, Attributen).
- Metrics numerische Messwerte mit Instrument-Typen wie Counter, UpDownCounter, Gauge und Histogram.
- Logs Ereignisprotokolle, über eine Bridge an bestehende Logging-Frameworks angebunden und automatisch mit Trace-/Span-IDs korreliert.
2. OTLP: das gemeinsame Protokoll
OTLP (OpenTelemetry Protocol) ist das standardisierte Übertragungsformat für alle drei Signale. Es läuft über gRPC (Standard-Port 4317) oder HTTP (Port 4318) und nutzt Protocol Buffers, optional gzip-komprimiert. Statt für jedes Backend ein eigenes Format zu sprechen, exportiert eine instrumentierte Anwendung einheitlich per OTLP, und nur der Empfänger (Collector oder Backend) muss es verstehen.
3. Der OpenTelemetry Collector
Der Collector ist eine eigenständige, herstellerneutrale Komponente mit einer dreistufigen Pipeline: Receiver (empfängt Telemetrie in verschiedenen Formaten) → Processor (transformiert, batcht, filtert) → Exporter (leitet an ein oder mehrere Backends weiter). Er läuft als Agent direkt neben dem Dienst oder als zentrales Gateway für viele Dienste. So entkoppelt er die Anwendung vom Backend: Die App gibt Daten schnell ab, der Collector kümmert sich um Retry, Batching und Routing.
Der Collector ist das eigentliche Architektur-Argument für OpenTelemetry. Er ist die herstellerneutrale Drehscheibe, über die sich das Backend austauschen lässt, ohne eine einzige Anwendung neu zu instrumentieren.
4. Instrumentierung und Semantic Conventions
Es gibt zwei Wege, Telemetrie zu erzeugen: manuelle Instrumentierung über die SDKs (volle Kontrolle, eigene Spans und Attribute) und Zero-Code/Auto-Instrumentation, die ohne Code-Änderung aus Bibliotheken und Runtime Daten zieht (schneller Einstieg, etwa für Java, .NET, Python, Go, Node.js, PHP). Die Semantic Conventions standardisieren die Attribut-Namen (für HTTP, Datenbanken, Messaging und mehr), damit Daten aus verschiedenen Sprachen und Bibliotheken im Backend konsistent auswertbar sind.
5. Kontext-Weitergabe und Backend-Abgrenzung
Damit ein Trace über mehrere Dienste zusammenhält, wird der Trace-Kontext über Service-Grenzen weitergereicht (Context Propagation). OTel nutzt dafür den offenen Standard W3C Trace Context mit dem HTTP-Header traceparent. Entscheidend für die Erwartungshaltung: OTel speichert und visualisiert selbst nichts. Für Auswertung und Darstellung braucht es ein Backend, etwa Prometheus (Metriken), Loki/OpenSearch (Logs), Tempo/Jaeger (Traces) und Grafana als Oberfläche.
Reifegrad der Signale beachten
Traces und Metrics sind in den meisten Sprach-SDKs stabil. Das Logs-Signal ist auf Spezifikationsebene stabil, die Umsetzung in einzelnen Sprach-SDKs aber unterschiedlich weit. Wer Logs über OTel führt, sollte den Stand des konkret genutzten SDK prüfen.
6. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Herstellerneutral: einmal instrumentieren, Backend frei wählen | Kein eigenes Backend; Speicher und Visualisierung separat nötig |
| Industriestandard (CNCF graduated), breite Sprachunterstützung | Logs-Signal je nach Sprach-SDK unterschiedlich reif |
| OTLP und W3C Trace Context als offene Standards | Collector erzeugt eigenen Betriebs- und Konfigurationsaufwand |
| Collector als zentrale, austauschbare Pipeline | Tiefe Telemetrie erfordert manuelle Instrumentierung |
| Zero-Code-Instrumentierung für schnellen Einstieg | Schnelle Release-Takte; Versionsstände veralten zügig |
Häufige Fragen zu OpenTelemetry
Nein, es ergänzt sie. OTel erzeugt und transportiert Telemetrie herstellerneutral; gespeichert und dargestellt wird sie weiterhin in Backends wie Prometheus (Metriken) und Grafana (Visualisierung). OTel kann sogar an Prometheus exportieren.
Nicht zwingend. Für viele Sprachen gibt es Zero-Code-Instrumentation, die ohne Änderung am Anwendungscode Telemetrie aus Bibliotheken und Runtime zieht. Tiefere, fachliche Einblicke (eigene Spans, Business-Attribute) erfordern allerdings manuelle Instrumentierung über die SDKs.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
OpenTelemetry im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.