Tracing, logs et métriques : les 3 piliers

Prérequis : cours 4.3 (corrélation) ; [logs](DevOps 7.1 — voir cursus DevOps).

Pourquoi

« Lent en prod » sans observabilité = devinettes. Les 3 piliers répondent à 3 questions : combien (métriques), quoi exactement (logs), où ça coince dans la chaîne (traces).

Concepts

• Métriques : nombres agrégés dans le temps (taux d'erreur, p95, saturation). Pour les tendances et les alertes. Outils : Prometheus + Grafana, ou managé.
• Logs structurés : l'événement précis (qui, quoi, quand, requestId). Pour le diagnostic d'un cas. JSON en prod, jamais de texte libre à parser en panique.
• Traces distribuées : un appel = un arbre de spans (proxy → api → base → paiement) avec durées, propagé par headers (W3C Trace Context). Pour localiser l'étage lent dans la chaîne. Outils : OpenTelemetry (standard), Jaeger/Tempo.
• La règle : métriques pour savoir QU'il y a un problème, traces pour savoir OÙ, logs pour savoir QUOI.

Exemple : le trio en incident

1. Alerte : p95 /checkout passé de 300 ms à 4 s (métrique)
2. Trace : le span 'reserve-stock' prend 3,7 s (trace)
3. Logs : timeouts vers le service stock à 14h02 (logs) → cause : deploy stock 14h00

Cas réel

« L'app est lente » sans tracing : 3 jours à profiler chaque service. Avec : la trace montre le span fautif en 5 minutes. L'observabilité ne coûte pas — elle évite de payer en devinettes.

Pièges

• Logs sans requestId/traceId : 3 piliers non reliés = 3 silos. Corréler par IDs partout.
• 100 % des traces conservées : coût explosif. Échantillonnage (100 % erreurs, 1-5 % succès).
• Métriques sans labels utiles (route, statut, version) : des courbes qu'on ne peut pas découper = décorations.

À retenir

Métriques = combien (alertes), traces = où (chaîne), logs = quoi (cas) ; reliés par IDs ; échantillonner.