Les 3 niveaux d'architecture OpenTelemetry

Introduction #

OpenTelemetry (OTel) n'est pas un outil unique, mais un framework complet conçu pour standardiser la manière dont nous collectons les données de télémétrie. Son architecture repose sur une séparation claire des responsabilités entre la génération de la donnée, son transport et son stockage.

1. Le niveau Applicatif : Instrumentation et SDKs #

C'est ici que les signaux (Traces, Métriques, Logs, Profiles) sont créés.

Génération de la donnée #

Les applications utilisent des SDKs OpenTelemetry pour capturer des informations sur leur exécution. Cette étape peut se faire de deux façons :

• L'instrumentation automatique : Elle repose sur l'utilisation d'un agent (Java, Python, .NET, ...) ou d'un wrapper qui s'injecte au démarrage de l'application. Elle permet de collecter des signaux standards (comme les requêtes HTTP ou les appels en base de données) sans aucune modification du code source.
• L'instrumentation manuelle : Elle nécessite l'utilisation explicite de l'API OTel au sein du code source. Cette méthode permet aux développeurs de définir précisément ce qu'ils souhaitent observer, en ajoutant par exemple des attributs métier personnalisés ou des spans spécifiques à leur logique applicative.

Une fois capturées, les données sont transformées en objets internes puis exportées vers le niveau suivant, généralement en utilisant le protocole OTLP (OpenTelemetry Protocol).

2. Le niveau Collecteur : Le cerveau du pipeline #

Le composant central qui reçoit, transforme et route les données.

Les composants internes du Collecteur #

Le collecteur est constitué de quatre éléments clés qui forment ses pipelines :

• Receivers : Ils définissent comment les données entrent (en mode Push ou Pull).

  receivers:
    otlp:
      protocols:
        grpc:
          endpoint: 0.0.0.0:4317

• Processors : Ils manipulent les données (batching, filtrage, anonymisation) avant l'exportation.

  processors:
    batch:
      send_batch_size: 1000
      timeout: 10s

• Exporters : Ils définissent où envoyer les données transformées vers les backends de stockage.

  exporters:
    otlp:
      endpoint: "my-backend:4317"
      tls:
        insecure: true

• Extensions : Contrairement aux autres, elles n'interviennent pas sur les données de télémétrie mais sur le fonctionnement du collecteur (ex: santé, authentification).

  extensions:
    health_check:
      endpoint: 0.0.0.0:13133

Le concept de Pipelines #

Un pipeline est un graphe orienté reliant des Receivers à des Exporters en passant par des Processors. OTel permet de définir des pipelines distincts pour chaque type de signal (traces, metrics, logs), tout en partageant les mêmes receivers.

3. Le niveau Backend : Stockage et Analyse #

L'étape finale où les données deviennent exploitables.

Neutralité vis-à-vis des fournisseurs #

Grâce à l'architecture en couches d'OpenTelemetry, le choix du backend est totalement agnostique. Vous pouvez router vos données vers des solutions Open Source (Prometheus, Tempo, Loki, Jaeger) ou des solutions commerciales (Dynatrace, New Relic, Datadog) sans jamais modifier le code de votre application.

Le Protocole OTLP : Le langage commun #

La colle qui lie les trois niveaux.

Standardisation du transport #

L'OTLP (OpenTelemetry Protocol) est un protocole de transport universel basé sur gRPC ou HTTP. Il garantit que les métadonnées et le contexte (comme la propagation de traces) restent intacts tout au long de la chaîne. Pour approfondir les différences de transport, consultez notre article sur OTLP gRPC vs HTTP.

Conclusion #

Adopter cette architecture en trois niveaux permet une flexibilité maximale : vous pouvez faire évoluer vos backends ou vos règles de transformation dans le collecteur sans impacter vos développeurs ou vos applications en production.

Schéma d'architecture globale #