tracing-setuplisted

# Tracing distribué ## Ce que ce skill n'enseigne pas Déployer un collecteur OpenTelemetry, configurer un backend Jaeger ou Tempo, lire une cascade dans une interface : ce sont des tâches d'outillage bien documentées. Ici on décide **ce qu'on trace, comment on le nomme et ce qu'on garde**. La règle de base : **le tracing répond à "où le temps est parti", pas à "combien" ni à "quoi exactement".** Ces deux questions appartiennent à `metrics-setup` et `logging-setup`. ## La propagation d'abord, tout le reste ensuite **Une trace interrompue ne vaut rien.** Un span orphelin est pire qu'une absence de trace : il donne l'illusion d'une couverture. C'est le seul point à valider avant d'investir dans le nommage ou les attributs. Le contexte voyage dans l'en-tête **W3C `traceparent`** (format standard, à préférer aux formats propriétaires). Il doit traverser : | Frontière | Point de vigilance | |---|---| | Appel HTTP sortant | Le client instrumenté injecte l'en-tête. Un client construit à la main ne le fait pas | | Message en file | Le contexte se met dans les **en-têtes du message**, pas dans son corps métier | | Job asynchrone ou batch | Le contexte du producteur doit être sérialisé avec la tâche, sinon la trace s'arrête à l'enqueue | | Passerelle, proxy, load balancer | Vérifier que l'en-tête est transmis et non filtré | | Frontière d'équipe ou de prestataire | Se mettre d'accord sur le format en amont, pas après | Test de validation : prendre un `trace_id` réel et vérifier