OpenTelemetry.adoc

Présentation d’OpenTelemetry

Table of Contents

• Présentation générale de la solution et objectifs
• Principaux avantages d’OpenTelemetry
• Architecture d’OpenTelemetry
• Utilisation d’OpenTelemetry sur Azure (A CREUSER)

Présentation générale de la solution et objectifs

• Projet opensource dont l’objectif est de fournir une solution unifiée pour la collecte et l'exportation de données d’observabilité / télémétrie (métriques, logs, traces) pour tout type d’application (on-premises ou Cloud)

• Il offre une API unifiée, implémentée par différents SDK (pour Java, Python, Go, etc.), permettant d’instrumenter les applications de manière standardisée, quelle que soit la technologie utilisée.

• Si l’on souhaite éviter une modification du code source, des agents OpenTelemetry peuvent être installés afin de collecter les données de télémétrie.

• Des collectors OpenTelemetry existent également pour recevoir les données de télémétrie envoyées par les agents et / ou applications utilisant les SDKs.

Example 1. Observabilité et télémétrie

• Observabilité : L’observabilité est la capacité à déduire le fonctionnement interne d’un système à partir de ses sorties externes.

• Télémétrie : Le processus automatisé de collecte et de transmission de données à partir de sources distantes vers un emplacement central à des fins d’analyse et de surveillance.

💡	OpenTelemetry ou "OTel" de son petit nom 😉

Principaux avantages d’OpenTelemetry

• Unification des données : OpenTelemetry permet de collecter différents types de données de télémétrie (métriques, logs, traces) dans un format standardisé, facilitant ainsi l’analyse et la corrélation.

• Vendor-neutral : Les données collectées par OpenTelemetry peuvent être exportées vers différents backends d’observabilité (Splunk, New Relic, Dynatrace, etc.), offrant une grande flexibilité.

• Communauté active : OpenTelemetry est un projet très populaire qui est en train de devenir un standard en matière d’observabilité.
  De nombreux éditeurs ont développé des connecteurs pour aller récupérer les données récupérées par les connectors OpenTelemetry.

Architecture d’OpenTelemetry

Les principaux composants de la plateforme OpenTelemetry :

• Agent (on parlera aussi d'auto-instrumentation ou de Zero-code) : Collecte automatiquement les données au niveau de l’application, sans besoin de modifier le code source de l’application

  • Son rôle principal est d’instrumenter l’application et d’envoyer les données de télémétrie à un point de collecte, généralement un collector.

  • Pour un exemple d’agent, voici celui de Java : https://github.com/open-telemetry/opentelemetry-java-instrumentation
    "This project provides a Java agent JAR that can be attached to any Java 8+ application and dynamically injects bytecode to capture telemetry from a number of popular libraries and frameworks"

    • Voir également https://opentelemetry.io/docs/languages/java/intro/

  • Pour plus de détails sur ce type d’instrumentation, voir la doc officielle d’OpenTelemetry : https://opentelemetry.io/docs/concepts/instrumentation/zero-code/

    • "Zero-code instrumentation adds the OpenTelemetry API and SDK capabilities to your application typically as an agent or agent-like installation. The specific mechanisms involved may differ by language, ranging from bytecode manipulation, monkey patching, or eBPF to inject calls to the OpenTelemetry API and SDK into your application.
      Typically, zero-code instrumentation adds instrumentation for the libraries you’re using. This means that requests and responses, database calls, message queue calls, and so forth are what are instrumented. Your application’s code, however, is not typically instrumented. To instrument your code, you’ll need to use code-based instrumentation."

• Collector : Reçoit, traite et exporte les données

  • Il est le point central de collecte des données de télémétrie. Il reçoit les données des agents et peut les exporter vers différents backends.

  • un collector est composé lui-même de 3 composants :

    • Receiver : point d’entrée des données de télémétrie dans le Collector.
      Il reçoit les données provenant des différents agents ou sources et les met dans un format standard.

    • Processor : traite les données reçues par le receiver. Il peut les filtrer, les agréger, les transformer, etc., avant de les envoyer à l’exporter.

    • Exporter : envoie les données traitées par le processor vers un backend spécifique (Jaeger, Prometheus, Azure Monitor, etc.).
      L’exporter est spécialisé dans un type de backend particulier et connaît les protocoles et les formats de données spécifiques à ce backend.
      

• SDK : Fournit une interface pour instrumenter l’application

• API : Définit les concepts et les opérations communs

• OTLP (OpenTelemetry Protocol) : Protocole de communication pour les données de télémétrie

  • Ce protocole est en train de devenir un standard dans l’IT.

En parallèle de ces composants, les connecteurs ("connector") développés par d’autres éditeurs sont des outils servant de pont entre OpenTelemetry et un système tiers (un outil de monitoring, une base de données, une plateforme cloud, etc.).
Ces connecteurs permet soit :

• d'importer des données depuis ce système tiers dans OpenTelemetry

• ou inversement, d'exporter les données collectées par OpenTelemetry dans ce système

Quelques exemples de connecteurs pour OpenTelemetry :

• Connecteur vers des outils de monitoring : Prometheus, Grafana, Jaeger

  • Le connecteur pour Grafana permet d’envoyer les traces et les métriques OpenTelemetry vers Grafana pour créer des tableaux de bord personnalisés et des visualisations riches.

• Connecteur vers des BDD : Elasticsearch, TimescaleDB (une BDD time-series)

• Connecteurs vers des plateformes cloud : Azure Monitor, AWS CloudWatch, Google Cloud Monitoring

  • Le connecteur pour Azure Monitor permet d’exporter les données OpenTelemetry vers Azure Monitor pour bénéficier des fonctionnalités d’observabilité de la plateforme Azure, telles que l’analyse de logs et la création d’alertes.

❗

Export direct Souvent le workflow OpenTelemetry impliquant un connecteur est le suivant : Application instrumentée → Collector OpenTelemetry → Connecteur pour système tiers → Système tiers (ex : Azure Monitor) → MAIS l’usage d’un collector n’est PAS obligatoire, il est possible d’envoyer directement les données de télémétrie depuis votre applications instrumentée vers votre système tiers : c’est l'export direct. Quand privilégier l’export direct ? Simplicité : Si vous avez besoin d’une solution simple et rapide pour envoyer des données à système tiers, l’export direct peut être suffisant. A l’inverse, passer par un collector vous offre une plus grande flexibilité dans le traitement des données. Vous pouvez les filtrer, les agréger, les transformer avant de les envoyer à d’autres backends (comme Azure Monitor) Petits volumes de données : Pour de petits volumes de données, l’overhead d’un collector peut ne pas être justifié. A l’inverse, le collector peut gérer de grands volumes de données et s’adapter à l’évolution de votre infrastructure. En résumé: Export direct : Plus simple à mettre en place, mais moins flexible. Collector : Plus flexible, mais nécessite une configuration supplémentaire.

📎

Différence entre un connector et l’exporter d’un collector Les 2 composants peuvent sembler être identiques, ou avoir des finalités identiques, mais : L'exporter est un composant spécialisé dans l’envoi de données vers un backend spécifique (uniquement l’envoi) Le connector peut lui gérer aussi bien l’envoi que la réception de données Pour plus de détails, voir https://opentelemetry.io/docs/collector/building/connector/

Utilisation d’OpenTelemetry sur Azure (A CREUSER)

Plutôt que d’instrumenter directement le code de son application à l’aide d’un SDK OpenTelemetry, il est recommandé dans le cas d’Azure d'utiliser un agent OpenTelemetry.

Raison de préférer un agent pour Azure :

• Simplicité : L’agent est préconfiguré pour fonctionner avec Azure Monitor, pas besoin de gérer les détails de la configuration.

• Automatisation : L’agent collecte les données de manière automatique, pas besoin de modifier son code.

• Maintenance : Azure gère la mise à jour et la maintenance de l’agent, vous n’avez pas à vous en soucier.

• Intégration : L’agent est étroitement intégré avec Azure Monitor, la visualisation et l’analyse des données en sont améliorées

→ Pour plus d’informations, voir https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-enable?tabs=python