OTLP (OpenTelemetry Protocol) ist das herstellerneutrale Protokoll, mit dem OpenTelemetry Telemetriedaten zwischen SDKs, Collectors und Backends überträgt. Es definiert Protobuf-Nachrichten für Traces, Metriken und Logs und transportiert sie per gRPC (Standardport 4317) oder HTTP (Standardport 4318), mit klar festgelegten Regeln für Retries, Kompression und Antworten.
Was ist OTLP?
OTLP, das OpenTelemetry Protocol, ist das native Übertragungsprotokoll von OpenTelemetry. Es legt fest, wie Telemetriedaten zwischen dem SDK einer Anwendung, einem OpenTelemetry Collector und einem Observability-Backend kodiert, transportiert und bestätigt werden. Da alle OpenTelemetry-SDKs und der Collector OTLP sprechen, ist es zur gemeinsamen Sprache für Traces, Metriken und Logs geworden. Genau das erlaubt es, Backends zu wechseln oder zu kombinieren, ohne den Code neu zu instrumentieren.
Die Signale Traces, Metriken und Logs sind in der Spezifikation stabil. Ein Signal für Profile wird in derselben Protokollfamilie entwickelt, damit Continuous-Profiling-Daten künftig dieselbe Pipeline nutzen können.
Vor OTLP nutzten Tracing-Systeme wie Jaeger und Zipkin sowie die verschiedenen Metrik-Agents jeweils eigene Formate. Der Collector kann viele dieser älteren Formate weiterhin empfangen und übersetzen, doch OTLP ist das Format, in dem alle Signale zusammenlaufen. Für neue Instrumentierung gibt es daher kaum einen Grund, ein anderes Protokoll zu wählen.
Transporte, Ports und Endpunkte
OTLP definiert zwei Transportwege. Beide nutzen dasselbe Protobuf-Datenmodell aus dem Repository opentelemetry-proto.
| Aspekt | OTLP/gRPC | OTLP/HTTP |
|---|---|---|
| Standardport | 4317 | 4318 |
| Encoding | Binäres Protobuf | Binäres Protobuf oder JSON (Protobuf-JSON-Mapping) |
| Pfade | gRPC-Services je Signal (TraceService, MetricsService, LogsService) | /v1/traces, /v1/metrics, /v1/logs |
| Typischer Einsatz | Verkehr vom Service zum Collector innerhalb eines Clusters | Browser, Serverless, Proxys und Firewalls, die nur HTTP zulassen |
Beide Transporte unterstützen gzip-Kompression. Das Protokoll des Exporters wählen Sie meist über die Umgebungsvariable OTEL_EXPORTER_OTLP_PROTOCOL mit den Werten grpc, http/protobuf und http/json. Die Standardwerte unterscheiden sich je nach Sprach-SDK, setzen Sie die Variable daher explizit.
So läuft ein OTLP-Export ab
- Das SDK sammelt Spans, Metrik-Datenpunkte oder Log-Einträge in Batches und gruppiert sie nach Resource (zum Beispiel
service.name,k8s.pod.name) und Instrumentation Scope. - Der Exporter sendet einen Export-Request an den konfigurierten Endpunkt.
- Der Empfänger antwortet mit Erfolg, mit einem Partial Success, der meldet, wie viele Einträge abgelehnt wurden und warum, oder mit einem Fehler.
- Bei wiederholbaren Fehlern wie gRPC
UNAVAILABLEoder HTTP 429, 502, 503 und 504 wiederholt der Client den Versand mit exponentiellem Backoff und beachtet Drosselungshinweise des Servers.
Konfigurationsbeispiel
Ein Beispiel zur Veranschaulichung: Anwendungen exportieren per gRPC an einen lokalen Collector, der die Daten per HTTP an ein Backend weiterleitet.
# Umgebung der Anwendung
OTEL_SERVICE_NAME=checkout
OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317
OTEL_EXPORTER_OTLP_PROTOCOL=grpc
# Collector (Auszug)
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
exporters:
otlphttp:
endpoint: https://otlp.example.com
compression: gzipBei OTLP/HTTP hängt das SDK /v1/traces und die übrigen Signalpfade an den Basis-Endpunkt an. Verwenden Sie signalspezifische Variablen wie OTEL_EXPORTER_OTLP_TRACES_ENDPOINT, müssen Sie die vollständige URL inklusive Pfad angeben.
Warum OTLP wichtig ist
- Kein Lock-in: Dieselbe Instrumentierung sendet an jedes OTLP-fähige Backend oder über einen Collector an mehrere gleichzeitig.
- Eine Pipeline für alle Signale: Traces, Metriken und Logs teilen Resource-Attribute, wodurch Trace-Kontext und Service-Identität konsistent bleiben.
- Effizienter Transport: Protobuf mit Kompression ist kompakt, Batching hält die Zahl der Requests niedrig.
- Klare Semantik: Partial Success und Retry-Regeln machen Datenverluste sichtbar, statt sie zu verschweigen.
OTLP zuverlässig betreiben
In Produktion verdient OTLP-Verkehr dieselbe Sorgfalt wie jeder andere kritische Datenpfad. Verschlüsseln Sie ihn per TLS und authentifizieren Sie Exporter, zum Beispiel mit einem API-Token im Header, gesetzt über OTEL_EXPORTER_OTLP_HEADERS. Dimensionieren Sie Batches so, dass ein einzelner Request deutlich unter der maximalen Nachrichtengröße des Empfängers bleibt; gRPC-Server lehnen Nachrichten oberhalb weniger Megabyte häufig ab. Geben Sie dem Collector eine Sending Queue und, wo Datenverlust bei einem Neustart nicht akzeptabel ist, eine persistente Queue auf der Festplatte. Überwachen Sie schließlich die Pipeline selbst: Der Collector stellt eigene Metriken zu angenommenen, abgelehnten und fehlgeschlagenen Einträgen bereit. Eine steigende Zahl abgelehnter Einträge ist oft das erste Anzeichen für Gegendruck aus dem Backend oder für einen falsch konfigurierten Exporter.
Typische Fehler
- gRPC-Verkehr an Port 4318 oder HTTP-Verkehr an Port 4317 senden; die Fehlermeldungen helfen dabei oft wenig.
- Den Pfad
/v1/tracesvergessen, wenn ein signalspezifischer HTTP-Endpunkt gesetzt wird. - Aus Tausenden Pods direkt an ein entferntes Backend exportieren, statt einen Collector für Batching, Retries und Sampling einzusetzen.
- Partial-Success-Antworten ignorieren, wodurch abgelehnte Daten unbemerkt verloren gehen.
- TLS uneinheitlich terminieren, sodass manche Exporter
http://und anderehttps://gegen dasselbe Gateway verwenden.
Wie Obseria unterstützt
Obseria nimmt OTLP per gRPC und HTTP nativ entgegen. Bestehende OpenTelemetry-SDKs und Collectors senden Daten also ohne proprietäre Agents; der erste Trace kommt in der Regel wenige Minuten nach der Umstellung des Exporters an. Per OTLP können Sie Ihre Daten jederzeit wieder exportieren und bleiben bei der Werkzeugwahl frei. Mehr dazu auf der OpenTelemetry-Produktseite und in unserem Leitfaden zum Collector-Betrieb in Produktion.
