Relier un test de charge aux traces avec OpenTelemetry

Le rapport d'un tir donne le 95e percentile de la transaction « valider la commande » : trop haut. Il ne dit pas lequel des cinq services appelés en chaîne traîne. Les outils d'APM répondent à cette question quand ils sont installés ; OpenTelemetry vise le même résultat sans dépendre d'un fournisseur, à condition de relier chaque requête de test à sa trace.

Ce qu'est OpenTelemetry

La documentation du projet le définit comme un cadre et une boîte à outils d'observabilité, indépendants du fournisseur, qui produisent trois signaux : des traces, des métriques et des journaux. Il ne les stocke pas et ne les affiche pas : un autre outil s'en charge. Le projet est passé « graduated » à la CNCF le 11 mai 2026.

La spécification donne les traces et les journaux comme stables. Pour les métriques, l'API est stable et le SDK porte la mention « mixed », le modèle de données étant stable alors que le reste évolue. Le statut réel dépend du langage : les pages d'état listent des SDK Java à tous les signaux stables, et des journaux encore en développement pour JavaScript et Python. Avant d'instrumenter, lisez la ligne de votre langage.

L'en-tête qui relie les deux mondes

Le W3C a publié en novembre 2021 la Recommandation Trace Context. Elle définit l'en-tête traceparent, composé de quatre champs : la version, un identifiant de trace sur 16 octets, un identifiant de l'appel courant sur 8 octets et des indicateurs, dont un seul est défini en version 00 : « sampled », qui signale que l'appelant a retenu la trace. Un service instrumenté qui reçoit cet en-tête rattache son travail à la même trace.

Côté outil de test, il suffit donc d'ajouter l'en-tête à chaque requête et de garder l'identifiant. La documentation de k6 prévoit un module pour cela : http-instrumentation-tempo, avec les propagateurs w3c et jaeger. Avec w3c, chaque requête reçoit un en-tête traceparent.

Un essai, rejoué

import http from 'k6/http';
import { check } from 'k6';
import { instrumentHTTP } from 'https://jslib.k6.io/http-instrumentation-tempo/1.0.1/index.js';

instrumentHTTP({ propagator: 'w3c' });

export const options = { vus: 1, iterations: 1 };

export default function () {
  const res = http.get(`${__ENV.CIBLE}/produit`);
  console.log('traceparent reçu par la cible : ' + res.json('traceparent'));
  check(res, { 'en-tête traceparent présent': (r) => !!r.json('traceparent') });
}

La cible de l'essai est un petit serveur HTTP local qui renvoie en JSON l'en-tête traceparent reçu. Le script a été exécuté le 5 novembre 2026 avec k6 v2.3.0, dans son image Docker officielle. Résultat :

level=info msg="traceparent reçu par la cible : 00-dc071818e520af180ecff4b21eef08e1-6afe321e92b971a9-01"
✓ en-tête traceparent présent

La valeur respecte le format du W3C : version 00, identifiant de trace de 32 caractères hexadécimaux, identifiant d'appel de 16, indicateur 01. Ce que cet essai ne prouve pas : le rapprochement avec une trace dans un outil d'observabilité. La documentation du module cite Grafana Tempo comme destination ; les étapes de recherche par identifiant côté Tempo n'ont pas été rejouées ici. Elle ne dit pas non plus si le module est stable, et la version 1.0.1 de l'adresse ci-dessus est celle qui a répondu à l'essai.

Ce que le client ajoute aux résultats

La documentation de l'ancien client de traçage de k6 (k6/experimental/tracing, que ce module remplace) dit qu'il ajoute l'identifiant de trace aux métadonnées des points de données HTTP de la sortie k6 ; nous n'avons pas relevé que la page du module actuel le dise. Avec cette métadonnée, une requête lente repérée dans le rapport peut se retrouver côté observabilité sans deviner. k6 sait aussi envoyer ses propres métriques au format OpenTelemetry vers un collecteur (k6 run -o opentelemetry, commande citée d'après la documentation, non rejouée ici) ; la page ne précise ni le statut de cette sortie ni la version qui l'a introduite.

Quoi regarder une fois la trace trouvée

Le livre de Google sur la fiabilité des systèmes propose quatre signaux : la latence, le trafic, les erreurs et la saturation. Une trace lente permet de lire la latence service par service ; les métriques de saturation disent si l'un d'eux manque de ressource. Le même ouvrage rappelle qu'une moyenne cache la queue de distribution : regardez les percentiles, y compris dans la trace.

Limites

• Il faut que les services traversés soient instrumentés, sinon la trace s'arrête au premier maillon.
• Tracer toutes les requêtes d'un tir produit beaucoup de données. Ce que le backend conserve dépend de sa configuration d'échantillonnage ; vérifiez-la avant le tir.
• Le statut des SDK varie selon le langage, et celui du module k6 n'est pas documenté.

Rédigé avec l’aide d’une IA, relu et validé par Philippe Naveau.