Architecture OpenTelemetry : Comprendre les 3 niveaux

Publié le : 15/06/2024 à 09:00 Mis à jour le : 13/06/2026 à 13:08 Vues : 522

Plongée au cœur de l'architecture OpenTelemetry. Apprenez comment les données circulent de l'application au backend via le collecteur et le protocole OTLP.

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.

Le saviez-vous ?