OpenTelemetry hat den Observability-Krieg gewonnen — was nun?

Das Lock-In-Problem ist gelöst

Für den Großteil der 2010er Jahre bedeutete die Wahl eines Observability-Anbieters, sich an dessen Instrumentierungsbibliothek zu binden. Datadog Agents, New Relic SDKs, Honeycombs proprietäre Beelines – jede dieser Lösungen hat Ihren Anwendungscode an ein bestimmtes Backend gefesselt. Ein Wechsel des Anbieters bedeutete, jeden Service neu zu instrumentieren. Diese Ära ist vorbei.

OpenTelemetry ist jetzt der De-facto-Standard für Distributed Tracing, Metrics und Logs. AWS, GCP, Azure, Datadog, Honeycomb, Grafana, New Relic, Dynatrace und jede größere Observability-Plattform unterstützen es nativ. Sie instrumentieren einmal. Sie leiten überall hin.

Was OpenTelemetry eigentlich ist

OpenTelemetry ist ein CNCF-Projekt – 2021 in den Graduiertenstatus erhoben – entstanden aus der Fusion zweier konkurrierender Standards: OpenCensus (Google) und OpenTracing (CNCF). Diese Fusion ist wichtig, weil sie die Fragmentierung beendet hat. Vor OpenTelemetry musste man sich für eine Seite entscheiden; jetzt gibt es nur einen Standard.

Das Projekt definiert drei Observability-Signale:

• Traces: Verteilte Request-Flows über Service-Grenzen hinweg, dargestellt als Baum von Spans mit Zeitangaben und Attributen.
• Metrics: Aggregierte numerische Messungen – Counters, Gauges, Histogramme – für Dashboards und Alarmierung.
• Logs: Strukturierte Ereignisaufzeichnungen, die über einen gemeinsamen Kontext (Trace-IDs, Span-IDs) mit Traces und Metrics korreliert werden können.

Die Architektur besteht aus zwei Hauptkomponenten: dem SDK (in Ihre Anwendung eingebettet) und dem Collector (einem eigenständigen Binary, das Telemetrie empfängt, verarbeitet und exportiert). Das Verständnis der Trennung zwischen diesen beiden ist die entscheidende Erkenntnis, die den meisten Teams entgeht.

Die Spezifikation vs. das SDK: Warum die Trennung wichtig ist

OpenTelemetry definiert eine API-Spezifikation getrennt von der SDK-Implementierung. Das ist bewusst so gewählt. Bibliotheksautoren können ihren Code gegen die API instrumentieren, ohne eine harte Abhängigkeit von einem bestimmten SDK einzugehen. Wenn Ihre Anwendung ohne konfiguriertes SDK läuft, werden diese API-Aufrufe zu No-ops. Null Overhead.

Wenn Sie ein SDK konfigurieren, verbindet es sich mit der API und beginnt mit dem Export. Das SDK übernimmt Batching, Retry-Logik, Sampling und Context Propagation. Die Spezifikation definiert den Vertrag; das SDK liefert die Implementierung. Diese Architektur ist der Grund, warum OpenTelemetry eine Null-Overhead-Instrumentierung für uninstrumentierte Deployments beanspruchen kann – ein Anspruch, der für Bibliotheksautoren, die an eine breite Nutzerbasis ausliefern, wichtig ist.

Die praktische Implikation: Instrumentieren Sie Ihre Bibliotheken gegen die OTel API. Instrumentieren Sie Ihre Anwendungen gegen das SDK. Lassen Sie niemals zu, dass eine Bibliothek eine harte SDK-Abhängigkeit eingeht.

Auto-Instrumentierung vs. Manuelle Spans

OpenTelemetry bietet sprachspezifische Auto-Instrumentierung, die gängige Frameworks und Bibliotheken ohne Code-Änderungen patcht:

• Java: Ein Java-Agent (-javaagent:opentelemetry-javaagent.jar), der Spring, Tomcat, gRPC, JDBC und Dutzende andere Bibliotheken per Bytecode-Manipulation beim Start instrumentiert.
• Python: opentelemetry-instrument python app.py – instrumentiert Django, Flask, FastAPI, SQLAlchemy, Redis-Clients und viele andere automatisch.
• Node.js: Binden Sie das Paket @opentelemetry/auto-instrumentations-node ein, und es hakt sich über Module-Patching in Express, HTTP, gRPC, MySQL, Postgres und andere ein.

Auto-Instrumentierung verschafft Ihnen sofort Sichtbarkeit auf Infrastrukturebene. Sie sehen HTTP-Request-Dauern, Datenbank-Query-Latenzen, externe API-Aufrufe – all die mechanische Verkabelung – ohne Anwendungscode zu berühren.

Aber die Auto-Instrumentierung weiß nicht, was Ihr Code bedeutet. Sie kann Ihnen nicht sagen, dass der Checkout-Service langsam ist, weil eine bestimmte Promo-Code-Validierungsregel greift. Für Sichtbarkeit auf Geschäftslogik-Ebene benötigen Sie manuelle Spans:

• Umschließen Sie jeden Vorgang, der fehlschlagen oder latenzempfindlich sein kann, mit einem benutzerdefinierten Span.
• Fügen Sie semantische Attribute hinzu: User-ID, Order-ID, Experiment-Variante, Feature-Flag-Werte.
• Zeichnen Sie Ausnahmen explizit mit span.recordException(err) und span.setStatus({code: ERROR}) auf.

Der richtige Ansatz: Nutzen Sie Auto-Instrumentierung als Basis und fügen Sie an jedem für Ihr Geschäft wichtigen Entscheidungspunkt manuelle Spans hinzu. Beginnen Sie mit Auto, erweitern Sie schrittweise um manuelle Spans, während Sie lernen, welche Fragen Sie nicht beantworten können.

Der Collector ist der architektonische Dreh- und Angelpunkt

Die meisten Teams beginnen damit, Telemetrie direkt vom Anwendungs-SDK an ein Backend zu senden. Das funktioniert, gibt aber die wertvollste Funktion der OTel-Architektur auf: die Collector-Pipeline.

Der OTel Collector ist ein vendor-neutraler Proxy, der zwischen Ihren Anwendungen und Ihren Backends sitzt. Konfigurieren Sie ihn mit Receivern (OTLP, Jaeger, Prometheus, Zipkin), Processors (Sampling, Attribut-Manipulation, PII-Scrubbing) und Exporters (Datadog, Honeycomb, Tempo, CloudWatch – jede Kombination).

Warum das in der Praxis wichtig ist:

• Fan-out: Senden Sie Traces gleichzeitig an Honeycomb zur Exploration UND an Grafana Tempo zur Langzeitspeicherung. Keine Anwendungsänderungen erforderlich.
• PII-Scrubbing: Entfernen oder hashen Sie sensible Attribute (E-Mail-Adressen, IP-Adressen, Session-Tokens), bevor sie Ihr Netzwerk verlassen – bevor Daten einen Vendor erreichen.
• Sampling-Entscheidungen: Wenden Sie Tail-based Sampling auf Collector-Ebene an, behalten Sie Fehler und langsame Traces, verwerfen Sie gesunde schnelle Traces.
• Backend-Migration: Wechseln Sie von Datadog zu Grafana, indem Sie eine Collector-Konfigurationsdatei ändern. Ihre Anwendungsinstrumentierung bleibt unberührt.

Deployen Sie den Collector als Sidecar in Kubernetes oder als DaemonSet. Für Umgebungen mit hohem Traffic setzen Sie eine abgestufte Architektur ein: Sidecar-Collectors pro Pod, die an Gateway-Collectors weiterleiten, die Tail Sampling über die gesamte Request-Population hinweg durchführen.

Sampling-Strategien: Head-based vs. Tail-based

Jeden Request in voller Detailtreue zu tracen, ist teuer. Bei 10.000 Requests pro Sekunde kostet das Speichern jedes Traces bares Geld. Sampling ist im großen Maßstab keine Option – aber die Sampling-Strategie bestimmt, was Sie tatsächlich debuggen können.

Head-based Sampling trifft die Keep/Drop-Entscheidung zu Beginn eines Requests, bevor nachgelagerte Spans erstellt werden. Es ist einfach zu implementieren und hat minimalen Overhead. Das Problem: Sie können nicht basierend auf Ergebnissen sampeln, die Sie noch nicht kennen. Sie könnten genau den einen Request verwerfen, der fehlgeschlagen ist. Bei 1 % Head Sampling werden Sie regelmäßig keinen Trace für Ihre interessantesten Bugs haben.

Tail-based Sampling puffert alle Spans eines Traces und trifft die Entscheidung erst, nachdem der gesamte Trace abgeschlossen ist. Damit können Sie:

• 100 % der Traces behalten, die einen Fehler-Span enthalten.
• 100 % der Traces behalten, die einen Latenzschwellenwert überschreiten (z. B. P99 > 2 Sekunden).
• Einen konfigurierbaren Prozentsatz gesunder, schneller Traces behalten (z. B. 1 % Basislinie).

Der tailsampling Processor des OTel Collectors implementiert dies. Konfigurieren Sie Policies in YAML: kombinieren Sie Error-Status-Policies mit Latenz-Policies und einer probabilistischen Basislinie. Das Ergebnis ist ein Trace-Korpus, der überproportional aus den interessanten Fällen besteht, die Sie tatsächlich debuggen möchten.

Der operative Preis: Tail-based Sampling erfordert das Puffern von in-flight Spans im Collector-Speicher. Für sinnvolle Entscheidungen müssen alle Spans eines bestimmten Traces dieselbe Collector-Instanz erreichen – typischerweise durch trace-ID-basiertes Load-Balancing vor einem Collector-Pool. Das ist mehr Infrastruktur zu betreiben, aber die Verbesserung der Debugbarkeit ist nicht marginal. Es ist der Unterschied zwischen dem Sehen jedes Fehlers und dem Sehen von keinem.

Der aktuelle Stand der drei Signale

Die Signale von OpenTelemetry sind unterschiedlich schnell gereift:

• Traces: GA und stabil seit 2021. Das reifste Signal. Die Semantic Conventions für HTTP, gRPC, Datenbanken, Messaging-Systeme sind etabliert und stabil. Nutzen Sie dies zuerst.
• Metrics: GA und stabil seit 2022. Das OTLP-Metrics-Protokoll ist produktionsreif. Semantic Conventions decken HTTP-Server- und Client-Metrics, Runtime-Metrics (JVM, Python-Runtime) und System-Metrics ab.
• Logs: Stabil seit 2023. Das Log-Datenmodell und das OTLP-Logs-Protokoll ermöglichen es strukturierten Logs, Trace-Kontext (Trace-ID, Span-ID) zu tragen und so die Korrelation zwischen Logs und Traces in Backends, die dies unterstützen, zu ermöglichen. Grafana Loki + Tempo-Korrelation ist heute die ausgereifteste Implementierung.

Die Semantic Conventions sind das, was die signalübergreifende Korrelation tatsächlich zum Funktionieren bringt. Wenn Ihr HTTP-Span und Ihre HTTP-Metric dieselben Attributnamen verwenden (http.request.method, http.response.status_code, server.address), können Backends sie verbinden. Halten Sie sich an die veröffentlichten Semantic Conventions – erfinden Sie keine eigenen Attributnamen für Standardoperationen.

Vendor-Landschaft im Jahr 2026

Da die Instrumentierung jetzt vendor-neutral ist, dreht sich die Wahl des Backends um das Query-Modell, die Kosten und die betrieblichen Präferenzen:

• Honeycomb: Das meinungsstärkste und wohl beste Produkt für Trace-Exploration. BubbleUp für automatische Korrelationserkennung, Unterstützung für hochkardinale Spalten und ein Query-Modell, das auf beliebig breite Events aufbaut. Am besten für Teams, die anspruchsvolle Trace-Analysen durchführen möchten und bereit sind, für ein verwaltetes Produkt zu zahlen.
• Grafana-Stack (LGTM): Loki (Logs) + Grafana (Dashboards) + Tempo (Traces) + Mimir (Metrics). Vollständig Open Source, selbst hostbar oder verwaltet über Grafana Cloud verfügbar. Der LGTM-Stack ist die richtige Wahl für Teams, die ihre Infrastruktur selbst betreiben und Vendor-Lock-in vollständig vermeiden möchten. Die Trace-to-Logs- und Trace-to-Metrics-Korrelationen von Tempo funktionieren gut, wenn alles OTel Semantic Conventions verwendet.
• Datadog: Hervorragende OTel-Ingestion-Unterstützung über den Datadog-Agent (der OTLP spricht). Am besten für Teams, die bereits Datadog für APM und Infrastruktur-Monitoring nutzen und die OTel-Instrumentierung standardisieren möchten, während sie die Datadog-Oberfläche und Alarmierung beibehalten. Die Kosten skalieren stark mit dem Datenvolumen.
• AWS CloudWatch: The AWS Distro for OpenTelemetry (ADOT) bietet AWS-verwaltete OTel-Collectors und tiefe Integration mit CloudWatch, X-Ray und Amazon Managed Grafana. Praktische Wahl für AWS-first-Teams, die die betriebliche Angriffsfläche minimieren möchten. Die Trace-Visualisierung von X-Ray ist funktional, aber nicht so ausdrucksstark wie Honeycomb oder Tempo.

Was immer noch schwierig ist

OpenTelemetry hat nicht alles gelöst. Seien Sie ehrlich, was noch rau ist:

• Profiling-Signal: Die Profiling-Spezifikation (kontinuierliches CPU- und Memory-Profiling korreliert mit Traces) befindet sich in der Entwicklung, ist aber Mitte 2026 noch nicht stabil. Rechnen Sie mit GA im Jahr 2026 oder 2027. Bis dahin bleibt Profiling vendor-spezifisch.
• Korrelation von Geschäftsmetriken: Die Verbindung einer langsamen Datenbankabfrage mit den Umsatzauswirkungen erfordert die Verknüpfung von Observability-Daten mit Geschäftsereignisdaten. OpenTelemetry definiert nicht, wie dies zu tun ist. Sie müssen Ihren Spans Geschäftsattribute hinzufügen (Bestellwert, Nutzerstufe, umsatzgenerierender Pfad) und die Analyse selbst in Ihrem Backend aufbauen.
• Komplexität der Collector-Konfiguration: Eine produktionsreife OTel-Collector-Konfiguration mit Tail Sampling, mehreren Exporters, PII-Scrubbing und Attributtransformationen kann Hunderte von Zeilen YAML umfassen. Der Collector hat ein umfangreiches Pipeline-Modell, aber die Lernkurve für komplexe Konfigurationen ist real. Verwenden Sie den OTel Collector Builder und testen Sie Konfigurationen lokal mit dem file Exporter, bevor Sie deployen.

Erste Schritte: Einen Service in 5 Schritten instrumentieren

Für einen Node.js-Service (gleiches Muster gilt für Python mit entsprechenden Paketen):

• Schritt 1 – Pakete installieren: npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node @opentelemetry/exporter-otlp-http
• Schritt 2 – Eine Instrumentierungsdatei erstellen (tracing.js): Initialisieren Sie das NodeSDK mit Ihrem Service-Namen, dem Auto-Instrumentations-Plugin und einem OTLP-HTTP-Exporter, der auf Ihren Collector-Endpunkt oder direkt auf die OTLP-Ingest-URL eines Vendors zeigt.
• Schritt 3 – Starten Sie das SDK vor Ihrer App: Rufen Sie in Ihrem Einstiegspunkt sdk.start() auf, bevor Sie andere Module laden. Verwenden Sie für Node.js --require ./tracing.js in Ihrem Startbefehl.
• Schritt 4 – Fügen Sie manuelle Spans für Geschäftslogik hinzu: Umschließen Sie Checkout, Zahlungsabwicklung, Empfehlungsabfragen – alles mit geschäftlicher Bedeutung – in benutzerdefinierten Spans. Fügen Sie Attribute für Order-ID, Nutzersegment und Experiment-Flags hinzu.
• Schritt 5 – Deployen Sie einen Collector-Sidecar: Betreiben Sie den OTel Collector neben Ihrem Service, konfiguriert zum Empfang von OTLP auf localhost:4318 und zum Export an Ihr gewähltes Backend. Dies entkoppelt die Backend-Konfiguration vom Anwendungsdeployment.

Handlungsorientierter Entscheidungsrahmen

So treffen Sie die wichtigsten Entscheidungen, ohne zu viel nachzudenken:

• Signal-Priorität: Implementieren Sie zuerst Traces, dann Metrics, dann Logs. Traces geben Ihnen den größten Debugging-Hebel pro Einheit Instrumentierungsaufwand. Logs sind wertvoll, aber Sie haben sie wahrscheinlich bereits – konzentrieren Sie sich darauf, sie über Trace-Kontext-Injektion mit Traces zu verbinden.
• Backend-Auswahl: Wenn Sie selbst hosten, verwenden Sie den LGTM-Grafana-Stack. Wenn Sie ein verwaltetes Produkt mit exzellenter UX für Trace-Analyse wünschen, nutzen Sie Honeycomb. Wenn Sie bereits Datadog für Infrastruktur-Monitoring verwenden, standardisieren Sie auf OTel-Instrumentierung und behalten Datadog als Backend. Optimieren Sie die Backend-Wahl nicht zu früh – der Sinn von OTel ist, dass Sie Ihre Meinung ändern können.
• Collector von Tag eins an: Selbst wenn Sie heute nur ein Backend haben, deployen Sie den Collector. Die Kosten sind minimal; der Flexibilitätsgewinn, wenn Sie ein zweites Backend hinzufügen oder den Vendor wechseln müssen, ist erheblich.
• Sampling-Richtlinie: Beginnen Sie mit Head-based Sampling bei 10–20 %, wenn Sie die Kosten sofort kontrollieren müssen. Planen Sie, zu Tail-based Sampling zu migrieren, sobald Sie einen Collector-Pool haben – die Verbesserung der Fehlersichtbarkeit ist die betriebliche Komplexität wert.
• Semantic Conventions: Setzen Sie sie durch. Fügen Sie einen Lint-Schritt oder CI-Check hinzu, der Ihre benutzerdefinierten Span-Attributnamen gegen das OTel Semantic Conventions Registry validiert. Konsistenz jetzt bedeutet signalübergreifende Korrelation später, und es bedeutet, dass jedes neue Backend, das Sie einführen, Ihre Daten ohne Transformation versteht.

Die Observability-Vendor-Kriege sind vorbei. Das Instrumentierungsproblem ist gelöst. Was bleibt, ist die operative Disziplin, es korrekt zu deployen, Ihre Pipeline für Kosten und Detailtreue zu konfigurieren und die organisatorischen Gewohnheiten rund um trace-getriebenes Debugging aufzubauen. Diese Gewohnheiten – bei Langsamkeit zuerst zu Traces zu gehen, Deployments als Trace-Attribute zu annotieren, Runbooks zu schreiben, die auf bestimmte Span-Attribute verweisen – sind das, was Teams, die Wert aus Observability ziehen, von Teams unterscheidet, die nur Dashboards haben.