Corrélation des signaux : relier logs, métriques et traces

Vous avez trois signaux — logs, métriques, traces — mais trois outils, trois interfaces, trois langages de requête. Une alerte se déclenche sur un dashboard, vous basculez vers les logs, vous cherchez manuellement un identifiant, vous le collez dans l’outil de tracing… et 20 minutes plus tard vous trouvez peut-être le span lent. La corrélation résout ce problème : elle relie vos signaux entre eux par un identifiant commun, le trace_id, pour passer du symptôme à la cause racine en quelques clics au lieu de quelques dizaines de minutes.

TL;DR

La corrélation repose sur un principe simple : injecter le même trace_id dans vos logs, vos métriques (via les exemplars) et vos traces. Les outils de visualisation (Grafana, Datadog, etc.) utilisent ensuite cet identifiant pour créer des liens cliquables entre les signaux. Le workflow de diagnostic devient : alerte → dashboard → log → trace → span lent → cause racine.

Ce que vous allez apprendre

• Le problème : pourquoi trois silos de données ralentissent le diagnostic
• Les identifiants de corrélation : trace_id, span_id, request_id — quoi injecter, où et comment
• Les exemplars : le mécanisme qui relie une métrique à une trace précise
• Les liens entre signaux : log → trace, trace → log, métrique → trace
• Le workflow diagnostic complet : de l’alerte à la cause racine en 5 étapes
• Les mécanismes dans les outils : data links, correlations et Explore dans Grafana

Le problème : trois silos, trois interfaces

Chaque signal d’observabilité a ses forces, mais aussi ses limites quand il est utilisé seul :

Signal	Ce qu’il montre	Ce qu’il ne montre pas
Métriques	Que quelque chose ne va pas (taux d’erreur, latence)	Pourquoi — aucun détail sur la requête individuelle
Logs	Ce qui s’est passé sur un service donné	Le parcours complet à travers plusieurs services
Traces	Où le temps est perdu dans la chaîne de services	Le contexte métier détaillé (payload, état applicatif)

Glissez pour voir

Sans corrélation, le diagnostic suit un chemin manuel et lent :

1. Un dashboard montre un pic de latence sur le P99
2. Vous devinez quel service est responsable
3. Vous ouvrez les logs de ce service, filtrez par timestamp
4. Vous trouvez (peut-être) un log d’erreur
5. Vous copiez un identifiant à la main
6. Vous le collez dans l’outil de tracing
7. Vous remontez le span lent

Chaque étape est une rupture de contexte. Vous changez d’outil, de requête, de format. Vous perdez du temps et vous risquez de suivre la mauvaise piste.

Analogie

Imaginez un hôpital où le radiologue, le biologiste et le médecin utilisent chacun un dossier patient différent, sans numéro commun. Pour recouper une radio, une analyse de sang et un examen clinique, il faut chercher manuellement par nom et date. Le trace_id, c’est le numéro de dossier unique qui relie tous les examens d’un même patient en un clic.

Les identifiants de corrélation

La corrélation repose sur des identifiants partagés entre les signaux. Trois identifiants coexistent souvent :

Identifiant	Portée	Format	Rôle
trace_id	Toute la chaîne de services	32 hex (128 bits, W3C)	Relier tous les signaux d’une même requête distribuée
span_id	Un seul service, une opération	16 hex (64 bits)	Identifier précisément quel span a produit un log ou une métrique
request_id	Variable (edge → backend)	UUID ou chaîne libre	Identifiant historique souvent généré par le load balancer ou l’API Gateway

Glissez pour voir

Quel identifiant utiliser ?

Le trace_id est le choix par défaut. Il est standardisé (W3C Trace Context), généré automatiquement par les SDK OpenTelemetry, et reconnu par tous les backends de tracing.

Le request_id reste utile quand :

• Votre infrastructure n’est pas encore instrumentée pour le tracing distribué
• Le load balancer ou le CDN génère un identifiant en amont (par exemple X-Request-Id) que vous propagez dans vos services
• Vous avez besoin d’un identifiant côté client (visible dans les headers de réponse HTTP pour le support)

La bonne pratique : injecter les deux — le trace_id pour la corrélation technique et le request_id pour la traçabilité côté support. OpenTelemetry peut capturer le request_id comme attribut de span.

Où injecter le trace_id ?

1. Dans chaque log structuré

   Le champ trace_id doit apparaître dans chaque ligne de log. La plupart des frameworks de logging (Logback, Serilog, structlog, Zap) peuvent l’injecter automatiquement via le contexte OpenTelemetry.

   {
     "timestamp": "2026-02-07T14:23:01.456Z",
     "level": "ERROR",
     "service": "payment-service",
     "message": "Bank API timeout after 3500ms",
     "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
     "span_id": "00f067aa0ba902b7"
   }

2. Dans les métriques, via les exemplars

   Quand vous incrémentez un compteur ou enregistrez une valeur dans un histogramme, vous attachez le trace_id de la requête en cours comme exemplar (voir section suivante).

3. Dans les traces elles-mêmes

   C’est automatique : le trace_id est la clé primaire de chaque span. Rien à faire si vos services sont instrumentés avec OpenTelemetry.

Convention de nommage

Conservez un champ uniforme (trace_id, span_id) dans tous les services. Mélanger traceId, traceID, trace-id et trace_id casse les parsers, les liens de corrélation et les requêtes dans les backends. Choisissez une convention (la snake_case d’OpenTelemetry est la plus répandue) et appliquez-la partout.

Les exemplars : le pont métrique → trace

Un exemplar est un échantillon attaché à un point de données d’une métrique. Concrètement, quand Prometheus scrape un counter ou un histogram, l’exemplar associe un trace_id à ce point précis de la série temporelle.

Comment ça fonctionne

Le mécanisme repose sur le format OpenMetrics (évolution du format Prometheus) :

# TYPE http_request_duration_seconds histogram
# HELP http_request_duration_seconds Durée des requêtes HTTP
http_request_duration_seconds_bucket{le="0.1",method="POST",route="/checkout"} 2100
http_request_duration_seconds_bucket{le="0.5",method="POST",route="/checkout"} 4350
http_request_duration_seconds_bucket{le="1.0",method="POST",route="/checkout"} 4890
http_request_duration_seconds_bucket{le="+Inf",method="POST",route="/checkout"} 5000 # {trace_id="4bf92f3577b34da6a3ce929d0e0e4736"} 4.2

La dernière ligne montre l’exemplar attaché au sample (la notation # {...} après la valeur — à ne pas confondre avec un label) : le bucket +Inf a reçu une requête de 4,2 secondes, et son trace_id est 4bf92f.... Dans Grafana, ce trace_id apparaît comme un losange cliquable sur le graphe de l’histogramme. Un clic ouvre directement la trace dans Tempo, Jaeger ou Zipkin.

Prérequis pour les exemplars

Les exemplars fonctionnent avec des conditions précises :

• Types de métriques : supportés sur les histogrammes et les counters dans Prometheus (pas sur les gauges)
• Format d’exposition : assurez-vous que votre cible et votre scrape supportent l’exposition d’exemplars (OpenMetrics / négociation de format via le header Accept: application/openmetrics-text). Sans cela, Grafana ne pourra pas afficher les losanges ni pivoter vers la trace
• Prometheus : l’option --enable-feature=exemplar-storage doit être activée
• SDK : le code d’instrumentation doit attacher le trace_id à chaque enregistrement de métrique

Exemplars et cardinalité

Les exemplars n’ajoutent pas de nouvelle série temporelle — ils n’augmentent pas la cardinalité. En revanche, ils consomment un budget de stockage dédié (buffer circulaire en mémoire + WAL). La quantité conservée est limitée et dépend de la configuration. C’est un lien « best effort », pas un historique complet.

Vérifier que les exemplars fonctionnent dans Grafana

Si vous ne voyez aucun losange sur vos graphes d’histogramme ou de counter, vérifiez ces trois points :

1. Exposition : votre cible expose-t-elle en OpenMetrics ? (header Accept: application/openmetrics-text négocié par Prometheus)
2. Stockage : Prometheus est-il démarré avec --enable-feature=exemplar-storage ?
3. Exporter : votre SDK attache-t-il bien un trace_id aux enregistrements de métriques ?

Si tout est en place, vous voyez un losange cliquable sur le graphe → un clic mène directement à la trace dans Tempo / Jaeger.

Les quatre directions de corrélation

La corrélation fonctionne dans plusieurs directions. Chaque direction répond à un besoin différent dans le diagnostic :

Log → Trace

Le cas le plus courant. Vous lisez un log d’erreur et vous voulez voir la trace complète de la requête qui l’a produit.

Mécanisme : le champ trace_id du log structuré sert de clé de recherche dans le backend de tracing.

Dans Grafana : si le trace_id est un label ou un champ parsé dans Loki, un data link peut générer automatiquement un lien vers Tempo. Cliquer sur le trace_id dans un log ouvre la trace dans un panneau latéral.

Trace → Logs

Le cas symétrique. Vous inspectez un span lent ou en erreur et vous voulez voir les logs émis pendant cette opération.

Mécanisme : le backend de tracing filtre les logs par trace_id (et éventuellement span_id pour cibler un span précis).

Dans Grafana : les trace correlations de Tempo permettent d’embarquer des liens cliquables directement dans la vue de trace. Un clic sur un span ouvre les logs Loki filtrés par trace_id et par l’intervalle temporel du span.

Métrique → Trace (via exemplar)

Vous observez un pic de latence sur un dashboard et vous voulez voir la trace d’une requête lente spécifique.

Mécanisme : l’exemplar attaché au point de données de la métrique contient le trace_id. Grafana affiche les exemplars comme des losanges sur les panels de type Time Series. Le survol affiche le trace_id, le clic ouvre la trace.

Trace → Métriques

Vous identifiez un span lent et vous voulez vérifier si c’est un problème ponctuel ou un pattern récurrent.

Mécanisme : à partir des attributs du span (service, endpoint, status code), vous construisez une requête PromQL pour voir la tendance sur la période. Ce lien est généralement configuré via des data links dans les dashboards — il n’est pas automatique.

Le workflow diagnostic : de l’alerte à la cause racine

Voici le parcours typique d’un incident dans un système correctement corrélé. Chaque étape est un clic, pas un copier-coller :

1. L’alerte se déclenche

   Le burn rate du SLO « latence checkout P99 < 2s » dépasse le seuil. Vous recevez une notification (Slack, PagerDuty, email).

2. Le dashboard montre le symptôme

   Vous ouvrez le dashboard du service checkout. Le panel P99 montre un pic à 4,2 s. Des losanges d’exemplars apparaissent sur les points hauts.

3. L’exemplar mène à la trace

   Vous cliquez sur un losange. Grafana ouvre la trace dans Tempo : POST /checkout → createOrder → processPayment → callBankAPI (3,5 s).

4. Le span lent mène aux logs

   Vous cliquez sur le span callBankAPI. Le lien de corrélation ouvre les logs Loki filtrés : Bank API timeout after 3500ms — retry 3/3 — circuit breaker OPEN.

5. Les logs révèlent la cause racine

   Le prestataire bancaire ne répond plus depuis 14:21. Le circuit breaker s’est ouvert après 3 tentatives. La cause est externe — pas un bug dans votre code.

Sans corrélation, ce diagnostic prend 15 à 30 minutes de navigation manuelle entre outils. Avec corrélation, c’est 5 clics et 2 minutes.

Le diagnostic en T inversé

Le workflow forme un T inversé : les métriques vous donnent la barre horizontale (vue d’ensemble, tendances, quel service est touché), puis le trace_id vous donne la barre verticale (plongée profonde dans une requête précise). Ni l’un ni l’autre ne suffit seul.

Mécanismes dans les outils : data links et correlations

La plupart des plateformes d’observabilité offrent des mécanismes pour relier les signaux. Voici les concepts génériques, illustrés avec Grafana (la stack open source la plus répandue pour la corrélation) :

Data links

Un data link est un lien hypertexte configurable sur un panel de dashboard. Il utilise les variables du panel (valeur, labels, timestamps) pour construire une URL vers un autre outil ou une autre vue.

Exemple : un panel Prometheus avec un data link vers Tempo :

URL : /explore?left={"datasource":"tempo","queries":[{"query":"${__data.fields.trace_id}"}]}

Ce lien prend le champ trace_id de la série et ouvre Explore avec Tempo filtré sur cette trace. Les data links fonctionnent sur les panels de dashboard — vous les configurez une fois, et chaque point du graphe devient cliquable.

Correlations (Grafana 10.1+)

Les correlations sont une évolution des data links, disponibles dans Explore (pas seulement les dashboards). Elles permettent de configurer des liens entre datasources au niveau de l’instance Grafana :

• Loki → Tempo (log → trace via trace_id)
• Tempo → Loki (trace → logs via trace_id + intervalle du span)
• Prometheus → Tempo (métrique → trace via exemplar)

La configuration se fait dans Configuration (ou Administration selon la version) → Plugins and data → Correlations, et les liens apparaissent automatiquement dans Explore et dans les vues de trace.

Ce que les autres plateformes offrent

Le principe est identique dans les plateformes commerciales, avec des noms différents :

Plateforme	Mécanisme	Configuration
Grafana (Loki + Tempo + Prometheus)	Data links, Correlations, Exemplars	Manuelle (YAML ou UI)
Datadog	Unified Service Tagging, Trace → Logs pivot	Quasi-automatique (agent unifié + conventions de tags)
Elastic (ELK + APM)	APM ↔ Logs correlation	Semi-automatique (agent Elastic APM)
Honeycomb	Colonnes unifiées (pas de silos)	Native (modèle en colonnes)
New Relic	Logs in Context, Distributed Tracing links	Quasi-automatique (agent New Relic + conventions)

Glissez pour voir

Page fondamentaux

Cette page explique les concepts de corrélation. La configuration concrète de Grafana (data links YAML, correlations UI, exemplars Prometheus → Tempo) sera détaillée dans les guides pratiques de la section Outils.

Prérequis techniques pour une corrélation fonctionnelle

La corrélation ne fonctionne que si chaque maillon de la chaîne fait sa part :

Composant	Ce qu’il doit faire	Si c’est absent
SDK d’instrumentation (OTel)	Générer le trace_id, le propager via traceparent, l’injecter dans le contexte de logging	Pas de trace_id dans les logs = pas de corrélation
Framework de logging	Émettre le trace_id et le span_id comme champs du log structuré	Les logs existent mais ne sont pas reliables aux traces
Bibliothèque de métriques	Attacher le trace_id comme exemplar sur les counters/histogrammes	Pas de lien métrique → trace
Backend de logs (Loki, ES)	Indexer le trace_id comme label ou champ recherchable	Log → Trace impossible (le champ existe mais n’est pas interrogeable)

Glissez pour voir

Côté logs, le trace_id doit être parseable et recherché efficacement (label Loki ou champ indexé Elasticsearch). Sans indexation, le pivot log → trace redevient une recherche full-text lente. | Backend de tracing (Tempo, Jaeger) | Stocker les spans et permettre la recherche par trace_id | Trace → span impossible | | Outil de visualisation (Grafana) | Configurer les data links / correlations entre datasources | Les données sont corrélables mais personne ne voit les liens |

Le piège classique : instrumenter parfaitement côté application, mais oublier de configurer les liens dans l’outil de visualisation. Les données contiennent les trace_id partout, mais personne ne peut cliquer pour naviguer entre les signaux.

Pièges courants

Piège	Pourquoi c’est un problème	Solution
trace_id absent des logs	Le signal le plus consulté (logs) n’est pas relié aux traces	Configurer le bridge OTel ↔ logging (Logback MDC, structlog, Zap fields)
Format Prometheus au lieu d’OpenMetrics	Les exemplars ne sont pas exposés — pas de lien métrique → trace	Exposer au format OpenMetrics (application/openmetrics-text)
trace_id comme texte libre, pas comme label indexé	La recherche log → trace est lente ou impossible	Indexer le trace_id comme label Loki ou champ Elasticsearch
Data links non configurés	Les données sont corrélées en théorie mais pas en pratique	Configurer les correlations Grafana (Administration → Correlations)
Sampling qui supprime le contexte	Le log contient un trace_id mais la trace a été échantillonnée (supprimée)	Aligner le sampling : si head-based, accepter que certains liens seront cassés ; si tail-based, le problème est réduit. Pour des pivots fiables en incident, privilégiez des règles qui gardent 100 % des erreurs (tail-based ou head-based conditionnel)
Horloges désynchronisées	Les liens « trace → logs par intervalle temporel » ramènent des logs décalés	Synchroniser les horloges (NTP/chrony) sur tous les nœuds — viser < 10 ms de dérive

Glissez pour voir

À retenir

1. La corrélation repose sur un identifiant commun — le trace_id — injecté dans les logs, attaché aux métriques (exemplars), et natif dans les traces

2. Les exemplars relient une métrique à une trace : un trace_id attaché à un point de données (histogram ou counter), affiché comme un losange cliquable dans Grafana

3. La corrélation fonctionne dans quatre directions : log → trace, trace → logs, métrique → trace (exemplar), trace → métriques (data links)

4. Le workflow diagnostic suit un parcours reproductible : alerte → dashboard → exemplar → trace → span lent → logs → cause racine — chaque étape est un clic, pas un copier-coller

5. La corrélation est une chaîne : si un seul maillon manque (SDK, logging, backend, visualisation), le lien est cassé

6. Configurer les liens dans l’outil de visualisation est aussi important que l’instrumentation côté code — sans data links ni correlations, les trace_id existent mais personne ne peut naviguer entre les signaux

Sources

• Grafana Correlations : grafana.com/docs — Correlations Editor in Explore — mécanisme de liaison entre datasources
• Grafana Trace Correlations : grafana.com/docs — Trace correlations — liens embarqués dans la vue de trace
• Prometheus Exemplars : prometheus.io/docs — Feature Flags: exemplar-storage — activation et usage des exemplars
• OpenTelemetry Logs Bridge : opentelemetry.io/docs — Logs Bridge API — injection du contexte de trace dans les logs

Prochaines étapes

OpenTelemetry Le framework unifié qui génère trace_id, spans et exemplars automatiquement

Traces distribuées Comprendre les spans, la propagation de contexte et le sampling

Logs structurés Le champ trace_id dans vos logs — format, conventions et bonnes pratiques

Métriques Histogrammes, counters et le format OpenMetrics qui supporte les exemplars

×

📖 Voir la documentation →