Tracing avec OpenTelemetry
Retour d’expérience sur le tracing, en utilisant OpenTelemetry avec la solution Jaeger.
Contexte
Cet article est un retour d’expérience sur un POC que j’ai effectué sur le tracing, troisième pilier de l’Observabilité, ainsi que sur les données de télémétries. Le but étant de montrer comment les données de télémétries permettent d’analyser plus facilement les requêtes dans une application microservices.
En effet, c’est suite à une conférence de Vincent Behar au Devoxx 2022, que je me suis intéressé par la suite à OpenTelemetry, et au tracing en général.
En première partie de cet article, je souhaitais partager les notions que j’ai pu apprendre tout au long de ce POC, sur OpenTelemetry, et le tracing en général.
La deuxième partie sera un retour d’expérience sur l’installation de Jaeger en local et sur un cluster Kubernetes, ainsi que des outils que j’ai utilisés pour déployer et tester cette solution.
Piliers de l’observabilité
Tout d’abord, avant d’aborder le POC en lui-même, je voudrais revenir sur 3 piliers de l’observabilité, que sont les logs, les metrics et enfin le tracing qui est le sujet qui nous intéresse.
Les logs d’événements vont permettre d’enregistrer l’activité d’une application, et se définissent par un contexte et une date d’écriture. Elles sont faciles à générer et la plupart des langages ont déjà des librairies pour les implémenter facilement dans une application à microservices. Le fait de générer beaucoup de logs dans un système peut avoir des impacts sur les performances, et les coûts de facturation générés, en fonction de la plateforme qui héberge l’application, d’où l’importance à donner sur les logs qu’on souhaite écrire.
Ensuite viennent les metrics, au format numérique, elles vont nous permettent d’analyser le comportement et les performances d’un service. Celles-ci sont peu gourmandes au niveau performance système, ce qui permet facilement de les interroger, dans une application telle que Grafana par exemple.
Enfin, le tracing, le 3ᵉ pilier de l’observabilité, représente une série d’événements effectuée par une request, lorsque celle-ci parcourt plusieurs services (ou spam) dans une application. Utilisé ensemble avec des logs d’événements, cela permet d’avoir une meilleure visibilité de ce qui se passe dans une application microservices.
Tout comme les metrics, elles consomment moins que les logs, et on pourra utiliser Jaeger par exemple pour visualiser ces données.
Qu’est-ce que OpenTelemetry ?
Ce projet va permettre d’instrumenter notre application, avec des données de télémétrie standardisées, afin de les envoyer au backend Jaeger, que j’ai utilisé pour ce POC.
Par exemple, en Java, OpenTelemetry fournit un dépôt Core, contenant un SDK et une API pour l’implémenter à la main dans notre application, ainsi que le dépôt Instrumentation pour que cela se fasse de manière automatique via un agent.
Toutes ces données de télémétries vont nous permettre par la suite de les monitorer afin d’analyser plus facilement la root cause d’un bug applicatif, de visionner les dépendances de services ou d’optimiser les performances d’une application distribuée.
Qu’est-ce que Jaeger ?
Inspiré de OpenZipkin, Jaeger est un projet open-source concurrent de SigNoz, qui va nous aider à monitorer les données de tracing standardisées par OpenTelemetry, pour les analyser plus facilement dans un tableau de bord.
Ce projet est constitué de plusieurs composants, dont chacun d’eux est disponible dans une image Docker. Le composant jaeger-all-in-one quant à lui contient l’ensemble de ces composants.
- Le premier composant est l’agent, daemon qui écoute les spans (service applicatif) afin de les envoyer au collector.
- Le collector va récupérer les traces envoyées par les agents, afin de les indexer et les stocker. Ce composant peut être pluggé avec Cassandra, Elasticsearch ou Kafka.
- Enfin, le composant Query va permettre d’interroger et visualiser les données de télémétries dans un tableau de bord, en se basant sur les données récupérées par le collector.
On pourrait également parler du composant Ingester, qui est un service permettant de lire les données sur Kafka, afin de les envoyer dans une autre backend comme Cassandra ou Elasticsearch.
Application de démo Jaeger en local
Pour commencer ce POC, je suis parti de la documentation officielle de Jaeger pour tester la solution en local sur mon poste, en me basant sur l’application Java Springboot de démo springboot_jaeger_tutorial.
Bien documentée, j’ai trouvé que cette solution est une bonne porte d’entrée pour comprendre le fonctionnement et l’architecture de Jaeger, sans avoir besoin d’une application distribuée déployée dans un environnement Kubernetes.
Première étape : installation des composants Jaeger
Dans un premier temps, l’idée était de déployer tous les composants de base de Jaeger, c’est-à-dire l’Agent, le Collector et le Query. Pour cela, j’ai effectué cette commande, en ayant préalablement installé Docker sur mon poste Ubuntu :