OpenTelemetry

Fiche express
Type	Standard et outillage unifiés d'instrumentation (traces, métriques, logs)
Éditeur	Projet CNCF (fusion OpenTracing + OpenCensus)
Licence	Open source (Apache 2.0)
Protocole d'export	OTLP (OpenTelemetry Protocol)
Composants	API/SDK par langage · Collector
Voir aussi	Prometheus · Grafana

OpenTelemetry (souvent abrégé OTel) est un standard ouvert et un ensemble d'outils visant à unifier la façon dont une application est instrumentée pour produire de la télémétrie : traces distribuées, métriques et logs, les trois piliers habituellement cités de l'observabilité. Son objectif central est de découpler l'instrumentation du code applicatif du choix du backend de stockage/visualisation : une application instrumentée avec OpenTelemetry peut exporter sa télémétrie vers Prometheus, Jaeger, un backend commercial ou plusieurs à la fois, sans changer une ligne de code d'instrumentation.

Historique : d'OpenTracing et OpenCensus à OpenTelemetry

Avant OpenTelemetry coexistaient deux initiatives concurrentes et partiellement redondantes :

• OpenTracing — spécification neutre côté fournisseur pour le traçage distribué,

 portée par la CNCF.

• OpenCensus — bibliothèque initiée par Google, couvrant à la fois traces et métriques,

 avec sa propre implémentation plutôt qu'une simple spécification.

Les deux projets ont fusionné en 2019 (à vérifier) pour donner naissance à OpenTelemetry, qui en reprend les concepts tout en les étendant à un troisième pilier, les logs. OpenTracing et OpenCensus sont depuis considérés comme obsolètes au profit d'OpenTelemetry, qui fournit des couches de compatibilité pour migrer progressivement une instrumentation existante plutôt que de devoir tout réécrire d'un coup.

API vs SDK

OpenTelemetry distingue explicitement deux couches, disponibles pour la plupart des langages courants (Java, Go, Python, JavaScript/Node.js, .NET...) :

• API — les interfaces qu'une bibliothèque tierce ou un développeur utilisent pour

 instrumenter du code (créer un span, enregistrer une métrique), sans dépendance sur une
 implémentation particulière.

• SDK — l'implémentation concrète de cette API côté application : configuration des

 exporters, des processeurs, de l'échantillonnage. Une bibliothèque tierce peut ainsi
 embarquer uniquement l'API (légère, sans effet si l'application hôte n'a pas activé de SDK),
 laissant à l'application finale le choix du SDK et de sa configuration.

De nombreuses bibliothèques et frameworks courants fournissent une instrumentation automatique (auto-instrumentation) qui génère des traces/métriques sans modification du code applicatif (interception des appels HTTP sortants, des requêtes SQL...), en complément de l'instrumentation manuelle pour les portions de code métier spécifiques.

Le Collector

Le OpenTelemetry Collector est un composant autonome (binaire indépendant du langage de l'application) qui reçoit, transforme et réexporte de la télémétrie, organisé en pipeline à trois étages :

<mermaid> flowchart LR

   subgraph Receivers
     R1[OTLP]
     R2[Prometheus scrape]
     R3[Jaeger / Zipkin]
   end
   subgraph Processors
     P1[batch]
     P2[filter / attributes]
     P3[memory_limiter]
   end
   subgraph Exporters
     E1[Prometheus remote_write]
     E2[Jaeger / Tempo]
     E3[Backend logs]
   end
   Receivers --> Processors --> Exporters

</mermaid>

• Receivers — points d'entrée acceptant de la télémétrie dans un format donné (OTLP

 natif, mais aussi Jaeger, Zipkin, ou un scrape au format Prometheus pour interopérer avec de
 la télémétrie non native OTel).

• Processors — transformations appliquées en pipeline : mise en lot (batch),

 filtrage, enrichissement d'attributs, protection contre la saturation mémoire
 (memory_limiter).

• Exporters — réexpédition vers un ou plusieurs backends : Prometheus (métriques, via

 remote_write ou exposition d'un endpoint de scrape), un backend de traces comme
 Jaeger ou Grafana Tempo, ou tout backend compatible OTLP.

Déployé en frontal des applications, le Collector centralise ainsi la configuration d'export (URL de backend, identifiants, échantillonnage) hors du code applicatif : les applications n'exportent qu'en OTLP vers le Collector, qui seul sait où et comment router la télémétrie vers les backends réels.

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:
  memory_limiter:
    limit_mib: 512

exporters:
  prometheusremotewrite:
    endpoint: "http://prometheus:9090/api/v1/write"
  otlp/tempo:
    endpoint: "tempo:4317"
    tls:
      insecure: true

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [prometheusremotewrite]
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/tempo]

OTLP

OTLP (OpenTelemetry Protocol) est le protocole natif d'échange de télémétrie d'OpenTelemetry, défini sur gRPC et sur HTTP/protobuf. C'est le format que les SDK produisent par défaut et que le Collector accepte nativement en entrée ; les autres formats (Prometheus, Jaeger, Zipkin...) sont gérés via des receivers/exporters dédiés plutôt que nativement.

Positionnement : un standard d'instrumentation, pas un backend

Point important à retenir : OpenTelemetry ne stocke ni ne visualise rien par lui-même. C'est un standard d'instrumentation et un outil de transport/transformation (le Collector) ; le stockage et la visualisation restent délégués à des backends spécialisés :

• Métriques — typiquement exportées vers Prometheus (ou un backend compatible

 remote_write), puis visualisées dans Grafana.

• Traces — exportées vers un backend de traces distribuées comme Jaeger ou Grafana Tempo

 (non couverts en détail sur ce wiki à ce stade).

• Logs — pilier le plus récemment stabilisé côté OpenTelemetry (à vérifier selon la

 maturité au moment de la lecture) ; peuvent être exportés vers un backend de logs tel que
 Loki, en complément ou en remplacement d'une chaîne syslog traditionnelle.

Cette neutralité vis-à-vis du backend est l'argument central d'adoption d'OpenTelemetry : elle évite un couplage fort (vendor lock-in) entre le code instrumenté et l'outil de visualisation, contrairement aux SDK propriétaires fournis historiquement par certains éditeurs de solutions d'observabilité commerciales.

Voir aussi

• Prometheus — backend de métriques le plus courant en sortie d'un pipeline OpenTelemetry
• Grafana — visualisation des métriques (et, via Tempo/Loki, des traces et logs) collectées

 in fine via OpenTelemetry