← Zurück zum Glossar
webentwicklung

OpenTelemetry

Offener Standard zur Erfassung von Traces, Metriken und Logs aus verteilten Systemen — vendor-neutral und weit verbreitet.

Aktualisiert: 23. Februar 2026

Was ist OpenTelemetry?

OpenTelemetry (kurz: OTel) ist ein quelloffenes Framework zur Erfassung, Verarbeitung und dem Export von Telemetriedaten — also Traces, Metriken und Logs — aus verteilten Systemen. Es entstand 2019 aus der Zusammenführung von OpenCensus und OpenTracing unter dem Dach der Cloud Native Computing Foundation (CNCF) . Der entscheidende Vorteil: Einmal instrumentiert, können Daten an beliebige Backends wie Prometheus, Jaeger, Grafana oder kommerzielle Anbieter gesendet werden — ohne Code-Änderungen.

Für Entwickler und Betreiber von Web-Applikationen bedeutet OpenTelemetry konkret: Statt proprietärer SDKs eines einzelnen Monitoring-Anbieters verwendet man eine standardisierte API. Der Wechsel des Backends wird damit zur Konfigurationsfrage, nicht zur Refactoring-Aufgabe.

Kurzprofil OpenTelemetry

Kurzprofil

Wie funktioniert OpenTelemetry?

OpenTelemetry gliedert sich in drei Signaltypen: Traces (Anfrage-Pfade durch das System), Metriken (numerische Zeitreihendaten wie CPU-Auslastung oder Request-Latenz) und Logs (strukturierte Ereignisse). Alle drei werden durch eine einheitliche API und SDKs in verschiedenen Programmiersprachen (PHP, JavaScript, Python, Go, Java u.v.m.) erfasst.

Der typische Datenfluss sieht so aus:

Applikation
  → OTel SDK (instrumentiert Code automatisch oder manuell)
  → OTel Collector (Aggregation, Filterung, Routing)
  → Backend (Jaeger, Prometheus, Grafana Tempo, Datadog, ...)

Der OTel Collector ist dabei optional, aber empfohlen: Er entkoppelt die Applikation vom Backend und übernimmt Batching, Retry-Logik und Protokollkonvertierung. Für die Übertragung wird in der Regel OTLP verwendet.

Ein Trace besteht aus mehreren Spans: Jeder Span repräsentiert eine Operation (z.B. ein Datenbankquery, ein externer HTTP-Call), mit Startzeit, Dauer, Status und frei definierbaren Attributen. Spans sind über eine Trace-ID verknüpft, sodass eine vollständige Anfrage durch Microservices, Caches und Datenbanken nachvollziehbar wird.

OpenTelemetry in der Praxis

Für eine WordPress-Installation auf Docker/Kubernetes bedeutet OpenTelemetry: Jede PHP-Anfrage wird automatisch instrumentiert (über das opentelemetry-php Paket), Spans werden für MySQL-Queries, Redis-Zugriffe und externe HTTP-Calls erstellt, und die Daten landen im gewählten Backend.

Ein typisches Setup für Webprojekte:

# docker-compose Ausschnitt
otel-collector:
  image: otel/opentelemetry-collector-contrib
  volumes:
    - ./otel-config.yaml:/etc/otel/config.yaml
  ports:
    - "4317:4317"   # OTLP gRPC
    - "4318:4318"   # OTLP HTTP

In PHP wird das SDK über Composer eingebunden und per Auto-Instrumentation aktiviert — für gängige Frameworks wie WordPress, Laravel oder Symfony existieren fertige Instrumentation-Pakete, die ohne manuelle Span-Erstellung auskommen.

Auf einen Blick

Das Wichtigste

  • OpenTelemetry ist der De-facto-Standard für Observability in Cloud-nativen Systemen
  • Drei Signaltypen: Traces (Anfragepfade), Metriken (Zahlen), Logs (Ereignisse)
  • Vendor-neutral: ein SDK, beliebig viele Backends
  • Das Protokoll für den Transport heißt OTLP
  • Offizielle PHP-Unterstützung über opentelemetry-php

Was passiert wenn OpenTelemetry fehlt oder falsch konfiguriert ist?

Ohne Observability-Daten arbeitet man bei Produktionsproblemen blind. Fehlerhafte Konfiguration äußert sich häufig als hoher Memory-Verbrauch (wenn der Collector nicht erreichbar ist und Spans im Speicher gepuffert werden), oder als verpasste Traces (wenn Sampling-Raten falsch gesetzt sind und nur ein Bruchteil der Anfragen erfasst wird).

Ein häufiger Fehler ist das Exportieren direkt an ein Backend ohne Collector: Fällt das Backend kurz aus, blockiert die Applikation oder verliert Daten. Der Collector als Puffer verhindert das.

Bei WordPress-Setups: Wenn die OTLP-Endpoint-URL falsch konfiguriert ist, sendet das SDK Daten ins Leere — ohne Fehlermeldung in den Application-Logs, wenn der Export asynchron erfolgt. Immer mit OTEL_SDK_DISABLED=false und aktiviertem Debug-Exporter verifizieren.

Häufige Fragen

Was ist der Unterschied zwischen OpenTelemetry und Prometheus? Prometheus ist ein Monitoring-System mit eigenem Datenformat (Metriken-Pull-Modell). OpenTelemetry ist ein übergeordneter Standard, der Prometheus als Backend verwenden kann. OTel deckt zusätzlich Traces und Logs ab — Prometheus nur Metriken.

Muss ich für jede Sprache anderes SDK nutzen? Ja, aber alle SDKs implementieren dieselbe OpenTelemetry-Spezifikation. Die Konzepte (Tracer, Meter, Logger, Spans) sind identisch — nur die Syntax ist sprachspezifisch. Code für die Instrumentierung ist daher gut portierbar.

Ist OpenTelemetry für kleine WordPress-Seiten sinnvoll? Für einfache Seiten mit wenig Traffic ist der Aufwand meist zu hoch. Sinnvoll wird es ab containerisierten Multi-Service-Setups oder wenn Performance-Probleme schwer zu lokalisieren sind.

Verwandte Begriffe

Grafana · Jaeger · Prometheus

start call_