← Zurück zum Glossar
webentwicklung

OTLP

OpenTelemetry Protocol — das standardisierte Übertragungsformat für Telemetriedaten (Traces, Metriken, Logs) zwischen OTel-Komponenten.

Aktualisiert: 23. Februar 2026

Was ist OTLP?

OTLP (OpenTelemetry Protocol) ist das Übertragungsprotokoll von OpenTelemetry — das Format und der Transport, über den Telemetriedaten (Traces, Metriken, Logs) von der Applikation an den Collector oder direkt an ein Backend gesendet werden. OTLP definiert das Datenformat (Protocol Buffers / protobuf) und zwei Transportvarianten: gRPC und HTTP/Protobuf bzw. HTTP/JSON.

OTLP ist der Ersatz für eine Vielzahl proprietärer Protokolle (Jaeger-Thrift, Zipkin-Format, StatsD, Prometheus Remote Write) durch eine einheitliche, versionierte Spezifikation. Wer OTLP implementiert, kann Telemetriedaten an jedes kompatible Backend senden — ohne anbieter-spezifischen Code.

Kurzprofil OTLP

Kurzprofil

  • Typ: Telemetrie-Übertragungsprotokoll
  • Organisation: OpenTelemetry / CNCF
  • Transporte: gRPC (Standard), HTTP/Protobuf, HTTP/JSON
  • Standard-Ports: 4317 (gRPC), 4318 (HTTP)
  • Datenformat: Protocol Buffers (protobuf)
  • Relevanz für WordPress/Web: Mittel-hoch (bei containerisierten Setups)

Wie funktioniert OTLP?

OTLP definiert drei Services, einen je Signaltyp:

  • TraceService — für Distributed Traces
  • MetricsService — für Metriken
  • LogsService — für Logs

Jeder Service hat einen Export-Endpunkt, der einen Stream von Daten annimmt und mit einer Response (Success, Partial Success oder Failure) antwortet. Das Datenmodell ist in der OTLP-Spezifikation und den zugehörigen Proto-Definitionen festgelegt.

gRPC vs. HTTP:

  • gRPC/OTLP (Port 4317): Bietet bidirektionales Streaming, ist etwas effizienter für hohe Durchsätze. Standard in Server-zu-Server-Kommunikation.
  • HTTP/OTLP (Port 4318): Einfacher zu debuggen (kein gRPC-Tool nötig), funktioniert durch Firewalls und Load Balancer ohne spezielle gRPC-Unterstützung. Standard für Browser-Telemetrie.

Die Endpunkt-Pfade sind standardisiert:

POST /v1/traces     (OTLP/HTTP)
POST /v1/metrics
POST /v1/logs

OTLP in der Praxis

Für eine WordPress/PHP-Applikation sieht die OTLP-Konfiguration typischerweise so aus:

// Umgebungsvariablen für OpenTelemetry PHP SDK
OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4318
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
OTEL_SERVICE_NAME=wordpress-production
OTEL_TRACES_SAMPLER=parentbased_traceidratio
OTEL_TRACES_SAMPLER_ARG=0.1  // 10% Sampling

Der OTel Collector empfängt OTLP und kann an mehrere Backends weiterleiten:

# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
  otlp/tempo:
    endpoint: tempo:4317
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp/tempo]
    metrics:
      receivers: [otlp]
      exporters: [prometheus]
Auf einen Blick

Das Wichtigste

  • OTLP ist das Übertragungsprotokoll von OpenTelemetry (kein Monitoring-System selbst)
  • Zwei Transporte: gRPC (Port 4317) und HTTP (Port 4318)
  • Einheitliches Format für Traces, Metriken und Logs
  • PHP SDK nutzt standardmäßig HTTP/Protobuf (einfacher als gRPC)
  • Der OTel Collector als Middleware ist der empfohlene Empfänger

Was passiert wenn OTLP falsch konfiguriert ist?

Falscher Port oder Protocol-Mismatch ist der häufigste Fehler: gRPC-Client gegen HTTP-Endpoint oder umgekehrt führt zu sofortigen Connection-Fehlern. Das PHP SDK loggt diese Fehler nicht automatisch in die Standard-Error-Logs — man sieht nichts in /var/log/nginx/error.log, aber Telemetriedaten kommen nicht an.

Bei Docker-Netzwerken: Der Collector muss im selben Netzwerk wie die Applikation sein, oder der Hostname muss korrekt aufgelöst werden. otel-collector:4318 funktioniert nur wenn beide Container im selben Docker-Netzwerk liegen.

Häufige Fragen

Was ist der Unterschied zwischen OTLP und dem Prometheus-Format? Prometheus verwendet ein Pull-Modell: Der Prometheus-Server scrapt Metriken von einem Endpunkt. OTLP ist Push-basiert: Die Applikation sendet aktiv Daten. Beides hat Vor- und Nachteile — Pull ist einfacher für Service-Discovery, Push ist besser für kurzlebige Prozesse und Traces.

Kann ich OTLP direkt an Grafana Cloud senden? Ja. Grafana Cloud bietet OTLP-kompatible Endpunkte für Traces (Tempo), Metriken (Mimir) und Logs (Loki). Die Authentifizierung erfolgt über OTEL_EXPORTER_OTLP_HEADERS mit einem API-Token.

Muss ich immer einen OTel Collector verwenden? Nein. Applikationen können OTLP direkt an Backends senden, die OTLP unterstützen (Grafana Cloud, Honeycomb, Lightstep). Der Collector ist empfohlen für Produktion, weil er Batching, Retry und Routing übernimmt — aber für Entwicklung und kleine Setups kann man ihn weglassen.

Verwandte Begriffe

Jaeger · Prometheus

start call_