Qu'est-ce qu'OpenTelemetry et comment peut-il améliorer la qualité de votre backend ?

Dans le passé, lorsque nous parlions du backend, nous faisions généralement référence à une grande application avec une seule et grande base de données, et la journalisation était suffisante pour la surveillance. Désormais, grâce à des technologies comme Kubernetes , les microservices sont devenus la norme. Les applications sont de plus en plus nombreuses et distribuées, et la journalisation traditionnelle ne suffit plus pour déboguer et diagnostiquer les problèmes de nos applications.

Une excellente solution pour organiser la surveillance est OpenTelemetry, une boîte à outils moderne qui peut être utilisée pour le débogage et l'analyse des performances des systèmes distribués.

Cet article est destiné aux professionnels de l'informatique souhaitant approfondir leurs connaissances en optimisation backend. Ci-dessous, nous détaillerons ce qu'est OpenTelemetry, ses concepts clés et les problèmes qu'il permet de résoudre. Si vous souhaitez savoir comment OpenTelemetry peut changer votre approche de la surveillance et du débogage des systèmes backend, en améliorant leur fiabilité et leur efficacité, poursuivez votre lecture.

Une brève histoire d’OpenTelemetry

Les grandes entreprises technologiques ont été confrontées pour la première fois au défi de la journalisation et du traçage distribués à la fin des années 2000. En 2010, Google a publié un article : Dapper, une infrastructure de traçage de systèmes distribués à grande échelle , qui a jeté les bases de l'outil de traçage de Twitter, Zipkin, lancé en 2012.

En 2014, Kubernetes est apparu, simplifiant considérablement le développement de microservices et d'autres systèmes distribués dans le cloud. Cela a conduit de nombreuses entreprises à rencontrer des problèmes de journalisation et de traçage distribués dans les microservices. Pour normaliser le traçage distribué, le standard OpenTracing, adopté par la CNCF, et le projet OpenCensus de Google ont été créés.

En 2019, les projets OpenTracing et OpenCensus ont annoncé une fusion sous le nom d'OpenTelemetry. Cette plateforme combine les meilleures pratiques accumulées au fil de nombreuses années, permettant une intégration transparente du traçage, de la journalisation et des métriques dans n'importe quel système, quelle que soit sa complexité.

Aujourd’hui, OpenTelemetry n’est pas seulement un projet ; il s'agit d'une norme industrielle pour la collecte et la transmission de données de télémétrie. Il est développé et soutenu par une communauté de spécialistes et d'entreprises leaders du marché comme Google et Microsoft. Le projet continue d'évoluer, acquérant de nouvelles capacités pour simplifier le processus d'intégration et d'utilisation.

Qu'est-ce qu'il y a à l'intérieur?

OpenTelemetry est un ensemble complet de pratiques et d'outils qui définissent les signaux qu'une application peut générer pour interagir avec le monde extérieur, et comment ces signaux peuvent être collectés et visualisés pour surveiller l'état des applications et du système dans son ensemble. Les trois principaux types de signaux sont le traçage, la journalisation et la collecte de métriques .

**Regardons de plus près chaque composant : \

Contextes

OpenTelemetry introduit le concept de contextes d'opération. Un contexte comprend principalement des attributs tels que `trace_id` (identifiant de l'opération en cours) et `span_id` (identifiant d'une sous-requête, chaque nouvelle tentative d'une sous-requête ayant un `span_id` unique).

De plus, un contexte peut contenir des informations statiques, telles que le nom du nœud sur lequel l'application est déployée ou le nom de l'environnement (prod/qa). Ces champs, appelés ressources dans la terminologie OpenTelemetry, sont attachés à chaque journal, métrique ou trace pour faciliter la recherche. Les contextes peuvent également inclure des données dynamiques, comme l'identifiant du point de terminaison actuel ( `http_path: "GET /user/:id/info"` ), qui peuvent être sélectivement attachées à des groupes de journaux, de métriques ou de traces.

Les contextes OpenTelemetry peuvent être transmis entre différentes applications à l'aide de protocoles de propagation de contexte. Ces protocoles sont constitués d'ensembles d'en-têtes qui sont ajoutés à chaque requête HTTP ou gRPC ou aux en-têtes de messages pour les files d'attente. Cela permet aux applications en aval de reconstruire le contexte d'opération à partir de ces en-têtes.

Voici quelques exemples de propagation de contexte :

1. B3-Propagation Il s'agit d'un ensemble d'en-têtes ( x-b3-* ) développé à l'origine pour le système de traçage Zipkin. Il a été adapté dans OpenTracing et utilisé par de nombreux outils et bibliothèques. B3-Propagation porte trace_id / span_id et un indicateur indiquant si un échantillonnage est nécessaire.

   
   

2. W3C Trace Context Développée par le groupe de travail du W3C, cette norme unifie diverses approches de propagation de contexte en une seule norme et constitue la norme par défaut dans OpenTelemetry. Un bon exemple d'application de ces normes est le suivi de l'exécution d'une requête passant par des microservices implémentés avec différentes technologies sans compromettre la précision de la surveillance et du débogage.

Tracé

Le traçage est le processus d'enregistrement puis de visualisation de la chronologie du cheminement d'une requête à travers plusieurs microservices.

Dans la visualisation, chaque barre est appelée « span » et possède un « span_id » unique. L'étendue racine est appelée « trace » et possède un « trace_id » , qui sert d'identifiant pour l'ensemble de la requête.

Ce type de visualisation permet de :

• Analysez le temps d'exécution des requêtes sur différents systèmes et bases de données pour identifier les goulots d'étranglement qui nécessitent une optimisation.
• Détectez les dépendances cycliques entre les services.
• Recherchez les demandes en double. À l'aide des données de traçage, vous pouvez également créer des analyses supplémentaires, telles que la création d'une carte de microservices ou la répartition du temps entre différents systèmes pendant le traitement des opérations. Même si vous n'utilisez pas de données de trace pour visualiser les chronologies, OpenTelemetry génère toujours trace_id et span_id à utiliser dans d'autres signaux.

Journaux

Malgré son apparente simplicité, la journalisation reste l’un des outils les plus puissants pour diagnostiquer les problèmes. OpenTelemetry améliore la journalisation traditionnelle en ajoutant des informations contextuelles. Plus précisément, si une trace active est présente, les attributs « trace_id » et « span_id » sont automatiquement ajoutés aux journaux, les liant à la chronologie de la trace. De plus, les attributs de journal peuvent inclure des informations statiques du contexte OpenTelemetry, telles que l'identifiant du nœud, ainsi que des informations dynamiques, comme l'identifiant du point de terminaison HTTP actuel (`http_path: "GET /user/:id"`).

À l'aide du « trace_id », vous pouvez trouver les journaux de tous les microservices associés à la requête en cours, tandis que le « span_id » vous permet de différencier les sous-requêtes. Par exemple, dans le cas de nouvelles tentatives, les journaux de différentes tentatives auront des « span_id » différents. L'utilisation de ces identifiants permet une analyse rapide du comportement de l'ensemble du système en temps réel, accélérant ainsi le diagnostic des problèmes et améliorant la stabilité et la fiabilité.

Métrique

La collecte de métriques fournit des données quantitatives sur les performances du système, telles que la latence, les taux d'erreur, l'utilisation des ressources, etc. La surveillance en temps réel des métriques vous permet de répondre rapidement aux changements de performances, d'éviter les pannes et l'épuisement des ressources et de garantir la haute disponibilité et la fiabilité de l'application pour les utilisateurs.

L'intégration avec des systèmes de stockage et de visualisation métriques tels que Prometheus et Grafana facilite la visualisation de ces données, simplifiant considérablement la surveillance.

Collectionneurs métriques

Les collecteurs de métriques OpenTelemetry sont compatibles avec les standards Prometheus et OpenMetrics, permettant une transition facile vers les solutions OpenTelemetry sans changements significatifs. Le SDK OpenTelemetry permet d'exporter des exemples trace_id avec des métriques, ce qui permet de corréler les métriques avec les exemples de journaux et les traces.

Corrélation des signaux

Ensemble, les journaux, les métriques et le traçage créent une vue complète de l'état du système :

• Les journaux fournissent des informations sur les événements système, permettant une identification et une résolution rapides des erreurs.
• Les mesures reflètent les indicateurs de performance qualitatifs et quantitatifs du système, tels que les temps de réponse ou les taux d'erreur.
• Le traçage complète cette vue en montrant le chemin d'exécution de la demande à travers divers composants du système, aidant ainsi à comprendre leurs interrelations. La corrélation claire entre les journaux, les traces et les métriques est une caractéristique distinctive d'OpenTelemetry. Par exemple, Grafana permet aux utilisateurs de voir la trace correspondante et de demander des métriques lors de la visualisation d'un journal, améliorant considérablement la convivialité et l'efficacité de la plateforme.

En plus des trois composants principaux, OpenTelemetry inclut les concepts de gestion d'échantillonnage, de bagages et de contexte opérationnel.

Échantillonnage

Dans les systèmes à forte charge, le volume de journaux et de traces devient énorme, nécessitant des ressources substantielles pour l'infrastructure et le stockage des données. Pour résoudre ce problème, les normes OpenTelemetry incluent l'échantillonnage du signal, c'est-à-dire la possibilité d'exporter uniquement une partie des traces et des journaux. Par exemple, vous pouvez exporter des signaux détaillés à partir d'un pourcentage de requêtes, de requêtes de longue durée ou de requêtes d'erreur. Cette approche permet un échantillonnage suffisant pour construire des statistiques tout en économisant des ressources importantes.

Cependant, si chaque système décide indépendamment quelles requêtes surveiller en détail, nous nous retrouvons avec une vue fragmentée de chaque requête. Certains systèmes peuvent exporter des données détaillées tandis que d’autres peuvent n’exporter que partiellement ou pas du tout.

Pour résoudre ce problème, les mécanismes de propagation de contexte d'OpenTelemetry transmettent un indicateur d'échantillonnage avec le `trace_id`/`span_id`. Cela garantit que si le service initial recevant la demande de l'utilisateur décide que la demande doit être surveillée en détail, tous les autres systèmes emboîteront le pas. Sinon, tous les systèmes devraient exporter partiellement ou non les signaux pour conserver les ressources. Cette approche est appelée « Head Sampling » — une décision prise au début du traitement de la demande, soit de manière aléatoire, soit sur la base de certains attributs d'entrée.

En outre, OpenTelemetry prend en charge le « Tail Sampling », où toutes les applications exportent toujours tous les signaux en détail, mais il existe un tampon intermédiaire. Après avoir collecté toutes les données, ce tampon décide s'il doit conserver l'intégralité des données ou n'en conserver qu'un échantillon partiel. Cette méthode permet d'obtenir un échantillon plus représentatif de chaque catégorie de demande (réussie/longue/erreur) mais nécessite une configuration d'infrastructure supplémentaire.

bagages

Le mécanisme Baggage permet de transmettre des paires clé-valeur arbitraires avec trace_id / span_id , passant automatiquement entre tous les microservices pendant le traitement de la demande. Ceci est utile pour transmettre des informations supplémentaires nécessaires tout au long du chemin de la requête, telles que des informations utilisateur ou des paramètres d'environnement d'exécution.

Exemple d'en-tête de transmission de bagages selon la norme W3C : tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Voici quelques exemples d’utilisation des bagages :

• Transmission des informations de contexte métier telles que userId , productId ou deviceId peuvent être transmises via tous les microservices. Les applications peuvent enregistrer automatiquement ces informations, permettant ainsi des recherches de journaux par contexte utilisateur pour la demande d'origine.

• Paramètres de configuration spécifiques Paramètres pour les SDK ou l'infrastructure.

• Indicateurs de routage Indicateurs qui aident les équilibreurs de charge à prendre des décisions de routage. Pendant les tests, certaines requêtes devront peut-être être acheminées vers des backends fictifs. Étant donné que les bagages sont transmis automatiquement via tous les services, il n'est pas nécessaire de créer des protocoles supplémentaires : il suffit de définir une règle sur l'équilibreur de charge.

  
  

Mise en œuvre des infrastructures

La mise en œuvre d'OpenTelemetry au niveau de l'infrastructure implique l'intégration des backends OpenTelemetry dans l'architecture de l'application et la configuration de l'infrastructure pour l'agrégation des données.

Le processus comprend quatre étapes :

1. Intégration des applications Dans un premier temps, les SDK OpenTelemetry sont directement intégrés aux applications pour collecter des métriques, des journaux et des traces, garantissant ainsi un flux continu de données sur les performances de chaque composant du système.

   
   

2. Configuration des exportateurs Les données collectées sont acheminées depuis les applications via les exportateurs vers des systèmes externes pour un traitement ultérieur, tels que des systèmes de journalisation, de surveillance, de traçage ou d'analyse, en fonction de vos besoins.

   
   

3. Agrégation et stockage Cette étape peut impliquer la normalisation des données, leur enrichissement avec des informations supplémentaires et la fusion des données provenant de différentes sources pour créer une vue unifiée de l'état du système.

   
   

4. Visualisation des données Enfin, les données traitées sont présentées sous forme de tableaux de bord dans des systèmes comme Grafana (pour les métriques et les traces) ou Kibana (pour les journaux). Cela permet aux équipes d'évaluer rapidement l'état du système, d'identifier les problèmes et les tendances et de configurer des alertes basées sur les signaux générés.

Implémentation d'applications

Pour intégrer une application, vous devez connecter le SDK OpenTelemetry approprié au langage de programmation utilisé ou utiliser des bibliothèques et des frameworks prenant directement en charge OpenTelemetry. OpenTelemetry implémente souvent des interfaces largement utilisées à partir de bibliothèques connues, permettant des remplacements instantanés. Par exemple, la bibliothèque Micrometer est couramment utilisée pour la collecte de métriques dans l'écosystème Java. Le SDK OpenTelemetry fournit ses implémentations d'interfaces Micrometer, permettant l'exportation de métriques sans modifier le code de l'application principale. De plus, OpenTelemetry propose des implémentations d'anciennes interfaces OpenTracing et OpenCensus, facilitant une migration en douceur vers OpenTelemetry.

Conclusion

Dans les systèmes informatiques, OpenTelemetry peut devenir la clé du futur des backends fiables et efficaces. Cet outil simplifie le débogage et la surveillance et ouvre également des opportunités pour une compréhension approfondie des performances et de l'optimisation des applications à un nouveau niveau. Rejoignez la communauté OpenTelemetry pour contribuer à façonner un avenir où le développement backend est plus simple et plus efficace !