Vendredi soir, un client clique sur « Payer ». La requête traverse nginx, l'API checkout, le service inventaire en gRPC, Redis, PostgreSQL, puis un job webhook asynchrone. Le support reçoit « timeout ». Les logs API affichent upstream timed out ; les logs inventaire, rien d'anormal en volume. Pourtant un seul appel gRPC lent — noyé dans la moyenne — explique l'attente. Sans trace unifiée, personne ne le voit.
Dès qu'une action traverse deux briques ou plus, le diagnostic se fragmente. Le tracing distribué attache un trace_id à la requête d'origine et enregistre chaque segment (span) : durée, service, erreur. Vous voyez l'arbre complet, pas des feuilles isolées. La vraie question : savez-vous reconstituer le fil qu'un utilisateur vit comme une seule action ?
Traces, logs et métriques : trois piliers, pas trois substituts
Prometheus signalera un p95 doublé sur /api/checkout — voir Prometheus : choisir des métriques qui expliquent une lenteur. Les logs centralisés montreront une stack trace à un instant T. Aucun des deux ne relie le timeout nginx à la requête SQL lente sur le catalogue, ni au job webhook sans contexte.
| Pilier | Ce qu'il révèle | Limite typique |
|---|---|---|
| Métriques | Tendances, alertes, respect des SLO | Agrège — un cas rare disparaît dans le p95 |
| Logs | Contexte textuel, paramètres, erreurs | Un silo par service, corrélation manuelle |
| Traces | Chemin complet d'une requête | Coût de stockage si mal échantillonné |
Retirer les traces, c'est deviner où le parcours s'est brisé — le genre d'aveugle qui alimente la fatigue d'alertes.
Span, trace et propagation du contexte
Un trace représente le parcours complet d'une action utilisateur — par exemple checkout-abc123. Un span est une opération unitaire à l'intérieur de ce parcours : un appel HTTP GET /stock, une requête SQL SELECT, un publish Redis. Chaque span enregistre sa durée, son statut et le service qui l'a exécuté.
La propagation du contexte est le maillon faible le plus fréquent. Le trace_id doit voyager du reverse proxy jusqu'aux workers asynchrones, via les en-têtes HTTP W3C (traceparent, tracestate), les métadonnées gRPC, ou le payload du job en file d'attente. Sans cette transmission, le worker crée une trace orpheline sans lien avec la requête d'origine — et la moitié de l'histoire disparaît au premier traitement différé.
| Composant | Instrumentation courante |
|---|---|
| nginx | module OpenTelemetry ou ingress du maillage de services |
| PHP / Laravel | bibliothèque open-telemetry/opentelemetry-php |
| Go / Java | kits natifs matures, intégration simple |
| Worker de file d'attente | extraction du contexte depuis le message du job |
Instrumenter le reverse proxy sans instrumenter l'application, c'est voir l'entrée et la sortie — pas ce qui se passe entre les deux.
OpenTelemetry, Jaeger et Tempo : choisir sa stack
OpenTelemetry (OTel) collecte traces, métriques et logs avec une instrumentation unique. Exportez vers Jaeger (interface autonome), Grafana Tempo (stockage objet, corrélation Loki/Prometheus) ou un service managé. Sur un VPS modeste, un agent OTel Collector vers Tempo Cloud ou Grafana Cloud évite d'héberger Jaeger et Elasticsearch vous-même.
Échantillonnage : ne pas tracer tout le trafic
Tracer chaque requête en production génère un volume de données difficile à stocker et à interroger. Deux stratégies dominent.
L'échantillonnage en tête décide à l'entrée (ex. une requête sur cent) — simple, mais un cas rare peut échapper au filet. L'échantillonnage en queue garde systématiquement les parcours lents ou en erreur ; Grafana Tempo excelle sur ce modèle. Configurez ces règles avant un pic de charge, pas pendant l'incident.
Corréler logs et traces : fermer la boucle
Injectez le trace_id dans vos logs JSON ("trace_id": "abc123..."). Dans Grafana, un clic depuis un span lent ouvre le log avec la stack trace. Procédure d'incident : alerte p95 → trace la plus lente → span SQL fautif → requête exacte dans le log. Excluez les données sensibles (email, carte, identifiant patient) des attributs de span.
Limites et pièges courants
Spans trop granulaires → surcharge et interface illisible. Horloges désynchronisées → arbre incohérent (NTP obligatoire). Istio trace le HTTP entre pods, pas vos requêtes SQL sans instrumentation applicative. « Jaeger installé » ≠ « checkout lent diagnostiquable » : commencez par les parcours qui génèrent du chiffre.
Le sommet : trois tableaux de bord, zéro histoire
Voici ce que les stacks « observables » vendues clé en main passent souvent sous silence.
Décider et avancer sans angle mort
Sur une à deux journées, rendez une architecture multi-services diagnosable. Identifiez d'abord un parcours critique — checkout, login, API partenaire — et instrumentez-le en priorité. Déployez OpenTelemetry sur le reverse proxy, l'application et les workers, puis vérifiez que le contexte traverse les files d'attente asynchrones. Configurez l'échantillonnage en queue pour conserver les traces en erreur et celles au-dessus de votre seuil de latence. Injectez le trace_id dans les logs JSON et testez la navigation span → log. Simulez une requête lente volontaire : si elle n'apparaît pas en une trace bout en bout, corrigez la propagation avant le prochain incident.
Comparez les hébergeurs où vous pourrez installer vos propres agents via l'annuaire et le comparateur. Si Prometheus montre une dégradation sans localiser la couche fautive, lisez Prometheus : choisir des métriques qui expliquent une lenteur avant d'ajouter un dashboard.
Questions fréquentes
Traces, logs ou métriques — que choisir ?
Les trois se complètent, aucun ne remplace les autres. Les métriques agrègent dans le temps et alimentent les alertes ; les logs décrivent un instant précis avec du contexte textuel ; les traces relient les segments d'une même requête utilisateur à travers plusieurs services. Prometheus seul ne dira pas quelle requête SQL a bloqué le checkout — une trace le montrera en un coup d'œil.
OpenTelemetry est-il le standard à adopter ?
Oui, c'est aujourd'hui le choix le plus durable. OpenTelemetry propose une instrumentation neutre vis-à-vis des éditeurs, avec des exporteurs vers Jaeger, Grafana Tempo, Datadog ou d'autres backends. Évitez de nouer votre application à un kit de développement propriétaire unique : vous changerez probablement d'outil de visualisation avant de réécrire votre code.
Comment propager le contexte entre services ?
Utilisez les en-têtes W3C traceparent et tracestate du point d'entrée jusqu'aux workers asynchrones. Chaque saut — reverse proxy, appel gRPC, message en file d'attente — doit transmettre le même identifiant de trace. Sans cette propagation, chaque service crée une trace orpheline isolée, et vous perdez la moitié de l'histoire au premier job différé.
Quel échantillonnage en production ?
Un échantillonnage en tête de 1 à 10 % suffit souvent pour le trafic courant. L'échantillonnage en queue — proposé par Grafana Tempo — garde systématiquement les traces lentes ou en erreur, ce qui équilibre coût de stockage et capacité de diagnostic. Configurez ces règles avant un pic de charge, pas pendant l'incident.
La prochaine fois qu'un incident traversera trois services sans coupable évident, posez une question : pouvons-nous suivre une seule requête de bout en bout ? Si la réponse est non, le trace_id manquant coûtera plus cher que son instrumentation.