Qu'est-ce qu'OpenTelemetry ?

Définition, avantages et composants clés d'OpenTelemetry

OpenTelemetry (OTel) est un framework open source dédié à l’observabilité. Il permet de collecter, traiter et exporter les données de télémétrie (logs, métriques et traces) dans un format unifié.

Ce projet a été développé par la Cloud Native Computing Foundation (CNCF) afin de standardiser la collecte et l’envoi des données de télémétrie vers des backends d’observabilité. OpenTelemetry fournit des SDK, des API et des outils neutres vis-à-vis des fournisseurs, pour que vos données puissent être envoyées à une solution d’observabilité compatible avec OpenTelemetry.

OpenTelemetry s’impose rapidement comme la norme de référence pour la télémétrie dans les applications cloud-native. Adopter OpenTelemetry est aujourd’hui un enjeu stratégique pour les organisations souhaitant anticiper les besoins futurs sans dépendre d’un fournisseur ou se heurter aux limites de leurs technologies existantes.

Schéma montrant l'intégration d'OpenTelemetry avec Elastic pour l'observabilité des microservices


Comprendre les données de télémétrie (logs, métriques et traces)

Les données de télémétrie sont au cœur de l’observabilité moderne. Les trois piliers – logs, métriques et traces – offrent aux développeurs, aux équipes DevOps et aux équipes IT une visibilité approfondie sur le comportement, les performances et l’état de santé des systèmes.

  • Logs : un enregistrement textuel d’un événement discret à un instant donné
    • Exemple : une tentative de connexion enregistrée avec un horodatage, un ID utilisateur et une adresse IP
    • Idéal pour : le dépannage, le débogage et la vérification de l'exécution du code
  • Métriques : des mesures numériques dans le temps (données en séries chronologiques) qui reflètent les performances du système
    • Exemple : taux d’utilisation du CPU à 85 % ou taux de requêtes HTTP à 1 200/s
    • Idéal pour : la surveillance en temps réel, les alertes et l'analyse des tendances
  • Traces : le parcours d’une requête ou d’une transaction à travers plusieurs composants d’un système, découpé en spans
    • Exemple : suivi d’un processus de paiement réparti entre plusieurs microservices dans une plateforme e-commerce
    • Idéal pour : Identifier les goulots d'étranglement de performance et comprendre les flux de requêtes dans les architectures distribuées

Pour en savoir plus sur la collecte de chaque type de donnée avec OpenTelemetry, consultez notre documentation Getting Started with OpenTelemetry in Elastic.


Brève histoire d'OpenTelemetry

Avant OpenTelemetry, le secteur s’appuyait sur OpenTracing et OpenCensus : deux projets qui poursuivaient des objectifs similaires, mais avec des implémentations différentes. Pour éviter la fragmentation, la CNCF les a fusionnés dans un projet unique : OpenTelemetry.

Principaux composants hérités :

  • OpenTracing : des API neutres pour l’envoi de données de télémétrie
  • OpenCensus : bibliothèques spécifiques à chaque langue pour la collecte de métriques/traces

Résultat de la fusion : OTel réunit les deux projets dans un seul et même cadre, qui inclut :

  • Des API
  • SDKs
  • Options d'instrumentation
  • Un service de collecte

OpenTelemetry est né de la fusion entre OpenTracing et OpenCensus, avec pour ambition de créer une norme mondiale, unique et ouverte, pour l’observabilité.

Avec OpenTelemetry, les développeurs n'ont plus à choisir entre OpenTracing et OpenCensus. OpenTelemetry fournit un ensemble unifié de bibliothèques, d'API, d'agents et de services de collecteur pour la collecte et le transfert des données.


Fonctionnement d’OpenTelemetry

OpenTelemetry fournit un pipeline standardisé pour la collecte des données de télémétrie, que vous pouvez ensuite envoyer vers le backend d’observabilité de votre choix. Conçu pour être indépendant des fournisseurs et extensible.

  • APIs : interfaces spécifiques à chaque langage, pour générer les données de télémétrie
  • SDKs : implémentent les API et prennent en charge le traitement, le regroupement (batching) et l’export des données
  • Instrumentation :peut être automatique (sans modification du code) ou manuelle (métriques/événements personnalisés)
  • Exporters : envoient les données traitées vers une ou plusieurs destinations via des protocoles standards comme OTLP

Les API OpenTelemetry spécifiques au langage coordonnent la collecte de données télémétriques dans votre système et instrumentent votre code. Les SDK OpenTelemetry implémentent et prennent en charge les API via des bibliothèques qui facilitent la collecte, le traitement et l'exportation des données. OpenTelemetry fournit également une instrumentation automatique des services et prend en charge l'instrumentation personnalisée. Vous pouvez exporter vos données télémétriques à l'aide d'un exportateur fourni par le fournisseur ou du protocole OpenTelemetry (OTLP).


Principaux composants d'OpenTelemetry

Voici les principaux composants d'OpenTelemetry :

ComposantFinalitéExemple d’utilisation
CollecteurRéception, traitement et export des données de télémétrie dans plusieurs formats ; solution indépendante des fournisseursAgrégation des logs, métriques et traces depuis des clusters Kubernetes avant envoi vers Elastic
SDK de langageImplémente l’API OpenTelemetry pour un langage de programmation donnéUtiliser le SDK Python pour instrumenter une application écrite en Python
Bibliothèques d'instrumentationInstrumentation automatique des frameworks et bibliothèques les plus utilisés pour générer des données de télémétrieCollecte automatique des métriques des requêtes HTTP avec Spring Boot
Instrumentation automatiqueAjoute des capacités de télémétrie sans modification du codeInjection d’un agent Java pour superviser les microservices basés sur la JVM
ExportateursEnvoi des données collectées vers un ou plusieurs backends d’observabilitéExport des traces vers Jaeger et des métriques vers Prometheus

 

Ces composants permettent une collecte de données flexible et standardisée, indépendante du backend choisi.

Notre guide d’installation du collecteur OpenTelemetry dans la documentation Elastic inclut un tutoriel complet.


Avantages d'OpenTelemetry

Les avantages d'OpenTelemetry sont la normalisation des données et une flexibilité durable qui se traduisent par une meilleure observabilité, une efficacité accrue et des coûts réduits.

  1. Standardisation
    1. Utilisez une méthode unique de collecte pour plusieurs backends : Elastic, Splunk, Datadog, etc.
    2. Réduisez la complexité des pipelines avec un framework extensible unifié pour les logs, métriques et traces.
  2. Neutralité du fournisseur
    1. Changez de backend sans avoir à réinstrumenter vos applications.
    2. Adoptez facilement de nouveaux outils d’observabilité sans tout reconstruire.
    3. Conservez de la flexibilité à mesure que votre stack technologique évolue.
  3. Données cohérentes
    1. Simplifiez le traitement et l’analyse des données grâce à un schéma commun unifié.
    2. Exécutez des analyses, des requêtes, du machine learning, et bien plus encore, à partir de données issues de différentes sources.

Grâce à OpenTelemetry, vous bénéficiez d'une scalabilité pour la croissance, d'une compatibilité entre les plateformes et d'une intégration facile à vos outils de monitoring et d'observabilité existants.


Intégration d'OpenTelemetry et d'Elastic

En tant que partisan de longue date des standards ouverts, Elastic s'engage à promouvoir l'adoption d'OpenTelemetry dans l'ensemble du secteur par le biais d'une contribution et d'une collaboration actives.

Elastic Observability s’intègre de manière transparente aux données OpenTelemetry, en y ajoutant la puissance de la recherche, de l’analytique, du machine learning et de la visualisation à grande échelle. En 2023, Elastic a contribué à ECS pour OpenTelemetry, afin d’unifier les formats de données de télémétrie.

Elastic Distributions of OpenTelemetry (EDOT) fournit aux ingénieurs SRE et aux développeurs un écosystème OTel stable. Grâce à l’approche OTel-first d’Elastic, qui respecte les conventions OpenTelemetry d’origine, aucune conversion de schéma n’est nécessaire. EDOT inclut aussi des correctifs au-delà des cycles de publication d'OTel et un support technique professionnel sans modules complémentaires propriétaires.

Découvrez les solutions OTel-first d’Elastic


Cas d'utilisation de l'observabilité CI/CD avec OpenTelemetry et Elastic

Elastic fonctionne avec les principales plateformes CI/CD (Jenkins, Ansible, Maven) pour instrumenter les pipelines via OpenTelemetry.

Cela permet notamment :

  • Visibilité de bout en bout du pipeline
  • Tableaux de bord de supervision en temps réel
  • Détection automatisée des alertes et des anomalies
  • Dépannage accéléré des erreurs de compilation ou de test

Vous trouverez les instructions pour utiliser OpenTelemetry avec la supervision CI/CD Elastic dans notre documentation officielle.


Questions fréquentes sur OpenTelemetry

OpenTelemetry est-il une norme ?

Oui, OpenTelemetry est un projet open source et une norme unifiée pour les logs, les traces et les métriques.

Peut-on avoir des exemples de données télémétriques ?

Des exemples de données télémétriques incluent les logs, les indicateurs et les traces utilisés dans le monitoring et l'observabilité du système.

Quelle est la différence entre OpenTelemetry et Jaeger ?

OpenTelemetry vous permet de traiter et d'exporter des données vers différents back-ends open source et commerciaux, mais ce n'est pas un back-end d'observabilité comme Jaeger. OpenTelemetry fournit un ensemble d'API, de SDK et d'outils pour aider à générer et gérer des données télémétriques alors que Jaeger est un outil de traçage distribué open source. Les équipes informatiques utilisent Jaeger pour monitorer et dépanner les applications basées sur une architecture de microservices. Jaeger ne prend pas en charge les logs et les indicateurs.

Quelle est la différence entre l'API et le SDK OpenTelemetry ?

Les API OpenTelemetry, ou interfaces de programmation, coordonnent la collecte des données de télémétrie dans l’ensemble de votre système et instrumentent votre code. Étant donné que les API sont propres à chaque langage, elles doivent correspondre au langage utilisé dans votre code. Les SDK OpenTelemetry, ou kits de développement logiciel, implémentent les API et fournissent des bibliothèques pour collecter, traiter et exporter les données vers un backend d’observabilité.

Qui a développé OpenTelemetry et pourquoi ?

OpenTelemetry a été développé sous l’égide de la Cloud Native Computing Foundation (CNCF), pour standardiser la collecte et l’export des données de télémétrie. Il est issu de la fusion des projets OpenTracing et OpenCensus, dans le but d’éliminer la fragmentation.

Qu'est-ce que le protocole OpenTelemetry (OTLP) et pourquoi est-il important ?

OTLP est le protocole par défaut d’OpenTelemetry. C’est un protocole neutre vis-à-vis des fournisseurs, utilisé pour envoyer des données de télémétrie entre les composants et les backends. Il garantit que toutes les données — logs, métriques et traces — sont transmises dans un format cohérent, ce qui facilite l’intégration entre les outils et améliore la fiabilité globale.

Qu’est-ce que le Collector OpenTelemetry ?

Le collecteur OpenTelemetry est un service neutre qui reçoit les données de télémétrie depuis plusieurs sources, les traite (filtrage, agrégation, transformation) et les exporte vers un ou plusieurs backends. Il prend en charge plusieurs protocoles et formats au sein d’un même déploiement.

Comment OpenTelemetry s'intègre-t-il à Elastic ?

Vous pouvez envoyer vos traces, logs et métriques OTel-native vers Elastic depuis n’importe quel outil OTel tiers, ou via vos propres collecteurs OTel avec des processeurs et exporteurs personnalisés,pour les analyser et les visualiser dans Elastic. Elastic ingère nativement les données OTLP issues d’OpenTelemetry, et offre des fonctionnalités avancées telles que : la recherche à grande échelle, la visualisation interactive, la supervision en temps réel, la détection d’anomalies basée sur le machine learning. Aucune conversion de schéma n’est nécessaire.


Ressources OpenTelemetry d'Elastic