OpenTelemetry hat viele Teile, und der Großteil der Verwirrung entsteht dadurch, sie zu verwechseln. Diese Anleitung trennt sie: was in deiner Anwendung läuft, was daneben läuft und wo jedes konfiguriert wird. Ist die Landkarte klar, besteht der Rest der Reihe meist darin, YAML auszufüllen.

Das Problem, das es löst

Vor OpenTelemetry lieferte jeder Monitoring-Anbieter seinen eigenen Agent und sein eigenes Datenformat. Den Anbieter zu wechseln bedeutete, jeden Service neu zu instrumentieren, und zwei Werkzeuge zu betreiben bedeutete, zwei Agents zu betreiben. OpenTelemetry trennt die beiden Belange: Instrumentierung erzeugt einmal Standarddaten, und eine Pipeline entscheidet, wohin sie gehen.

Die Teile

Teil	Was es ist	Wo es läuft
API	Die Schnittstellen, die Instrumentierungscode aufruft (einen Span starten, eine Metrik erfassen)	In deiner App
SDK	Die Implementierung hinter der API: Sampling, Batching, Exportieren	In deiner App
Instrumentierung	Code, der Telemetrie für Bibliotheken erzeugt (HTTP, Datenbanken)	In deiner App, über Bibliotheken oder einen Zero-Code-Agent
OTLP	Das Übertragungsprotokoll für Telemetrie, über gRPC oder HTTP	Zwischen Komponenten
Collector	Ein eigenständiger Service, der Telemetrie empfängt, verarbeitet und exportiert	Neben Apps, pro Knoten oder als zentrales Gateway
Semantische Konventionen	Standardnamen für Attribute, etwa http.request.method	Überall

Anwendungen können direkt an ein Backend exportieren, aber ein Collector dazwischen ist die übliche Empfehlung, weil er dir erlaubt, Verarbeitung und Ziele zu ändern, ohne Anwendungen neu zu deployen.

Drei Konfigurationsschichten

1. Das SDK der Anwendung, konfiguriert mit OTEL_*-Umgebungsvariablen oder zunehmend einer deklarativen YAML-Datei, auf die OTEL_CONFIG_FILE zeigt. Es steuert Service-Namen, Resource-Attribute, Sampler und wohin exportiert wird.
2. Der Collector, konfiguriert mit einer YAML-Datei. Er steuert, was empfangen wird, wie Daten transformiert werden und wohin sie gehen.
3. Der Plattform-Kleber: Docker-Compose-Dateien, Helm-Values oder Kubernetes-Ressourcen aus dem OpenTelemetry Operator, die den Collector deployen und Konfiguration in Anwendungen injizieren.

Alles in diesen Schichten ist Text, kann also in Git leben.

Datenfluss in einem Bild

┌────────────┐  OTLP   ┌─────────────────────────────┐        ┌───────────┐
│ App + SDK  │────────▶│ Collector                   │───────▶│ Traces    │
│ (Env-Vars  │ 4317/   │ Receiver → Prozessoren →    │───────▶│ Metriken  │
│  oder YAML)│ 4318    │ Exporter (config.yaml)      │───────▶│ Logs      │
└────────────┘         └─────────────────────────────┘        └───────────┘

Signale im Überblick

• Traces zeichnen den Weg einer Anfrage durch Services als Spans auf. Sie beantworten „wo ist die Zeit geblieben?“
• Metriken sind numerische Messungen über die Zeit, etwa Anfragezahlen und Latenz-Histogramme. Sie beantworten „wie entwickelt sich das System?“
• Logs sind Datensätze mit Zeitstempel. OpenTelemetry kann sie mit Traces korrelieren, sodass eine Logzeile auf den Span verweist, der sie erzeugt hat.

Jedes Signal hat seine eigene Pipeline im Collector und seinen eigenen Provider in einem SDK.

Stabilität: lies vor der Einführung

OpenTelemetry ist groß, und seine Teile reifen unterschiedlich schnell. Das OTLP-Protokoll und die APIs für Tracing und Metriken sind stabil. Collector-Komponenten tragen ihre eigenen Stabilitätsstufen, und viele Contrib-Komponenten sind noch Beta oder Alpha. Die deklarative SDK-Konfiguration erreichte 2026 ein stabiles Schema, aber SDK-Implementierungen holen unterschiedlich schnell auf, wobei Java und einige andere vorn liegen. Wenn du eine Komponente oder ein Feature wählst, prüfe seine Stabilität in der Dokumentation und pinne Versionen.

Ein vorgeschlagener Weg durch diese Reihe

1. Betreibe einen Collector und sende ihm Daten (Docker Compose).
2. Lerne das Konfigurationsmodell des Collectors.
3. Konfiguriere SDKs mit Umgebungsvariablen und, wo unterstützt, einer deklarativen Datei.
4. Füge einer App Zero-Code-Instrumentierung hinzu.
5. Mache den Collector produktionsreif: Batching, Speicherlimits, Retries, Sampling.
6. Deploye ihn auf Kubernetes mit Helm oder dem Operator.
7. Sammle Logs und Infrastruktur-Metriken, sende sicher an Backends und behebe Fehler.

Als Referenz siehe die OpenTelemetry-Dokumentation.