OpenTelemetry (OTel) est un framework open source, neutre vis-à-vis des fournisseurs, pour générer, collecter et exporter de la télémétrie : traces, métriques et logs. Il définit le modèle de données, le protocole de transport (OTLP), les SDK utilisés par les applications et le Collector qui reçoit et achemine les données. Comme il n’a pas de backend propre, vous pouvez envoyer les mêmes données vers Grafana, Prometheus, Jaeger ou un fournisseur commercial, et en changer plus tard sans ré-instrumenter votre code.

Presque tout dans OpenTelemetry se configure avec du texte : un fichier YAML pour le Collector, des variables d’environnement pour les SDK et, de plus en plus, un fichier YAML déclaratif pour les SDK également. Cette série se concentre là-dessus, afin que votre configuration de télémétrie soit relue, versionnée et reproductible comme le reste de votre infrastructure.

Comment ça marche

Les applications sont instrumentées avec un SDK OpenTelemetry (ou un agent sans code qui en injecte un). Le SDK crée des spans, des métriques et des enregistrements de logs, et les exporte via OTLP, généralement vers un Collector. Le Collector reçoit les données, les traite (regroupement en lots, enrichissement, filtrage, échantillonnage) et les exporte vers un ou plusieurs backends.

App + SDK ──OTLP──▶ Collector (receivers → processors → exporters) ──▶ Backends

Concepts clés

• Signaux — traces, métriques et logs. Les profils émergent comme quatrième signal.
• SDK et API — l’API est ce que l’instrumentation appelle, et le SDK est l’implémentation qui échantillonne, regroupe en lots et exporte.
• OTLP — le protocole OpenTelemetry, via gRPC (port 4317) ou HTTP (port 4318).
• Collector — un binaire autonome construit à partir de receivers, processors, exporters, connectors et extensions, reliés entre eux dans service.pipelines.
• Resource — des attributs décrivant l’entité qui produit la télémétrie, comme service.name et deployment.environment.name.
• Conventions sémantiques — des noms d’attributs standard pour que les données issues de différents langages et bibliothèques se ressemblent.
• Échantillonnage — décider quelles traces conserver, dans le SDK (head sampling) ou dans le Collector (tail sampling).
• Instrumentation — code manuel, bibliothèques ou agents sans code qui créent la télémétrie.

Pourquoi les équipes adoptent OpenTelemetry

• Pas de verrouillage. Changez de backend en modifiant la configuration du Collector, pas le code applicatif.
• Un seul pipeline pour tout. Le même Collector gère les traces, métriques et logs de tous les langages.
• Contrôle en périphérie. Filtrez, expurgez, échantillonnez et routez les données avant qu’elles ne quittent votre réseau.
• Nommage cohérent. Les conventions sémantiques rendent les tableaux de bord et les alertes portables.
• Configuration en tant que code. Le YAML du Collector et les variables d’environnement des SDK s’intègrent aux outils GitOps comme Flux et Argo CD.

Pour commencer

Exécutez un Collector avec un petit fichier de configuration, faites pointer une application vers lui à l’aide de quelques variables d’environnement OTEL_*, et observez les données dans l’exporter debug du Collector. Les guides ci-dessous vous mènent de là à l’instrumentation sans code, à l’échantillonnage, à Kubernetes et au durcissement pour la production. Ils ont été rédigés pour des releases récentes du Collector (la série 0.16x) et le schéma de configuration déclarative stable ; consultez la documentation OpenTelemetry pour les versions que vous installez, car la stabilité des composants du Collector varie.