Observabilité · standards · devops

Qu'est-ce qu'OpenTelemetry ?

Par ColdwastMis à jour le 14 août 20269 min de lecture#opentelemetry#observabilite#devops

Un ordinateur portable argenté ouvert sur une table basse sombre dans un salon, son écran rempli d'un tableau de bord d'analytics : courbe de tendance, grille de cohortes bleue, carte du monde et anneau bleu — Un portable sur une table basse affichant un tableau de bord d'analytics — courbe de tendance, grille de cohortes bleue, carte du monde et diagramme en anneau, avec un canapé gris flou derrière. Le tableau de bord est la partie facile ; ce qui l'alimente est la vraie question.

OpenTelemetry est un standard pour PRODUIRE de la télémétrie, pas un outil pour la regarder. Cette seule phrase dissipe l'essentiel de la confusion qui l'entoure. Vous instrumentez votre application une fois, de façon indépendante des éditeurs, et vous décidez séparément où partent les données.

C'est un projet de la CNCF, né en 2019 de la fusion de deux efforts antérieurs — OpenTracing et OpenCensus — qui se partageaient le même problème. Cette fusion est tout l'enjeu : avant elle, choisir une bibliothèque d'instrumentation revenait à choisir un camp.

Le problème qu'il résout

Avant OpenTelemetry, instrumenter une application signifiait importer le SDK de son éditeur de supervision dans tout son code. Changer d'éditeur signifiait toucher à chaque service ayant un jour émis une métrique.

C'est de l'enfermement propriétaire exprimé en code source, et il colle particulièrement bien à la peau, parce que le coût du départ se répartit sur toutes les équipes ayant jamais ajouté un span. OpenTelemetry inverse le rapport : l'instrumentation vous appartient, le backend devient un choix de configuration.

Les trois signaux

OpenTelemetry définit trois types de télémétrie, et ils répondent à des questions différentes.

Les traces suivent une requête unique à travers les services. Une trace est faite de spans, chacun avec un début, une durée et un parent : vous voyez qu'une requête a passé 40 ms dans votre API et 2 secondes à attendre une base de données. C'est ce qui vous dit où le temps est parti.

Les métriques sont des nombres agrégés dans le temps : débit de requêtes, nombre d'erreurs, profondeur de file, mémoire utilisée. Elles coûtent peu à stocker et à tracer, et vous disent que quelque chose a changé, rarement pourquoi.

Les logs sont les lignes horodatées habituelles. Leur ajout à OpenTelemetry compte moins pour le format que pour la corrélation : un log émis à l'intérieur d'un span peut porter les identifiants de ce span, si bien qu'une ligne de fichier ramène à la requête exacte qui l'a produite.

Ensemble, la répartition des rôles est nette : les métriques remarquent le problème, les traces le localisent, les logs l'expliquent.

Une tablette posée sur une table en bois affichant un tableau de bord d'analytics avec un camembert des sources de trafic, une carte du monde, une courbe de visiteurs et un tableau de contenus, une tasse blanche et un smartphone flous à côté — Une tablette sur un bureau en bois affichant un tableau de bord de trafic : camembert répartissant direct, recherche et référents, carte du monde, et une courbe de visiteurs indiquant 2 958. Une tasse blanche, un téléphone et un stylet posés autour, hors mise au point.

API, SDK, Collector : ce que chaque pièce est vraiment

Trois noms reviennent sans cesse, et les confondre est la source habituelle des malentendus.

L'API est ce que votre code appelle. Elle est délibérément minimale et ne fait rien par elle-même : une application compilée avec l'API mais sans SDK ne produit aucune télémétrie et ne paie presque rien pour ces appels. C'est ce qui rend l'instrumentation sûre pour l'auteur d'une bibliothèque — la décision de collecter est laissée à l'application.

Le SDK est l'implémentation que vous configurez : échantillonnage, mise en lots, et exporteurs à utiliser. Il transforme les appels d'API en données qui quittent le processus.

Le Collector est un binaire séparé qui reçoit la télémétrie, la transforme et la retransmet. Il est facultatif, et c'est aussi la pièce que l'on finit par apprécier le plus : elle permet de changer de backend, d'ajouter un filtrage, de retirer des attributs bavards ou d'alimenter deux systèmes à la fois sans redéployer vos applications.

Ce qu'OpenTelemetry ne fait pas

Il ne stocke rien, et ne trace pas un seul graphique. Il n'y a pas d'interface OpenTelemetry où se connecter.

Il vous faut toujours un backend — Jaeger, Prometheus, Grafana, ou une plateforme commerciale — et c'est une décision de périmètre délibérée, pas un manque. Cela signifie aussi qu'adopter OpenTelemetry ne vous donne pas l'observabilité pour autant : cela vous donne des données portables, et il reste à choisir où les mettre et qui les lit à trois heures du matin.

La seconde chose à savoir avant d'adopter : la télémétrie a un coût. Des traces à plein volume sur un service chargé produisent beaucoup de données — c'est la raison d'être de l'échantillonnage, et cela mérite d'y penser tôt plutôt qu'après la première facture.

Faut-il l'utiliser ?

Si vous exploitez plus de deux ou trois services, oui — et l'argument est la portabilité, pas les fonctionnalités. Instrumenter une fois contre un standard fait de la prochaine migration de backend un changement de configuration au lieu d'une réécriture.

Si vous n'avez qu'une seule application, la réponse honnête est que des logs simples et deux ou trois métriques vous serviront longtemps. Le traçage distribué résout un problème distribué ; l'adopter avant d'en avoir un ajoute des pièces mobiles sans répondre à une question que vous vous posez réellement.

Le point de départ pratique, pour la plupart des équipes, c'est l'auto-instrumentation : dans plusieurs langages, des agents produisent des traces utiles à partir d'une application non modifiée. C'est assez pour voir si ces données vous apprennent quelque chose avant de passer un sprint à ajouter des spans à la main.

Guide indépendant, maintenu par la communauté. coldwa.st est un site de ressources pour la programmation ; cet article est un texte explicatif original sur OpenTelemetry et n'est affilié ni au projet OpenTelemetry ni à la CNCF. La spécification évolue et la stabilité des signaux diffère selon les langages — vérifiez la documentation en vigueur pour votre runtime avant de vous fier à un détail.