OpenTelemetry : instrumenter une fois, choisir librement le backend
L'observabilité dévore le budget et lie à un fournisseur. OpenTelemetry découplé l'instrumentation du backend : mesurer une fois, choisir librement…
Pendant trois ans, chaque trace passait par l’agent d’un seul fournisseur, pratique mais coûteux. Puis la facture a augmenté, l’équipe a voulu passer à un autre backend et a constaté : chaque span est lié au SDK du fabricant. Qui veut changer d’observabilité la reconstruit. C’est précisément cette impasse qu’OpenTelemetry résout en séparant la mesure de l’évaluation.
Les points clés en bref
- L’instrumentation et le backend sont découplés : Qui mesure une fois avec OpenTelemetry peut échanger l’outil d’évaluation plus tard librement, de Jaeger à Prometheus et Grafana jusqu’à Datadog. Le code reste identique, l’objectif change via la configuration.
- Standard de facto largement adopté : OpenTelemetry est un projet gradué de la Cloud Native Computing Foundation et l’un des plus actifs après Kubernetes. Les grands fournisseurs d’observabilité supportent désormais le protocole.
- Le démarrage rapide a un revers : L’auto-instrumentation fonctionne en quelques minutes, le véritable travail commence avec le collecteur, l’échantillonnage et la question de savoir quelles données conserver.
Lié :OpenTofu vs. Terraform : quel outil IaC est vraiment adapté / Coolify en test : Self-Hosting au lieu de Vercel et Heroku
Pourquoi la facture d’observabilité devient parfois une prise d’otage
Le modèle se répète dans presque chaque pile que j’ai vue de l’intérieur ces dernières années. Au début, il y a un agent. On l’installe, quelques lignes de configuration, et soudain les traces, les métriques et les logs apparaissent dans un beau tableau de bord. Le fournisseur le rend délibérément facile, car chaque service instrumenté est un service qui ne quittera pas son backend de si tôt.
La friction survient plus tard. Le volume de données augmente plus vite que prévu, la facture suit le volume, et finalement, la question se pose de savoir si un autre outil n’est pas moins cher ou simplement meilleur. Alors seulement, on voit à quel point l’obstacle est profond. Les spans portent les noms de classe du SDK du fournisseur, les métriques suivent son schéma de nommage, la logique d’échantillonnage est intégrée dans son agent. Changer n’est pas un travail de configuration, mais une refactorisation à travers la base de code.
Ce n’est pas une critique envers un fabricant particulier. C’est la conséquence logique lorsque la mesure et l’évaluation sont intégrées dans le même package propriétaire. OpenTelemetry établit précisément ici la ligne de démarcation.
Ce que fait OpenTelemetry quand on laisse de côté les diapositives
Qu’est-ce qu’OpenTelemetry ? OpenTelemetry est une norme ouverte pour la génération et le transport de données de télémétrie dans les systèmes distribués. Il définit des interfaces et des bibliothèques neutres vis-à-vis des fournisseurs pour les trois types de signaux stables que sont les traces, les métriques et les journaux, ainsi qu’un protocole unifié appelé OTLP, via lequel ces données sont envoyées à n’importe quel backend.
L’essentiel pratique est cette découplage. L’instrumentation vit dans le code et dans la norme, pas dans l’agent d’un fournisseur. Une étendue est appelée comme l’équipe la nomme, et non comme un SDK le prescrit. Où les données finissent par aller, c’est une ligne de configuration qui le décide, pas une modification de code.
Le projet est né de la fusion de deux approches plus anciennes, OpenTracing et OpenCensus, qui ont résolu le même problème pendant des années. Aujourd’hui, OpenTelemetry est un projet diplômé de la Cloud Native Computing Foundation et, après Kubernetes, le projet avec la deuxième activité la plus élevée. Même les fournisseurs commerciaux, dont le verrouillage est brisé par la norme, acceptent aujourd’hui directement OTLP. L’instrumentation neutre vis-à-vis des fournisseurs est ainsi devenue la norme.
Auto ou Manuel : où le démarrage rapide trouve ses limites
Il existe deux façons de pénétrer dans OpenTelemetry, et toutes deux ont leur justification. L’instrumentation automatique s’accroche via un agent ou une bibliothèque à des frameworks et des pilotes courants et fournit sans modification de code des traces pour les appels HTTP, les accès à la base de données et les file d’attente de messages. C’est la voie par laquelle on obtient une première image de trace pendant une pause déjeuner.
L’instrumentation manuelle demande plus de travail, mais fournit le contexte qui compte vraiment. Un appel comme tracer.start_as_current_span(…) marque exactement le processus commercial qui intéresse en cas d’incident, à savoir le paiement, la vérification des risques, l’exécution par lots. Auto dit que la base de données était lente. Manuel dit que la base de données était lente pendant que la troisième tentative de libération de paiement avait lieu. C’est la différence entre un chiffre et une explication.
| Instrumentation automatique | Instrumentation manuelle |
|---|---|
| Productif en quelques minutes, pas de modification de code | Effort par service, mais contexte ciblé |
| Couvre les frameworks et les pilotes, pas la logique métier elle-même | Représente exactement les processus commerciaux qui comptent en cas d’incident |
| Bien pour la première vue d’ensemble et pour les piles standard | Obligatoire dès que les traces doivent prendre des décisions |
Dans la pratique, on combine les deux. Instrumentation automatique comme bruit de fond, spans manuels là où il y a de l’argent, du risque ou de la frustration client. Si on construit tout manuellement, on ne finit jamais. Si on laisse tout à l’agent, on a finalement beaucoup de données et peu de réponses.
Le Collector est la partie que la plupart des gens sous-estiment
Les bibliothèques reçoivent l’attention, mais le OpenTelemetry Collector fait le véritable travail. Il s’agit d’un processus autonome qui reçoit les données de télémétrie des services, les traite et les transmet à un ou plusieurs backends. C’est précisément ce composant qui fait de la théorie de l’interchangeabilité une réalité opérationnelle, car c’est ici que le routage des données se produit, et non dans le code de l’application.
otlp:
protocols:
grpc:
processors:
batch:
exporters:
prometheus:
otlp/tempo:
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp/tempo]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [prometheus]
Cette configuration concise montre le principe. Un récepteur reçoit les données OTLP, un processeur de lot les regroupe, et deux pipelines distincts envoient les traces et les métriques à des destinations différentes. Si l’équipe veut changer le backend de trace demain, il suffit de modifier une ligne d’exportateur, aucun service n’a besoin d’être redéployé.
La friction se cache dans l’échantillonnage. Avec un volume modéré, on peut tout conserver, mais avec un trafic important, cela devient rapidement coûteux et peu lisible. L’échantillonnage basé sur la queue, c’est-à-dire la décision prise après la fin d’une trace, conserve spécifiquement les opérations lentes et erronées et supprime les cas de succès uniformes. C’est puissant, mais cela coûte de la mémoire dans le Collector et quelques itérations jusqu’à ce que les règles soient bien établies. J’ai moi-même souvent pris cette discipline trop tard, à mon grand regret.
Ce que le changement apporte, et où il ne sauve rien
Le gain concret de OpenTelemetry est la liberté d’options. L’instrumentation devient un investissement durable au lieu d’un pari sur un fournisseur. Les backends peuvent être comparés, combinés ou modifiés sans que le code ne soit rouvert à chaque fois. Pour les équipes qui ont des difficultés avec leurs coûts de télémétrie ou avec la dépendance à un outil, c’est le levier décisif.
OpenTelemetry n’est pas un produit d’observabilité prêt à l’emploi. Le standard génère et transporte des données, mais ne stocke, ne visualise ni n’alerte pas. Le backend reste une décision propre avec ses propres coûts, qu’il soit exploité en interne avec Grafana et Prometheus ou comme service acheté. Et le Collector est une infrastructure qui doit être exploitée, mise à l’échelle et surveillée. Une observabilité qui veut être observée elle-même.
Pour une petite équipe avec un monolithe gérable et un outil qui convient, la migration immédiate n’est pas une fin en soi. OpenTelemetry ne devient vraiment rentable que lorsque plusieurs services, plusieurs langages ou une frustration réelle avec les coûts et le verrouillage sont réunis. À ce stade, la question n’est plus de savoir si l’on change, mais seulement à quelle vitesse l’ancienne instrumentation expire.
Foire aux questions
En quoi OpenTelemetry diffère-t-il d’un outil comme Datadog ?
OpenTelemetry est la norme neutre des fournisseurs pour générer et transporter des données de télémétrie, ce n’est pas un outil d’évaluation prêt à l’emploi. Datadog et des fournisseurs similaires fournissent le backend avec stockage, tableaux de bord et alerte. Les deux fonctionnent ensemble : on instrumente avec OpenTelemetry et on envoie les données au backend de son choix, qui peut être remplacé plus tard sans modification de code.
Dois-je réinstrumenter complètement mon code ?
Non. Grâce à l’auto-instrumentation, les frameworks courants, les clients HTTP et les pilotes de base de données obtiennent des traces immédiatement sans modification de code. On ajoute manuellement des spans uniquement là où le contexte métier est important. La démarche habituelle consiste à commencer avec l’auto-instrumentation et à approfondir manuellement étape par étape.
Ai-je vraiment besoin du collecteur OpenTelemetry ?
Pour les petites configurations, on peut envoyer des données directement des services à un backend. Dès que l’échantillonnage, plusieurs objectifs ou le traitement centralisé entrent en jeu, le collecteur devient le point central. C’est l’endroit où la routage et le volume de données sont contrôlés sans toucher au code de l’application.
Quel est le coût de OpenTelemetry ?
La norme et les bibliothèques sont open source et gratuites. Les coûts ne sont pas générés par OpenTelemetry lui-même, mais par le backend choisi et par l’exploitation du collecteur. C’est précisément pourquoi la séparation est précieuse : on optimise les coûts du backend indépendamment de l’instrumentation.
La migration en vaut-elle la peine pour une petite équipe ?
Si un monolithe et un outil approprié fonctionnent déjà bien ensemble, la migration n’est pas une fin en soi. Dès que plusieurs services ou langages entrent en jeu ou que la dépendance à un fournisseur est perceptible, l’instrumentation neutre des fournisseurs est rapidement rentable.
Plus d’informations du réseau MBF Media
Plus du réseau MBF Media
MyBusinessFutureIA dans les PME : le goulet d’étranglement se situe dans les systèmes anciensDigital ChiefsDette technique : pourquoi le conseil d’administration doit agir maintenantSecurityTodayPriorisation des correctifs : pourquoi CVSS seul bride votre SOCSource de l’image : Rashed Paykary / Pexels
