Qu’est-ce qu’OpenTelemetry ?

OTel simplifie la collecte des données de télémétrie, quel que soit le langage de programmation, l’infrastructure ou l’environnement d’exécution, et permet aux développeurs de générer, collecter et exporter des données de télémétrie normalisées vers n’importe quel backend d’observabilité. Ce cadre standardisé renforce et étend les capacités d’observabilité, tout en offrant aux équipes informatiques et DevOps une flexibilité accrue.

OTel est mis en œuvre entre les applications, les systèmes et les équipements d’une part, et les solutions backend d’autre part – le stockage et la visualisation étant volontairement laissés à d’autres outils, ce qui donne aux entreprises la liberté de choisir ceux qui leur conviennent le mieux.

L’observabilité est la capacité à obtenir des informations sur le fonctionnement interne d’un système en analysant ses résultats externes. Dans les opérations informatiques (ITOps) et le cloud computing, les données télémétriques (telles que les journaux, les indicateurs et les traces) sont utilisées pour évaluer les performances et la santé du système. Les professionnels DevOps s’appuient sur l’instrumentation (ajout de code aux applications et aux systèmes pour produire et recueillir des données télémétriques) pour créer des systèmes observables.

Cette instrumentation est souvent une tâche complexe dans les environnements modernes, avec des environnements de cloud hybride et multicloud, des applications basées sur des microservices, des conteneurs Kubernetes et d’autres fonctionnalités des environnements informatiques actuels. Ces systèmes distribués, ainsi que les différents langages de programmation et environnements d’exécution qu’ils intègrent, présentent un ensemble complexe à instrumenter, collecter et exporter pour le stockage, la visualisation et l’analyse en arrière-plan.

Pour obtenir une vision complète des performances des services réseau et des applications, les ingénieurs doivent configurer une instrumentation personnalisée pour les applications et systèmes de l’ensemble de l’infrastructure. OpenTelemetry aide à résoudre ce problème.

OTel fournit une méthode standard pour recueillir et transmettre des données d’observabilité, ce qui contribue à simplifier la surveillance dans les systèmes distribués. Cet outil s’appuie sur des bibliothèques et des API unifiées et indépendantes des fournisseurs pour collecter et envoyer des données de télémétrie vers des plateformes back-end. En adoptant OpenTelemetry, les équipes peuvent recueillir et traiter de manière uniforme les données de télémétrie sur des systèmes complexes, quelles que soient les applications qu’elles gèrent ou les outils d’observabilité qu’elles emploient.

Autrefois, le code d’instrumentation variait énormément selon les environnements. Et comme aucun fournisseur commercial ne proposait un outil capable de collecter des données depuis toutes les applications et tous les services d’un réseau, il était difficile pour les entreprises de collecter des données dans différents langages et formats, ou encore de changer de backend. 

Si, par exemple, une équipe de développement souhaitait changer d’outils back-end, elle devrait réinstrumenter complètement son code et configurer de nouveaux agents pour envoyer les données de télémétrie aux nouveaux serveurs. Cette approche fragmentée créait également des silos de données et de la confusion, compliquant le dépannage et la résolution efficaces des problèmes de performances.

OpenTelemetry a représenté une avancée significative dans le domaine des outils d’observabilité, car il a standardisé la manière dont les données de télémétrie sont recueillies, analysées et transmises aux plateformes back-end. Il fournit une solution open source basée sur des normes communautaires pour la collecte de données sur le comportement et la sécurité des systèmes, aidant les équipes à rationaliser la surveillance et l’observabilité dans les écosystèmes distribués. Ainsi, OTel offre aux entreprises une approche ouverte et cohérente pour obtenir des données critiques à partir d’applications et de services réseau.

OpenTelemetry a été créé en combinant les fonctionnalités de traçage distribué d’OpenTracing et d’OpenCensus en un outil unique. OpenTracing était un projet open source conçu par la Cloud Native Computing Foundation (CNCF) pour fournir aux ingénieurs une API indépendante des fournisseurs, destinée à ajouter une instrumentation de traçage distribué aux applications. Il établissait un ensemble de conventions sémantiques afin de garantir la cohérence des données de télémétrie.

Cependant, contrairement à OpenTelemetry, OpenTracing n’était pas en soi une implémentation de traçage. Cette solution fournissait plutôt des interfaces que les systèmes de traçage pouvaient instaurer pour maximiser la compatibilité entre les plateformes. Si OpenTracing est aujourd’hui un projet abandonné qui encourage les utilisateurs à migrer vers OpenTelemetry, divers logiciels et solutions de traçage s’appuient toujours sur ses API.

OpenCensus est un ensemble de bibliothèques d’instrumentation développées par Google pour collecter des indicateurs d’application et des traces distribuées qui peuvent exporter des données vers différents systèmes back-end en temps réel. Il recueille des données à l’aide de balises de propagation et de métadonnées cohérentes, un concept désormais appelé « ressources » dans OpenTelemetry.

Avec OpenCensus, les applications peuvent importer et exporter des données selon leurs besoins spécifiques, offrant ainsi une grande flexibilité dans la manière dont les métriques et les traces sont envoyées aux backends d’observabilité. Contrairement à OpenTracing, OpenCensus n’a pas été officiellement abandonné : il continue de recevoir des mises à jour régulières de maintenance et de sécurité. Toutefois, le développement actif s’est largement déplacé vers OpenTelemetry.

Les deux projets visaient à résoudre le même problème. À l’époque, les équipes de développement ne disposaient d’aucune méthode standard pour instrumenter le code et transmettre les données de télémétrie aux outils d’observabilité back-end.

Cependant, aucun des deux projets ne pouvait résoudre ce problème à lui seul. La CNCF a donc parrainé le projet OpenTelemetry, qui regroupait les meilleures fonctionnalités de chaque solution. OpenTelemetry réunit la standardisation des API d’OpenTracing et les capacités de collecte de données d’OpenCensus afin de fournir une plateforme unique et unifiée pour l’envoi, la collecte et le transfert de données de télémétrie vers des plateformes d’observabilité back-end.

Pour assurer le fonctionnement de réseaux et d’applications rapides et hautement disponibles, il est essentiel de disposer d’une observabilité complète (ou visibilité), ce qui suppose un accès aux données de télémétrie. Les solutions d’observabilité collectent, surveillent et analysent les données de télémétrie pour évaluer l’état du système, puis fournissent aux équipes informatiques des informations exploitables pour les réparations et les optimisations.

Pour mieux comprendre OpenTelemetry, penchons-nous sur les données télémétriques et leur utilisation par les entreprises. OpenTelemetry prend en charge des types de données spécifiques, à savoir les sorties collectées à partir des journaux, des indicateurs et des traces (souvent appelées les « trois piliers de l’observabilité »).

Les indicateurs sont des mesures chiffrées de la performance du système et de l’utilisation des ressources. Ils donnent une vue d’ensemble de l’état du réseau en capturant des indicateurs clés de performance (KPIs) tels que la latence, la perte de paquets, l’utilisation de la bande passante et l’usage du processeur (CPU) des équipements.

Les indicateurs sont généralement résumés à l’aide de tableaux de bord et d’autres méthodes de visualisation. Ils fournissent souvent aux équipes les premières indications d’un problème de performance du système ou de l’application.

Les journaux sont des enregistrements détaillés de chaque événement ou action survenant dans l’environnement. Ils fournissent des informations granulaires sur ce qui s’est produit, à quel moment, et à quel endroit du réseau, offrant ainsi aux équipes un contexte précieux pour le dépannage, le débogage et les analyses post-incident.

Les journaux révèlent les causes sous-jacentes des problèmes en documentant des événements système comme des changements de configuration d’appareil, des échecs d’authentification ou des connexions interrompues.

Les traces captent le flux de données sur le réseau pour fournir des informations sur le chemin et le comportement des paquets lorsqu’ils traversent les différents appareils et systèmes. Leur rôle est essentiel pour comprendre les systèmes distribués et détecter les problèmes de latence.

Les données de traçage permettent aux équipes informatiques de suivre le cheminement complet d’une transaction, de bout en bout, afin d’identifier les retards et les défaillances dans des environnements complexes et multicouches.

Pour que la collecte des données soit efficace, OpenTelemetry s’appuie sur plusieurs composants et processus, parmi lesquels :

Une API est un ensemble de règles ou de protocoles qui permettent aux applications logicielles de communiquer entre elles pour échanger des données, des caractéristiques et des services.

OpenTelemetry fournit des API spécifiques à chaque langage (tel que Java, Ruby, JavaScript ou Python) que les développeurs peuvent employer pour instrumenter leurs applications afin de recueillir des données de télémétrie. Les API OpenTelemetry dissocient les applications de l’infrastructure réseau, ce qui donne aux équipes la flexibilité d’utiliser le point de terminaison qui correspond à leur code d’instrumentation.

Grâce aux SDK OpenTelemetry, les ingénieurs peuvent configurer et personnaliser le comportement des API. Les SDK font le lien entre les API et les collecteurs et permettent de connecter l’instrumentation manuelle des bibliothèques communes à celle des applications. 

OTel propose des SDK pour tout un éventail de langages de programmation, afin que les développeurs puissent exploiter les API OTel pour générer et exporter des données de télémétrie spécifiques au langage et au système back-end de leur choix. Les SDK OTel prennent également en charge l’instrumentation personnalisée pour les cadres internes qui ne sont pas encore couverts par la communauté OpenTelemetry.

Un collecteur est un agent qui collecte les données de télémétrie provenant des applications instrumentées avec OpenTelemetry. Composé de récepteurs, de processeurs, d’agrégats et d’exportateurs, le collecteur agit comme un intermédiaire neutre vis-à-vis des fournisseurs, en recevant les données des applications pour les transmettre à des plateformes d’observabilité ou à d’autres destinations d’analyse.

Le collecteur OpenTelemetry prend en charge les contrib packages qui lui permettent d’ingérer des données dans plusieurs formats – notamment OpenTelemetry Protocol (OTLP), Prometheus et Jaeger – et de les exporter vers différents backends, parfois simultanément (pour garantir la redondance). Les contrib packages sont des extensions tierces qui fournissent aux équipes de développement des outils tels qu’une instrumentation, des échantillonneurs, des propagateurs et des détecteurs de ressources, sous forme de sous-modules.

Les collecteurs peuvent également traiter et filtrer les données de télémétrie avant leur exportation, afin de donner la priorité aux informations les plus essentielles et d’accélérer les processus de dépannage et de débogage.

Les exportateurs font partie du collecteur et sont chargés d’envoyer les données de télémétrie des applications à un ou plusieurs backends d’observabilité spécifiés. Alors que les collecteurs gèrent l’ensemble du flux de données, les exportateurs donnent la priorité à la transmission des données vers leur destination.

Les exportateurs de données OpenTelemetry dissocient l’instrumentation des configurations back-end et convertissent les données au format adapté à chaque plateforme d’observabilité (en convertissant les traces au protocole Zipkin, par exemple). Cette dynamique permet au collecteur d’envoyer les mêmes données télémétriques à plusieurs systèmes back-end, ce qui facilite le changement de destination sans modifier la logique d’instrumentation du code.

L’instrumentation automatique fournit des bibliothèques et des cadres prêts à l’emploi qui permettent aux applications de générer automatiquement des données de télémétrie avec une modification minimale ou nulle du code. Ce processus simplifie l’instrumentation pour les développeurs, réduisant (et parfois éliminant) le codage manuel.

Cependant, l’auto-instrumentation peut offrir un contrôle moindre sur certains types de collecte de données par rapport à l’instrumentation manuelle. L’étendue de l’instrumentation automatique peut également varier en fonction des environnements d’exécution des langages, des environnements de calcul et du niveau de soutien communautaire aux frameworks d’observabilité.

OpenTelemetry allie des API, des SDK, des collecteurs et des processus d’instrumentation automatique pour extraire les données et les envoyer au système cible.

Dans un premier temps, l’équipe DevOps instrumente le code des applications avec les API OTel, en définissant quelles métriques, traces et journaux doivent être collectés et comment les collecter. Le collecteur SDK OTel rassemble les données et les prépare pour le traitement et l’exportation, puis les échantillonne, les filtre et les corrèle avec les dépendances et d’autres sources de données.

Lorsque les données traitées sont correctement formatées, le SDK les regroupe en lots basés sur le temps (où elles subissent un filtrage supplémentaire si nécessaire) et les envoie au système back-end désigné.

L’objectif principal d’OpenTelemetry est de collecter et d’exporter des données de télémétrie et d’améliorer l’observabilité, en offrant aux entreprises un outil qui facilite la neutralité vis-à-vis des fournisseurs ainsi que l’intégration de plateformes et d’outils. Il aide les équipes DevOps et les ingénieurs en fiabilité des sites (SRE) à gérer et à déboguer les applications et systèmes, afin de prendre des décisions plus éclairées et de rester agiles face à l’évolution des besoins métiers.

Les avantages d’OTel incluent :

• Une collecte de données cohérente. OpenTelemetry permet aux équipes de recueillir des données de télémétrie de manière cohérente entre différentes applications, différents systèmes et différents cas d’utilisation.

• Éviter l’enfermement propriétaire. OTel est une solution neutre vis-à-vis des fournisseurs qui permet aux développeurs de changer d’outils ou de prestataires d’observabilité sans avoir à modifier de façon significative le code d’instrumentation.

• Une observabilité rationalisée. OTel simplifie l’observabilité en collectant des données de télémétrie sans que le personnel informatique ait à modifier le code source ou les métadonnées. Les développeurs peuvent également conserver une visibilité complète des conteneurs, quels que soient les systèmes back-end ou les fournisseurs d’observabilité employés.

• Des écosystèmes informatiques pérennes. OpenTelemetry étant soutenu par une communauté open source et la CNCF, il est conçu pour évoluer au fur et à mesure que les technologies informatiques et les besoins en matière d’observabilité changent. Par exemple, OTel a récemment ajouté le profilage continu à son groupe de signaux de télémétrie primaires.¹

• Suivre l’utilisation des ressources. OpenTelemetry peut capturer les requêtes de données entre serveurs afin de catégoriser l’utilisation des ressources par groupes, ce qui aide les équipes informatiques à suivre l’utilisation des ressources dans des environnements partagés.

• Des demandes de données hiérarchisées. OpenTelemetry peut créer un pipeline de classement par priorité pour les demandes de données au sein de l’architecture, afin que les demandes concurrentes transitent par le réseau dans l’ordre de leur importance stratégique.

• Un accès élargi aux données de surveillance. Avec OTel, les développeurs peuvent surveiller les données de télémétrie et recevoir des alertes sur n’importe quel navigateur Web ou appareil, ce qui facilite le suivi en temps réel des performances des logiciels et de l’état général du système.