OpenTelemetry (OTel) ist ein herstellerneutrales Open-Source-Framework zum Erzeugen, Sammeln und Exportieren von Telemetrie: Traces, Metriken und Logs. Es definiert das Datenmodell, das Übertragungsprotokoll (OTLP), die SDKs, die Anwendungen nutzen, und den Collector, der Daten empfängt und routet. Weil es kein eigenes Backend hat, kannst du dieselben Daten an Grafana, Prometheus, Jaeger oder einen kommerziellen Anbieter senden und später wechseln, ohne neu zu instrumentieren.

Fast alles in OpenTelemetry wird mit Text konfiguriert: einer YAML-Datei für den Collector, Umgebungsvariablen für SDKs und zunehmend auch einer deklarativen YAML-Datei für SDKs. Diese Reihe konzentriert sich darauf, damit dein Telemetrie-Setup wie der Rest deiner Infrastruktur geprüft, versioniert und reproduzierbar ist.

So funktioniert es

Anwendungen werden mit einem OpenTelemetry-SDK instrumentiert (oder einem Zero-Code-Agent, der eines einschleust). Das SDK erzeugt Spans, Metriken und Log-Records und exportiert sie über OTLP, meist an einen Collector. Der Collector empfängt Daten, verarbeitet sie (Batching, Anreichern, Filtern, Sampling) und exportiert sie an ein oder mehrere Backends.

App + SDK ──OTLP──▶ Collector (Receiver → Prozessoren → Exporter) ──▶ Backends

Kernkonzepte

• Signale — Traces, Metriken und Logs. Profile entstehen als viertes Signal.
• SDK und API — die API ist das, was Instrumentierung aufruft, und das SDK ist die Implementierung, die sampelt, bündelt und exportiert.
• OTLP — das OpenTelemetry-Protokoll, über gRPC (Port 4317) oder HTTP (Port 4318).
• Collector — ein eigenständiges Binary aus Receivern, Prozessoren, Exportern, Connectors und Extensions, verdrahtet in service.pipelines.
• Resource — Attribute, die das beschreiben, was Telemetrie erzeugt, etwa service.name und deployment.environment.name.
• Semantische Konventionen — standardisierte Attributnamen, damit Daten aus verschiedenen Sprachen und Bibliotheken gleich aussehen.
• Sampling — entscheiden, welche Traces behalten werden, im SDK (Head Sampling) oder im Collector (Tail Sampling).
• Instrumentierung — manueller Code, Bibliotheken oder Zero-Code-Agents, die Telemetrie erzeugen.

Warum Teams OpenTelemetry einsetzen

• Kein Lock-in. Wechsle Backends durch Bearbeiten der Collector-Konfiguration, nicht des Anwendungscodes.
• Eine Pipeline für alles. Derselbe Collector behandelt Traces, Metriken und Logs aus jeder Sprache.
• Kontrolle am Rand. Filtere, schwärze, sample und route Daten, bevor sie dein Netzwerk verlassen.
• Konsistente Benennung. Semantische Konventionen machen Dashboards und Alerts portabel.
• Konfiguration als Code. Collector-YAML und SDK-Umgebungsvariablen passen zu GitOps-Werkzeugen wie Flux und Argo CD.

Erste Schritte

Betreibe einen Collector mit einer kleinen Konfigurationsdatei, richte eine Anwendung mit ein paar OTEL_*-Umgebungsvariablen darauf und sieh dir die Daten im debug-Exporter des Collectors an. Die folgenden Anleitungen führen dich von dort zu Zero-Code-Instrumentierung, Sampling, Kubernetes und Produktionshärtung. Sie wurden gegen aktuelle Collector-Releases (die 0.16x-Reihe) und das stabile Schema der deklarativen Konfiguration geschrieben; prüfe die OpenTelemetry-Dokumentation für die Versionen, die du installierst, da Collector-Komponenten in ihrer Stabilität variieren.