Qu’est-ce qu’OpenTelemetry ?

En observabilité, les données de télémétrie sont les résultats collectés à partir des sources du système. Analysés ensemble, ces résultats fournissent une image des relations et des dépendances au sein d’un système distribué. On utilise principalement trois classes de données, souvent appelées « les trois piliers de l’observabilité » : les logs, les métriques et les traces.

• Logs : un log est un enregistrement sous forme de texte d’un événement qui s’est produit à un moment donné. Chaque fois qu’un bloc de code est exécuté, une entrée est ajoutée au log pour consigner l’heure à laquelle l’événement s’est produit et fournir une « charge utile » de contexte sur cet événement. Les données de logs existent sous trois formes : texte brut, structurées et non structurées. Le texte brut est le plus courant, mais les logs structurés, qui incluent des métadonnées supplémentaires et sont plus faciles à interroger, deviennent de plus en plus populaires. À l’inverse, les journaux non structurés sont plus difficiles à analyser. Les journaux sont généralement la source de vérité permettant de savoir ce que fait une application. Ce sont eux qu’on consulte en cas de problème dans un système, et les développeurs comptent sur eux pour dépanner leur code et vérifier son exécution. Une défaillance dans un système distribué s’explique généralement par une série de causes sous-jacentes (parfois appelées causes profondes), et la journalisation nous fournit des détails précis sur l’exécution de certains blocs de code.
• Métriques : une métrique est une valeur numérique mesurée sur un certain intervalle de temps. Elle comprend des attributs spécifiques, dont l’horodatage, le nom de l’événement et la valeur de cet événement. Contrairement aux logs, les métriques se présentent par défaut sous une forme structurée, ce qui les rend plus faciles à interroger. Cette caractéristique facilite également leur stockage, ce qui vous permet de conserver une grande quantité de métriques pendant de longues périodes et ainsi d’obtenir une meilleure perspective sur les tendances historiques d’un système. Les métriques sont idéales pour les grands ensembles de données ou les données collectées à intervalles réguliers, lorsque vous souhaitez une réponse à une question spécifique. Nous observons généralement les métriques sous une forme agrégée au fil du temps, une approche cruciale pour analyser et traiter les problèmes dans nos systèmes modernes. Sous forme agrégée ou de point unique, les métriques alimentent des alertes qui sont souvent le premier indicateur de problèmes dans nos systèmes.
• Traces : une trace représente le trajet de bout en bout d’une requête à travers un système distribué. De nombreuses opérations sont effectuées sur une même requête au fil de son parcours dans un système. Chaque opération est codée, accompagnée de données importantes, pour former une « unité logique » incluant l’identifiant de trace, l’identifiant d’intervalle, le nom de l’opération, un horodatage de début et de fin, des logs, des événements et d’autres informations indexées. En affichant une trace, grâce à ce qu’on appelle le traçage distribué, vous pouvez suivre le parcours d’exécution complet et identifier quelle partie du code est à l’origine d’erreurs, de latence ou de problèmes de disponibilité des ressources. Les traces peuvent également générer des métriques, notamment sous une forme appelée RED (taux, erreurs et durée). Surtout, les traces apportent du contexte aidant à déterminer quelles instances des deux autres piliers sont les plus indiqués pour résoudre un problème particulier.

Individuellement, les logs, les métriques et les traces ont des objectifs différents, mais ensemble, ils fournissent les informations détaillées et complètes qui sont indispensables pour comprendre et dépanner les systèmes distribués.

OpenTelemetry est utilisé pour collecter des données de télémétrie à partir des systèmes distribués afin de dépanner, déboguer et gérer les applications et leur environnement hôte. Il offre aux équipes IT et de développeurs un moyen simple d’instrumenter leur base de code pour collecter des données et d’effectuer des ajustements au fil du développement de l’entreprise.

OpenTelemetry collecte plusieurs classes de données télémétriques (logs, métriques et traces) et les exporte vers des plateformes en back-end pour traitement. L’analyse de ces données de télémétrie permet aux équipes d’apporter de la cohérence à des écosystèmes multicouches. Cela facilite grandement l’observation du comportement des systèmes et la résolution des problèmes de performances.

Le framework OpenTelemetry possède plusieurs composants :

• Des API OpenTelemetry spécifiques par langage (Java, Python, JavaScript et d’autres) pour instrumenter le code en vue de la collecte de données.
• Des exportateurs pour permettre la transmission des données de télémétrie vers la plateforme d’observabilité back-end de votre choix.
• Des SDK OpenTelemetry spécifiques par langage pour établir un pont entre les API et les exportateurs.
• Le collecteur OpenTelemetry, qui délivre une implémentation indépendante du fournisseur pour la réception, le traitement et l’exportation des données de télémétrie.

OpenTelemetry est un outil essentiel pour le DevOps car les données qu’il fournit simplifient la génération d’alertes, le dépannage et le débogage des applications. Si les données de télémétrie ont toujours été utilisées pour comprendre le comportement des systèmes, la complexité générale du réseau a rendu la collecte et l’analyse des données de traçage plus difficiles. Dans ces systèmes labyrinthiques, tracer la cause d’un incident unique à l’aide de méthodes conventionnelles peut prendre des heures voire des jours.

Mais OpenTelemetry améliore l’observabilité de ces systèmes en rassemblant les traces, les logs et les métriques de l’ensemble des applications et services en les corrélant. De plus, ce projet open-source élimine les obstacles à l’instrumentation afin que les entreprises puissent se concentrer sur des fonctions vitales telles que la supervision des performances des applications (APM), entre autres. Le résultat ? Une plus grande efficacité dans l’identification et la résolution des incidents, une meilleure fiabilité du service et des temps d’arrêt réduits.

OpenTelemetry offre plusieurs avantages, dont voici les trois principaux.

Cohérence : la pratique consistant à collecter des données de télémétrie à partir des applications existait avant OpenTelemetry, mais elle demandait un effort bien plus important. Il était difficile de trouver les bons outils d’instrumentation, et une fois la solution ou le fournisseur choisi, vous y étiez lié par contrat. Il était peu probable que cette solution soit cohérente d’une application à l’autre, ce qui rendait quasiment impossible d’obtenir une compréhension globale des performances d’une application.

OpenTelemetry, par contre, propose un parcours cohérent permettant de capturer les données de télémétrie et de les transmettre à un back-end sans changer l’instrumentation, créant une norme de facto pour l’intégration de l’observabilité aux applications natives du cloud. Libérés des complexités de l’instrumentation, les développeurs et l’IT peuvent désormais consacrer plus de temps à la création de nouvelles fonctionnalités.

Un choix plus simple : avant OpenTelemetry, les entreprises devaient choisir entre OpenTracing ou OpenCensus, chacun offrant une approche différente de l’observabilité. Comme OpenTelemetry fusionne le code de ces deux frameworks, vous obtenez les avantages des deux au sein d’une même solution. Et il n’y a aucun risque à passer à OpenTelemetry si vous utilisiez l’un ou l’autre auparavant. OpenTelemetry est rétrocompatible avec les deux.

Une observabilité rationalisée : OpenTelemetry permet aux développeurs d’afficher les données d’utilisation et de performances des applications sur n’importe quel appareil ou navigateur web. Cette interface pratique facilite le suivi et l’analyse des données d’observabilité en temps réel.

Bien entendu, le plus grand avantage est l’acquisition de l’observabilité nécessaire pour atteindre les objectifs commerciaux. OpenTelemetry consolide les données de télémétrie nécessaires pour déterminer si les systèmes fonctionnent correctement, comprendre où les problèmes peuvent compromettre les performances et corriger les causes profondes, potentiellement avant une interruption du service, ce qui améliore la stabilité et la fiabilité de la prise en charge des processus métier.

OpenTelemetry peut injecter les données collectées dans un moteur d’IA pour produire automatiquement des informations exploitables. Pour donner un exemple, le moteur d’IA peut analyser en continu les données capturées par OpenTelemetry ainsi que d’autres données utiles, puis rechercher des anomalies dans l’ensemble de la pile sans aucune intervention humaine. L’IA peut révéler et traiter des milliards de dépendances au sein d’un système distribué en quelques fractions de seconde et détecter une activité invisible. Elle peut également identifier automatiquement la source des problèmes et, si possible et souhaitable, les résoudre avant qu’ils n’affectent les utilisateurs finaux. Grâce à ce processus continu, l’IA peut apprendre ce qu’est l’état « normal » du système et adapter ses réponses pour améliorer ses performances au fil du temps, jusqu’à prédire les problèmes avant qu’ils ne surviennent.

Pour synthétiser, l’intégration de l’IA augmente la valeur d’OpenTelemetry en réduisant l’effort manuel nécessaire pour analyser les conditions et en facilitant l’extraction d’informations exploitables.

OpenTelemetry est le fruit de la fusion de deux projets de traçage distribué open source qui se recoupent, OpenTracing et OpenCensus.

OpenTracing, hébergé par la Cloud Native Computing Foundation (CNCF), visait à fournir une API standardisée pour le traçage. Entre autres choses, il permet aux développeurs d’intégrer l’instrumentation dans des bibliothèques couramment utilisées ou dans leur propre code personnalisé sans avoir à s’engager vis-à-vis d’un fournisseur particulier. C’était un concept unique au moment de sa mise en œuvre. Bien qu’OpenTracing ait donné aux développeurs la flexibilité dont ils avaient tant besoin, ses applications étaient limitées et ses implémentations, incohérentes, du fait de sa focalisation exclusive sur le traçage.

Google a développé OpenCensus sur la base de sa plateforme de traçage interne. Une fois le projet publié en open source, Microsoft, avec d’autres fournisseurs et contributeurs, s’est impliqué et a fait évoluer le standard. OpenCensus était un ensemble de bibliothèques multi-langages qui collectait des métriques sur le comportement des applications, puis transférait ces données vers la plateforme d’analyse en back-end choisie par le développeur pour faciliter le débogage. Cette norme pouvait également suivre les messages les requêtes et les services de leur source à leur destination. Mais en l’absence d’API disponible pour intégrer OpenCensus dans le code, les développeurs devaient utiliser des agents d’instrumentation automatique créés par la communauté.

OpenTelemetry est né lorsque les projets OpenTracing et OpenCensus ont convenu de fusionner leurs bases de code, incorporant les points forts de chacun sous le contrôle de la CNCF. Actuellement en version bêta, OpenTelemetry propose un même ensemble d’API, de bibliothèques, d’agents et de services de collecte pour capturer les traces et les métriques distribuées (ainsi que les logs, prochainement) de n’importe quelle application, puis les analyser à l’aide d’outils d’observabilité populaires.

OpenTracing est un ensemble de spécifications, de cadres et de bibliothèques d’API indépendant des fournisseurs (il n’appartient à aucune entreprise en particulier), qui aide les développeurs à instrumenter le traçage dans leur base de code. OpenTracing simplifie le processus de traçage distribué en fournissant un mécanisme standard utilisable par les développeurs pour instrumenter leur propre code sans dépendre d’un fournisseur de traçage particulier.

Le traçage distribué, également appelé traçage des requêtes distribué, est une méthode de supervision destinée aux applications construites sur une architecture de microservices. Les programmeurs utilisent le traçage et d’autres formes de journalisation pour collecter des informations sur le comportement d’une application. Les développeurs utilisent ces informations pour le débogage, tandis que les administrateurs système, l’assistance technique et d’autres groupes les exploitent pour dépanner les applications et les services.

L’observabilité est la pratique qui consiste à mesurer les états internes d’un système en examinant ce qu’il produit. C’est un terme qui trouve son origine dans la théorie du contrôle, qui s’intéresse à la description et à la compréhension du fonctionnement des systèmes d’autorégulation. De plus en plus d’entreprises ajoutent de l’observabilité aux systèmes informatiques distribués pour comprendre et améliorer leurs performances. Dans ce contexte, l’observabilité utilise les données de télémétrie pour obtenir une visibilité approfondie sur ces systèmes et permettre aux équipes de répondre à une multitude de questions sur leur comportement.

La gestion des systèmes distribués représente un défi en raison du nombre considérables de parties interdépendantes connectées via des chemins de communication aux liens souples. Ils sont ainsi exposés à des défaillances toujours plus nombreuses et diverses. Comprendre les problèmes qui affectent l’état actuel d’un système distribué devient très difficile, et l’on ne parle pas de prédire les problèmes à venir. Pour dire les choses simplement, les systèmes distribués produisent plus d’« inconnues inconnues » que les systèmes plus simples. Et comme la supervision conventionnelle repose sur les « inconnues connues », elle a du mal à identifier les problèmes dans ces environnements complexes.

L’observabilité est mieux adaptée à cette imprévisibilité. Elle offre un meilleur contrôle sur ces systèmes modernes complexes, et rend leur comportement plus facile à interpréter. Les équipes identifient plus aisément les liens interrompus dans un environnement complexe et remontent jusqu’à la cause. L’observabilité permet également aux développeurs d’adopter une approche exploratoire des défaillances du système en posant des questions telles que « Pourquoi est-ce que X ne fonctionne plus ? » ou « Qu’est-ce qui provoque de la latence en ce moment ? ».

Pour atteindre l’observabilité, vous devez préparer vos systèmes et applications afin de recueillir les données de télémétrie appropriées. Vous pouvez acheter une plateforme d’observabilité commerciale, utiliser une solution open source ou créer la vôtre. Dans tous les cas, l’observabilité repose sur quatre composants :

• l’instrumentation. Les outils de mesure collectent les données de télémétrie d’un conteneur, d’un service, d’une application, d’un hôte et de tout autre composant de votre système qui produit des données. De cette manière, vous obtenez et conservez une visibilité sur l’ensemble de votre infrastructure lorsque vous ajoutez de nouveaux composants et types de données. L’auto-instrumentation est cruciale pour une mise en œuvre rapide ;
• la corrélation des données. Les données de télémétrie collectées à partir de votre système sont traitées et corrélées. Cette opération apporte un contexte et permet une sélection automatique ou personnalisée des données pour les visualisations de l’outil d’observabilité ;
• la réponse aux incidents. Les technologies automatisées transmettent les données sur les interruptions de service aux personnes et aux équipes concernées ;
• l’AIOps. Le machine learning agrège, corrèle et hiérarchise automatiquement les données d’incident. On améliore ainsi le rapport signal-bruit des alertes, ce qui permet aux équipes de détecter les problèmes et d’accélérer la réponse aux incidents.

OpenTelemetry est un moyen d’atteindre l’observabilité. Les entreprises doivent ajouter de l’instrumentation à l’ensemble de leur infrastructure pour obtenir une visibilité de bout en bout. La tâche est ardue avec une seule solution commerciale, mais OpenTelemetry normalise l’instrumentation nécessaire pour collecter les données de télémétrie et atteindre l’observabilité.

Le projet OpenTelemetry n’en est qu’à ses débuts. Il est actuellement en version bêta et ne prend en charge que les traces et les métriques ; la prise en charge des logs en est aux étapes de planification initiales. Les équipes de projet travaillent à la stabilisation des composants de base d’OpenTelemetry, à l’intégration de l’instrumentation automatisée via des agents, à l’ajout de nouveaux langages compatibles et à l’amélioration des capacités liées aux métriques. Une version de qualité production devrait ensuite voir le jour. OpenTelemetry est l’un des plus grands projets open source de la CNCF (avec Prometheus et Kubernetes) et reçoit un soutien considérable de la communauté technologique. OpenTelemetry sera à terme le cadre d’observabilité dominant dans le paysage de télémétrie natif du cloud.

Les déploiements distribués peuvent prendre la forme de petits déploiements à service unique sur des réseaux locaux, ou de déploiements mondiaux à grande échelle. En plus de leur taille et de leur complexité globale, les entreprises peuvent évaluer les options de déploiement en fonction de la taille et de la capacité de leur réseau informatique, de la quantité de données qu’elles consommeront, de la fréquence à laquelle elles exécutent des processus, qu’ils soient planifiés ou ad hoc, du nombre d’utilisateurs accédant au système, de la capacité de leur datacenter et des exigences nécessaires en matière de fidélité et de disponibilité des données.

Sur la base de ces considérations, les déploiements distribués sont classés en fonction de leur envergure : département, petite entreprise, moyenne entreprise ou grande entreprise. Bien qu’il n’y ait pas de taxonomie officielle pour distinguer une petite entreprise d’une moyenne, ces catégories offrent un point de départ pour planifier les ressources nécessaires à la mise en œuvre d’un système informatique distribué. Les systèmes distribués peuvent également évoluer au fil du temps et gagner progressivement de l’envergure, passant de l’échelle du département à celui de la petite entreprise.

L’informatique moderne ne serait pas possible sans les systèmes distribués. Ils sont essentiels au fonctionnement des réseaux sans fil, des services de cloud computing et d’Internet. Sans les systèmes distribués, aucune de ces technologies ne serait possible.

Mais avons-nous besoin de systèmes distribués pour les tâches d’entreprise qui n’ont pas la complexité d’un réseau de télécommunications complet ? Dans la majorité des cas, la réponse est oui. Les systèmes distribués offrent une évolutivité et des performances hors d’accès pour les systèmes monolithiques. Et comme ils tirent parti des capacités d’autres dispositifs et processus informatiques, ils peuvent offrir des fonctionnalités qui seraient difficiles ou impossibles à développer sur un système unique.

C’est utile, par exemple, pour réaliser une sauvegarde de serveurs et d’applications hors site : si le catalogue principal ne voit pas les octets de segment dont il a besoin pour une restauration, il peut demander aux autres nœuds distants d’envoyer les segments. Mais en bout de ligne, tout ce que vous faites ou presque avec un appareil informatique de nos jours exploite la puissance des systèmes distribués, qu’il s’agisse d’envoyer un e-mail, de jouer à un jeu ou de lire cet article sur le Web.

Au cours des deux dernières décennies, la transformation numérique a créé de nouvelles façons de travailler, et les applications mobiles et web revêtent aujourd’hui une importance stratégique.

La collecte de données est un moteur essentiel de ces applications natives du cloud, mais de nombreuses entreprises ne sont pas équipées pour cela. 57 % des entreprises de tous les secteurs affirment que le volume des données augmente plus vite que leur capacité à les gérer, et 47 % des professionnels IT déclarent tout simplement que leur organisation ne sera pas à la hauteur d’une augmentation rapide du volume de données. Et s’ils sont une majorité à penser que les données sont essentielles au succès global et à l’innovation, les deux tiers d’entre eux déclarent que les « dark data » représentent la moitié ou plus de leurs données, soit une augmentation de 10 % par rapport à l’année précédente.

OpenTelemetry est la clé de la maîtrise de votre télémétrie et vous offre la visibilité complète dont vous avez besoin pour améliorer vos pratiques d’observabilité. Cette norme fournit des outils pour collecter des données sur l’ensemble de votre pile technologique, sans vous enliser dans des délibérations sans fin. Elle contribue au final à préserver les performances de vos applications et améliore considérablement les résultats commerciaux.