Quand iriez-vous chercher une trace distribuée plutôt qu'une métrique ou un log ?

Les métriques vous disent que quelque chose ne va pas et à peu près où. Les logs vous disent ce qui s'est passé à l'intérieur d'un processus. Les traces vous disent où est parti le temps à travers les services pour une seule requête. Sortez une trace quand la latence est élevée mais qu'aucun service pris isolément n'a l'air malade, ou quand une requête traverse beaucoup de sauts. Les métriques sont bon marché et agrégées, les logs détaillés et coûteux, les traces échantillonnées et relationnelles.

Je vois ça comme trois questions. Les métriques répondent à est-ce cassé et à quel point, les logs à ce qui s'est passé dans ce processus précis, et les traces à où est parti le temps sur l'ensemble de la requête. Le moment où je sors une trace, c'est quand la latence globale monte alors que chaque tableau de bord de service pris à part a l'air bien, ce qui veut presque toujours dire que le temps est dans un saut que personne ne possède. Ça nous est arrivé avec un sidecar de service mesh qui ajoutait des retries dont on ignorait l'existence ; la trace l'a rendu évident en une minute environ parce qu'on voyait trois spans identiques imbriqués sous un même appel. La colle pratique, c'est de mettre les identifiants de trace et de span dans chaque ligne de log, pour pouvoir sauter d'une métrique agrégée à une trace exemplaire lente puis aux lignes de log exactes de cette requête. Et j'échantillonnerais les traces en tête à faible taux avec un échantillonnage en queue pour les erreurs et les requêtes lentes, parce que tout garder ne vaut pas la facture.