OpenTelemetry en production : arrêtez le débogage dans le noir

La première fois que vous avez vraiment besoin d’observabilité, ce n’est pas lorsque vous regardez calmement un tableau de bord. C'est lorsqu'un utilisateur écrit « le paiement est lent », que le graphique d'erreur semble normal et que dans les journaux, vous ne trouvez qu'une rangée de messages déconnectés.

OpenTelemetry a été créé pour éviter ce moment : non pas pour avoir plus de graphiques, mais pour relier les pièces. Une requête entre dans le API, appelle une base de données, passe par un fournisseur externe, publie une tâche en file d'attente et peut échouer trois services plus tard. Sans traçage distribué, vous reconstruisez cette histoire à la main. Avec OpenTelemetry au moins vous avez une carte.

Le problème n'est pas le trace, c'est l'histoire

Un trace est une séquence de span. Dit comme ça, ça fait froid. En pratique, chaque span est un morceau de l'histoire : POST /checkout, SELECT inventory, call payment provider, publish order.created.

La valeur vient lorsque vous commencez à répondre à de vraies questions :

quel service externe ralentit ?
les erreurs proviennent-elles d'une version spécifique ?
le problème concerne-t-il tout le monde ou un seul locataire ?
une nouvelle tentative cache-t-elle un délai d'attente ?
le travail asynchrone démarre mais meurt ensuite ailleurs ?

Ces questions ne peuvent pas être résolues par un console.log lancé à la hâte. En effet, souvent le journal ajouté en cas d'urgence vous aide aujourd'hui et devient du bruit demain.

Comment pourrais-je mettre cela dans une application Node.js

La configuration la plus saine est simple : l'application produit la télémétrie, le Collector décide où l'envoyer.

Node.js app -> OpenTelemetry Collector -> backend di observability

Pourquoi ne pas exporter directement vers le fournisseur ? Parce qu'au début, cela semble plus rapide, vous réalisez ensuite que chaque service a des configurations différentes, des tentatives différentes, des filtres différents et aucun point central pour supprimer les données sensibles ou changer de destination.

Le Collector est ennuyeux dans tous les sens du terme. Il reçoit OTLP, effectue le traitement par lots, peut filtrer, effectuer des échantillonnages, ajouter des attributs communs et exporter vers plusieurs systèmes.

Auto-instrumentation : bien, mais pas suffisant

En Node.js, je commencerais par l'auto-instrumentation. Il vous offre une visibilité immédiate sur HTTP, les frameworks pris en charge, les bases de données et les bibliothèques communes.

npm install @opentelemetry/sdk-node \
  @opentelemetry/auto-instrumentations-node \
  @opentelemetry/exporter-trace-otlp-http

Ensuite, vous initialisez le SDK avant le reste de l'application :

import { NodeSDK } from '@opentelemetry/sdk-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: process.env.OTEL_EXPORTER_OTLP_TRACES_ENDPOINT,
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

Cependant, cela concerne le cadre, pas votre produit. Il sait que vous avez effectué une requête, mais il ne sait pas que cette requête était dans « ordre de création » ou « renouvellement d'abonnement ». Pour cela, vous avez besoin de span manuels aux points où la domination compte.

const span = tracer.startSpan('checkout.create_order');

try {
  span.setAttribute('cart.items_count', input.items.length);
  const order = await createOrder(input);
  span.setAttribute('order.id', order.id);
  return order;
} catch (error) {
  span.recordException(error as Error);
  throw error;
} finally {
  span.end();
}

Je ne mettrais les manuels span nulle part. Je les mettrais là où, à trois heures du matin, j'aimerais comprendre ce qui s'est passé sans lire la moitié de la base de code.

Trois règles qui évitent beaucoup de chaos

Première règle : chaque service doit avoir service.name, environnement et version. Cela semble trivial, mais sans ces attributs, un trace est beaucoup moins utile. Lorsqu'un déploiement interrompt quelque chose, vous souhaitez filtrer par version en deux secondes.

Deuxième règle : ne mettez pas de données sensibles dans les attributs. Les e-mails, les jetons, les charges utiles entières et les adresses ne doivent pas se retrouver par accident dans un backend d’observabilité. Si vous devez identifier un utilisateur, envisagez les identifiants internes, le hachage ou les champs moins sensibles.

Troisième règle : faites attention à la cardinalité. user.id comme attribut de trace peut avoir du sens. En tant qu'étiquette métrique, elle peut détruire vos coûts et vos performances.

Métriques : peu nombreuses, mais bonnes

Je commencerais par des mesures très pratiques :

tarifs, erreurs et durée des demandes ;
latence des dépendances externes ;
nombre de délais d'attente et de tentatives ;
profondeur des queues ;
durée du travail ;
pourcentage d'erreurs par version.

Le reste est ajouté en cas de besoin. Les tableaux de bord remplis de graphiques que personne ne regarde sont des meubles, pas des observables.

Logs : toujours utiles, mais liés

Les journaux ne disparaissent pas. Ils deviennent simplement beaucoup plus utiles lorsqu'ils portent trace_id et span_id. Vous pouvez donc partir d'un journal d'erreurs et ouvrir le trace, ou partir d'un trace lent et lire uniquement les journaux produits dans ce chemin.

Sans corrélation, vous recherchez des aiguilles. Avec la corrélation, au moins vous savez dans quel tiroir regarder.

La checklist que j'utiliserais avant de dire "nous sommes couverts"

Le trace traverse en fait plusieurs services.
Les journaux incluent trace_id et span_id.
Le Collector est configuré avec des limites de traitement par lots et de mémoire.
Les erreurs sont enregistrées en span.
Il existe une politique d'échantillonnage.
Les métriques ont une cardinalité contrôlée.
Les données sensibles sont filtrées.
Les alertes partent des symptômes de l'utilisateur et non de graphiques aléatoires.

Conclusion

OpenTelemetry ne résout pas à lui seul les problèmes de production. Mais la façon dont vous les gérez change. Au lieu d'ajouter aveuglément des journaux, vous commencez à suivre le chemin réel d'une requête.

Pour moi, le signe que ça marche est simple : quand quelque chose arrive, l'équipe arrête de se demander « où cherche-t-on ? et commence à demander "pourquoi ce morceau est-il lent ?". C'est là que l'observabilité devient un outil et non un ensemble de tableaux de bord.

##Sources