OpenTelemetry hat funktioniert – aber warum war es so kompliziert?

• OpenTelemetry (OTel) ist ein Observability-Framework und Toolset
• Zu den bestehenden Tools gehören Prometheus (Metriken), Logstash (Logs) und OpenTracing (verteiltes Tracing)
• OTel standardisiert die drei Signale Metriken, Logs und Traces und bietet dafür das OpenTelemetry Protocol (OTLP), den OpenTelemetry Collector sowie SDKs für verschiedene Sprachen
  • Es erfüllt alle Buzzwords: Open Source, herstellerunabhängig, sprachunabhängig, verteilt, Zero Code usw.

Die Probleme mit OTel

• Logs und Metriken ähneln bestehenden Tools und lassen sich daher leicht integrieren. Oft reicht es, nur Konfigurationen hinzuzufügen, um auf OTel umzustellen
• Schwierigkeiten bei der Implementierung von Tracing
  • Context Propagation: notwendig, um Request-Informationen zwischen verteilten Systemen weiterzugeben
    • Die Request-Einheit wird in Trace und Span unterteilt
    • Beispiel: Klick auf den Button „Kaufen“ → Frontend → Backend → Payment-/Shipping-Service; die Beziehungen dazwischen werden als Spans dargestellt
  • So unterstützt OTel das:
    • Es stellt verschiedene Standards für Context Propagation bereit (z. B. b3, W3C Trace Context)
  • OTel muss mehrere Standards unterstützen
    • Beim Wechsel von bestehendem OpenTracing zu OTel kam es zu unerwarteten Konflikten
    • Lightbend Telemetry unterstützt OpenTelemetry-Logs und -Metriken, aber kein Tracing

Konflikte zwischen APIs

Integrationsprobleme zwischen Spring und Akka

• Spring: für Application-Bootstrapping und Konfigurationsverwaltung
• Akka: für Event Sourcing, Scheduling, Clustering usw.
• Das Problem:
  • Bei der Nutzung von OTel interagieren die Tracing-APIs von Spring und Akka nicht miteinander
  • Sie können keine gemeinsame Trace ID verwenden → fehlerhafte Tracing-Ergebnisse

Lösung: OpenTracing Shim

• Ein Tool, das einen OTel Tracer in einen OpenTracing Tracer umwandelt
• Das Problem:
  • Lightbend Telemetry von Akka entspricht der OpenTracing-Implementierung nicht vollständig
  • Jaeger und OTel erwarten unterschiedliche SpanContexts, was zu Konflikten führt

Der Lösungsweg

Manuelle Integration von OTel und OpenTracing

• OTel Context manuell in einen Jaeger SpanContext umwandeln:
  • OTel Context in eine Java-Map einfügen
  • Die entsprechende Map in den Jaeger SpanContext extrahieren und manuell setzen
• Codebeispiel:

  var otelContext = new HashMap<>();  
  GlobalOpenTelemetry.get().getPropagators().getTextMapPropagator()  
      .inject(Context.current(), otelContext, (carrier, key, value) -> carrier.put(key, value));  
  var openTracingContext = new TextMapCodec(false).extract(new TextMapAdapter(otelContext));  
  GlobalExtendedTracer.get().local().activateContext(openTracingContext);  
  

• Ergebnis:
  • Erfolgreiche Zusammenführung der Tracing-Daten zwischen Spring und Akka
  • Traces werden über HTTP-Grenzen hinweg korrekt verbunden

Fazit

Woher die Komplexität kommt

• Der Versuch, zwei unterschiedliche Tracing-Bibliotheken zu integrieren
• Die von OpenTelemetry bereitgestellten Standards sind nützlich, können aber mit bestehenden Tools kollidieren

Der Wert von OpenTelemetry

• OpenTelemetry spielt eine wichtige Rolle bei der Standardisierung von Observability
• Ein komplexes, aber leistungsstarkes Open-Source-Projekt

Nächste Aufgaben

• Es muss geprüft werden, ob der Trace Context von Akka korrekt zwischen Threads weitergegeben wird
• Zusätzliche Tests und Feedback sind notwendig, um das Projekt weiter zu verbessern

[GN⁺]

Hacker-News-Kommentare

• Während ich Otel gelernt und portiert habe, fühlte es sich an, als wäre ich in die Java-Welt zurückgekehrt. Beim Durchstöbern des Codes wirkte es wie EnterpriseFizzBuzz, und es war überhaupt nicht auffindbar. In NodeJS lag die CPU-Auslastung etwa 4-mal höher als bei StatsD, was wir durch eigene Aggregation reduziert haben. OTEL ist feindlich gegenüber Sprachen, die einen Prozess pro Kern verwenden. Es ist besser, Prometheus zu nutzen.

• Otel kann sich wegen der von verschiedenen Observability-Anbietern bereitgestellten SDKs, Agenten und APIs komplex anfühlen. OpenTelemetry hat sich als Standard durchgesetzt, und es ist lobenswert, dass Grafana OpenTelemetry übernommen hat. Die Preise von Datadog sind zwischen mittelgroßen Unternehmen und Großunternehmen außer Kontrolle geraten. Die Dokumentation könnte besser sein, und die Onboarding-Dokumente unterscheiden sich je nach Programmiersprache. Ich habe ein Paket und einen Beispiel-Grafana-Stack erstellt, mit denen man mit einem NodeJS/Typescript-Stack schnell mit OpenTelemetry loslegen kann.

• In der lokalen Entwicklung wollte ich Unterstützung für Logs, Traces und Metriken, aber ich wollte nicht mehrere Docker-Images ausführen. Das .NET-Team hat .NET Aspire veröffentlicht, und damit lässt sich im lokalen Entwicklungs-Stack alles leicht visualisieren. Beim Deployment auf k8s verbindet man den OTEL-Endpunkt mit dem DataDog-Agenten, und dann funktioniert alles. Ich vermeide die proprietären Tracing-Bibliotheken und SDKs von DataDog und nutze OTEL.

• OpenTelemetry kann je nach Bedarf komplex sein. Unser Team nutzt es einfach und verwendet manuelle Instrumentierung, um sorgfältig auszuwählen, was beobachtet werden soll. Wir verwenden zwei Backends: eines ist ein günstiger Drittanbieter-Service, das andere eine Jaeger-Installation für die lokale Entwicklung.

• Wenn man Otel in Python verwendet, ist es besser, den Client von Logfire zu nutzen. Der vom Pydantic-Team entwickelte Client ist viel besser und einfacher als die offizielle Otel-Bibliothek.

• Viele Web-Frameworks übernehmen den Großteil der Instrumentierung automatisch. Mit opentelemetry-js und etwas wie Signoz im Self-Hosting kann man innerhalb einer Stunde viele Daten erhalten.

• Ich habe ein Open-Source-Projekt gestartet, das sich mit einem einzigen Befehl ausführen lässt, um die Einführung von OpenTelemetry zu erleichtern.

• Wenn man in Python den Standard-Stack verwendet, lässt sich mit nur ein paar Imports alles automatisch nachverfolgen. Otel ist komplex, weil es für Unternehmen entwickelt wurde, die Otel-kompatible Software verkaufen.

• OpenTelemetry begann mit Tracing, aber bei Metriken und Logs ist es besser, sie spezialisierten Lösungen zu überlassen. Der Versuch, alles unter einem Dach zu vereinen, fühlt sich wie ein Problem der „leaky abstraction“ an. SQL-Datenbanken können zwar auch alles gleichzeitig, aber das heißt nicht, dass sie es sollten.