Correlating traces, metrics, logs and profiles

1. Pourquoi corréler #

Le temps de diagnostic est le vrai coût d'un incident.

Sans et avec corrélation #

Sans corrélation, l'ingénieur d'astreinte voit un pic d'erreurs dans un tableau de bord, cherche des logs autour de la même heure, devine quel service est en cause, puis cherche une trace « qui ressemble ». Avec des signaux corrélés, chaque étape est un clic, sur des données qui concernent la même requête.

2. Les mécanismes de corrélation #

Ce qu'il faut mettre en place.

Vue d'ensemble #

Une ressource partagée #

# Les mêmes variables pour tous les signaux d'un service
export OTEL_SERVICE_NAME=checkout
export OTEL_RESOURCE_ATTRIBUTES=service.namespace=shop,service.version=1.4.0,deployment.environment.name=production
export OTEL_TRACES_EXPORTER=otlp OTEL_METRICS_EXPORTER=otlp OTEL_LOGS_EXPORTER=otlp

Erreur Courante : Si les traces disent checkout et les logs checkout-api, aucune navigation automatique ne fonctionne. Le nom du service est la clé de toute la corrélation.

3. Configurer Grafana #

Les liens entre sources de données.

Provisioning des sources #

apiVersion: 1
datasources:
  - name: Tempo
    type: tempo
    uid: tempo
    url: http://tempo:3200
    jsonData:
      tracesToLogsV2:
        datasourceUid: loki
        filterByTraceID: true
        spanStartTimeShift: -5m
        spanEndTimeShift: 5m
      tracesToMetrics: { datasourceUid: prometheus }
      tracesToProfiles: { datasourceUid: pyroscope, profileTypeId: "process_cpu:cpu:nanoseconds:cpu:nanoseconds" }
      serviceMap: { datasourceUid: prometheus }
  - name: Loki
    type: loki
    uid: loki
    url: http://loki:3100
    jsonData:
      derivedFields:
        - { name: TraceID, matcherRegex: '"trace_id":"(\w+)"', url: "$${__value.raw}", datasourceUid: tempo }
  - name: Prometheus
    type: prometheus
    uid: prometheus
    url: http://prometheus:9090
    jsonData:
      exemplarTraceIdDestinations: [{ name: trace_id, datasourceUid: tempo }]

Le parcours type #

1. L'alerte de burn rate se déclenche sur le SLO de latence.
2. Le panneau de latence p99 affiche des exemplars : on clique sur le plus haut.
3. La trace s'ouvre : le span payment dure 2 s et finit en erreur.
4. « Logs for this span » affiche le log connection pool exhausted.
5. « Profiles for this span » montre le temps passé à attendre le pool.
6. La version (service.version) montre que le problème est apparu avec le dernier déploiement.

4. Baggage et contexte métier #

Corréler aussi avec le métier.

Utiliser le baggage #

from opentelemetry import baggage, context
ctx = baggage.set_baggage("shop.customer.tier", "premium")
token = context.attach(ctx)        # propagé aux services appelés (en-tête baggage)
try:
    appeler_paiement()
finally:
    context.detach(token)

Dans les SDK et le Collector, un span processor peut copier certaines clés du baggage en attributs de span pour filtrer « toutes les traces lentes des clients premium ».

Erreur Courante : Le baggage voyage en clair dans les en-têtes HTTP, y compris vers des services tiers : n'y mettez jamais de données sensibles et filtrez-le en sortie du système.