Parlons d’OpenTelemetry – un moyen standard et neutre de collecter des données de télémétrie.
Offrir une meilleure observabilité à une application est un grand défi pour tout développeur, car il doit capturer les données de télémétrie de l’application. Le dictionnaire de Cambridge définit la télémétrie comme la science ou le processus consistant à collecter des informations sur des objets éloignés et à les envoyer quelque part par voie électronique.
Par exemple, le simple clic ou la session d’un utilisateur sur un site web génère un grand nombre de requêtes et de traçages circulant entre les réseaux, les microservices, les bases de données, etc.
OpenTelemetry est une plateforme d’observabilité, un ensemble de composants bien adaptés qui peuvent être utilisés ensemble ou à la carte. En outre, les développeurs de frameworks et de bibliothèques que nous utilisons tous aujourd’hui disposent désormais d’un moyen standard d’intégrer des données de télémétrie dans ces bibliothèques et frameworks, ce qui permet aux utilisateurs finaux d’avoir un aperçu de ce que ces frameworks font sous le capot.
Pour comprendre OpenTelemetry, vous devez d’abord savoir ce qu’est le traçage distribué.
Qu’est-ce que le traçage distribué ?
Au fur et à mesure que nos applications deviennent plus complexes et qu’un plus grand nombre de services sont impliqués dans le trafic des utilisateurs et la réalisation des transactions, il devient de plus en plus critique de comprendre comment les requêtes traversent nos services et comment chaque service contribue à la latence globale. C’est ce que fait le traçage distribué. Il capture la latence des requêtes des utilisateurs et le temps qu’il faut à chaque microservice pour renvoyer une réponse.
Lorsqu’une demande d’utilisateur arrive, nous voulons créer une trace, c’est-à-dire l’ensemble des informations qui décrivent comment notre système répond à une demande d’utilisateur. Les traces sont composées de travées, et chaque travée représente une paire spécifique de requête et de réponse impliquée dans le traitement d’une requête d’utilisateur. L’étendue parentale décrit la latence telle qu’elle est observée par l’utilisateur final. L’étendue enfant est utilisée pour comprendre comment un service particulier du système distribué a été appelé et a répondu avec ses informations de latence.
Qu’est-ce que OpenTelemetry ?
OpenTelemetry est un projet open-source hébergé par la CNCF qui fournit un moyen standard de générer des données de télémétrie. Il est né de la fusion d’OpenTracing, un standard pour la génération de données de trace, et d’OpenCensus, un standard pour la génération de données de métrique.
OpenTelemetry offre un ensemble unique d’API, d’agents, de services de collecte et de bibliothèques pour capturer les traces distribuées et les métriques de votre application. OpenTelemetry standardise la façon dont nous collectons les données de télémétrie et les envoyons à un back-end de votre choix. Cela vous offre un chemin neutre vers l’instrumentation et vous donne la flexibilité de changer votre back-end sans avoir à instrumenter à nouveau votre code.
Vous pouvez donc instrumenter vos applications à l’aide d’un agent indépendant du fournisseur tout en envoyant vos mesures et traces à un fournisseur SaaS tel que Datadog. Si vous souhaitez changer de fournisseur (par exemple, de Datadog à Dynatrace), vous pouvez le faire sans modifier le code de votre application.
Le projet OpenTelemetry vise à fournir un ensemble unique d’API, de bibliothèques et d’agents pour capturer des métriques et des traces distribuées à partir de vos applications. Cela s’applique à de nombreux langages et plateformes. Le projet OpenTelemetry inclut également un service de collecte optionnel et dispose d’un référentiel dédié aux spécifications. Pour être clair, OpenTelemetry n’est pas Jaeger ou Prometheus, qui sont des back-ends observables. Mais il permet d’exporter des données vers des back-ends open-source et commerciaux.
Vous trouverez ci-dessous les fonctionnalités offertes par OpenTelemetry :
- Standardisation de la collecte des données de télémétrie que les organisations peuvent suivre, ce qui facilite le passage d’un fournisseur à l’autre
- Une convention sémantique ouverte et indépendante des fournisseurs pour le processus de collecte des données
- Un collecteur qui peut être déployé sous forme d’agent ou de passerelle de différentes manières
- Prise en charge de plusieurs formats de propagation de contexte pour la migration
- Une solution de bout en bout pour générer, émettre, collecter, traiter et exporter des données de télémétrie
- Possibilité d’envoyer des données vers différentes destinations en parallèle avec un contrôle complet sur celles-ci
Composants d’OpenTelemetry
Vous trouverez ci-dessous les principaux composants d’OpenTelemetry :
- Proto : Ce composant est utilisé pour définir les collecteurs, les bibliothèques d’instrumentation, etc., qui sont des types d’interface indépendants du langage pour OpenTelemetry.
- Collecteur : Les collecteurs sont utilisés pour recevoir, traiter et exporter les données de télémétrie. L’implémentation des collecteurs doit être indépendante du fournisseur. Par défaut, toutes les données de télémétrie sont exportées par les bibliothèques d’instrumentation à cet emplacement.
- Spécification : Ce composant décrit les exigences et les attentes de la mise en œuvre dans différents langages, à savoir les API, les SDK et les données. L’API génère les données de télémétrie, le traitement et les capacités d’exportation pour la mise en œuvre des API fournies par les SDK. Les données ont les conventions sémantiques nécessaires pour prendre en charge tous les types de fournisseurs sans modifier le code.
- Bibliothèques d’instrumentation : Elles sont disponibles dans plusieurs langues dans le cadre du projet OpenTelemetry. Ces bibliothèques sont utilisées pour fournir une observabilité à d’autres bibliothèques afin que toutes les applications soient observées en faisant des appels à l’API OpenTelemetry.
Architecture d’OpenTelemetry
Au niveau le plus élevé, OpenTelemetry se compose de trois éléments principaux :
- Un ensemble d’API pour instrumenter les applications, les bibliothèques et les cadres.
- Le SDK met en œuvre les API.
- Un collecteur optionnel qui permet d’ingérer, d’agréger et d’exporter les données de télémétrie là où vous en avez besoin.
L’objectif de l’API est de permettre la création d’une instrumentation pour les bibliothèques et le code de l’application. L’API comporte quatre sections principales : le traçage, les compteurs, un contexte partagé et des conventions sémantiques.
- L’API de traçage prend en charge la création, l’annotation et l’achèvement des portées.
- L’API des compteurs se compose de plusieurs instruments métriques. Les observateurs, les enregistreurs de valeurs et les compteurs sont des exemples de ces instruments.
- Vous pouvez suivre et exécuter le contexte des travées en activant l’API de contexte et propager ce contexte à l’intérieur et à l’extérieur de votre système.
- Les conventions sémantiques contiennent toutes les directives et les règles relatives à l’attribution des noms, comme les noms des portées, des attributs, des étiquettes et des instruments métriques. Ces conventions sont mises en œuvre pour garantir la cohérence entre les différentes implémentations linguistiques et pour les instruments externes.
Dans un contexte partagé, l’implémentation du contexte se situe entre le traceur et le compteur et permet à tous les enregistrements métriques non observateurs de se produire dans le contexte d’un span en cours d’exécution. Une fonctionnalité qui permet aux SDK de capturer des portées exemplaires pour les valeurs métriques. Vous pouvez personnaliser le contexte avec des propagateurs, qui permettent de propager le contexte du span dans et hors du système, ce qui permet un véritable traçage distribué.
Le collecteur est un élément essentiel de l’architecture OpenTelemetry. Il s’agit d’un service autonome qui peut recevoir, traiter et exporter des données de télémétrie provenant de différentes sources, y compris OpenCensus, Zipkin, Jaeger et le protocole OpenTelemetry. En utilisant les collecteurs, vous pouvez exporter des portées et des métriques vers plusieurs fournisseurs et systèmes de télémétrie open-source.
L’architecture OpenTelemetry offre une solution de télémétrie complète. Vous pouvez également la personnaliser en utilisant plusieurs points d’extension en fonction de vos besoins.
Comment fonctionne OpenTelemetry ?
A l’intérieur de chaque service de votre déploiement, installez le client OpenTelemetry. Le client est le SDK ; le SDK, à son tour, a une API. Les cadres et les bibliothèques de vos applications utilisent cette API d’instrumentation pour décrire le travail qu’ils effectuent. Le SDK exporte ensuite les observations collectées vers un service d’acheminement des données appelé Collecteur.
OpenTelemetry a son propre protocole de données, OTLP, mais le collecteur peut traduire OTLP dans différents formats, y compris Zipkin, Jaeger et Prometheus. Notamment, OpenTelemetry ne fournit pas son propre back-end ou outil d’analyse, car il s’agit d’un effort de standardisation au cœur d’OpenTelemetry. L’objectif est d’élaborer un langage universel pour décrire les opérations des ordinateurs dans un environnement en nuage. L’objectif n’est pas de normaliser la manière dont nous analysons ces données. Nous espérons plutôt qu’OpenTelemetry contribuera à faire avancer le monde de l’observabilité en permettant à de nouveaux outils d’analyse de démarrer rapidement sans avoir à reconstruire tout cet écosystème de logiciels de télémétrie.
Lorsque vous envoyez une grande quantité de données à travers le système, il y a beaucoup de choses à prendre en compte. Heureusement, OpenTelemetry a pensé à tout et propose des solutions à chacune de ces questions. Tout d’abord, OpenTelemetry est flexible et gère plusieurs formats de propagation de contexte. Cela signifie que même s’il y a un standard, il y a toujours la possibilité de choisir à l’intérieur de ce standard. Ainsi, si vous utilisez quelque chose comme le format de contexte w3c trace ou la propagation b3, il s’agit de normes différentes au sein de la norme qui permettent à vos services de relier les points.
Conclusion
OpenTelemetry collecte une variété d’observations, les métriques de traçage distribuées et les ressources système étant les plus importantes. Plutôt que de les traiter comme des signaux distincts, OpenTelemetry les rassemble et fournit une indexation et un contexte qui vous permettent d’agréger et de croiser l’indexation de tous ces signaux en arrière-plan.
En plus de la collecte de données, OpenTelemetry fournit un traitement de données et une installation de pipelines qui vous permet de changer les formats de données, de manipuler vos données, et tous les outils dont vous avez besoin pour construire un pipeline de télémétrie robuste dans un système moderne.
Voilà, c’était tout sur OpenTelemetry, allez-y et essayez cet outil.