J’ai réussi à faire fonctionner OpenTelemetry, mais pourquoi est-ce si compliqué ?

• OpenTelemetry (OTel) est un framework et un ensemble d’outils d’observabilité
• Les outils existants incluent Prometheus (métriques), Logstash (logs) et OpenTracing (tracing distribué)
• OTel standardise trois types de signaux — métriques, logs et traces — et fournit OpenTelemetry Protocol (OTLP), OpenTelemetry Collector ainsi que des SDK pour de nombreux langages
  • Il coche toutes les cases des mots-clés à la mode : open source, indépendant des vendors, indépendant du langage, distribué, zero-code, etc.

Les problèmes d’OTel

• Les logs et les métriques sont similaires aux outils existants, ce qui permet une intégration facile. Il est possible de passer à OTel simplement en ajoutant de la configuration
• La difficulté réside dans l’implémentation du tracing
  • Context Propagation : nécessaire pour transmettre les informations d’une requête entre systèmes distribués
    • L’unité de requête est divisée en Trace et Span
    • Exemple : clic sur le bouton « Acheter » → Frontend → Backend → relations entre les services Payment/Shipping représentées sous forme de Span
  • Méthode de prise en charge par OTel :
    • Fournit plusieurs standards de Context Propagation (par ex. b3, W3C Trace Context)
  • OTel doit prendre en charge plusieurs standards
    • Lors d’une migration d’OpenTracing vers OTel, des conflits inattendus peuvent apparaître
    • Lightbend Telemetry prend en charge les logs et métriques OpenTelemetry, mais pas le tracing.

Problèmes de conflit entre API

Problème d’intégration entre Spring et Akka

• Spring : utilisé pour le bootstrap de l’application et la gestion de la configuration
• Akka : utilisé pour l’event sourcing, l’ordonnancement, le clustering, etc.
• Problème :
  • Avec OTel, les API de tracing de Spring et d’Akka n’interagissent pas entre elles
  • Elles ne peuvent pas partager le même Trace ID → résultats de tracing incorrects

Solution : OpenTracing Shim

• Outil permettant de convertir un Tracer OTel en Tracer OpenTracing
• Problème :
  • Lightbend Telemetry d’Akka n’arrive pas à s’aligner sur l’implémentation OpenTracing
  • Jaeger et OTel exigent des SpanContext différents, ce qui provoque des conflits

Processus de résolution

Intégration manuelle entre OTel et OpenTracing

• Conversion manuelle du contexte OTel en Jaeger SpanContext :
  • Insertion du contexte OTel dans une Java Map
  • Extraction de cette map vers le Jaeger SpanContext, puis configuration manuelle
• Exemple de code :

  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);  
  

• Résultat :
  • Intégration réussie des données de tracing entre Spring et Akka
  • Les traces sont correctement reliées à travers les frontières HTTP

Conclusion

Origine de la complexité

• Tentative d’intégrer deux bibliothèques de tracing différentes
• Les standards fournis par OpenTelemetry sont utiles, mais des conflits avec les outils existants restent possibles

La valeur d’OpenTelemetry

• OpenTelemetry joue un rôle important dans la standardisation de l’observabilité
• C’est un projet open source complexe mais puissant

Défis à venir

• Il faut vérifier si le Trace Context d’Akka est correctement propagé entre les threads
• Des tests supplémentaires et des retours sont indispensables pour améliorer le projet

[GN⁺]

Avis Hacker News

• En apprenant et en portant Otel, j’avais l’impression de revenir dans l’univers Java. Explorer le code donnait une impression d’EnterpriseFizzBuzz, et ce n’était pas du tout découvrable. En NodeJS, l’utilisation CPU était environ 4 fois supérieure à celle de StatsD, et cela a été réduit via une agrégation maison. OTEL est hostile aux langages qui utilisent un processus par cœur. Mieux vaut utiliser Prometheus.

• Otel peut sembler complexe à cause des SDK, agents et API proposés par divers fournisseurs d’observabilité. OpenTelemetry est devenu le standard, et bravo à Grafana pour l’avoir adopté. Les prix de Datadog sont devenus incontrôlables entre les entreprises de taille intermédiaire et les grandes entreprises. La documentation pourrait être meilleure, et les guides d’onboarding diffèrent selon les langages. J’ai créé un package pour démarrer rapidement avec OpenTelemetry sur une stack NodeJS/Typescript, ainsi qu’un exemple de stack Grafana.

• En développement local, je voulais le support des logs, des traces et des métriques, mais je ne voulais pas lancer plusieurs images Docker. L’équipe .NET a lancé .NET Aspire, qui permet de tout visualiser facilement dans une stack de développement local. Lors d’un déploiement sur k8s, il suffit de connecter le endpoint OTEL à l’agent DataDog pour que tout fonctionne. J’évite les bibliothèques de traçage et SDK propriétaires de DataDog et j’utilise OTEL.

• OpenTelemetry peut être complexe selon les besoins. Notre équipe l’utilise de façon simple, avec une instrumentation manuelle pour choisir soigneusement ce qu’on veut observer. Nous utilisons deux backends : un service tiers peu coûteux, et une installation Jaeger pour le développement local.

• En Python, il vaut mieux utiliser le client de Logfire avec Otel. Le client créé par l’équipe Pydantic est bien meilleur et plus simple que la bibliothèque officielle Otel.

• Beaucoup de frameworks web gèrent automatiquement la majeure partie de l’instrumentation. Avec opentelemetry-js et quelque chose comme Signoz en auto-hébergement, on peut obtenir beaucoup de données en moins d’une heure.

• J’ai lancé un projet open source exécutable avec une seule commande pour faciliter l’adoption d’OpenTelemetry.

• En Python, avec la stack standard, on peut tout tracer automatiquement avec seulement quelques imports. Otel est complexe parce qu’il a été conçu pour les entreprises qui vendent des logiciels compatibles Otel.

• OpenTelemetry a commencé par le traçage, mais pour les métriques et les logs, il vaut mieux s’en remettre à des solutions spécialisées. La tentative de tout mettre sous un même parapluie donne l’impression d’un problème d’« abstraction qui fuit ». Les bases de données SQL peuvent aussi tout faire à la fois, mais cela ne veut pas dire qu’elles devraient le faire.