- Mode distribution (toujours activé) : lorsqu’il n’y a aucune sélection sur la heatmap, la distribution des valeurs de chaque attribut est affichée pour la population actuelle de spans. Utile pour repérer les valeurs dominantes ou inhabituellement rares (valeurs aberrantes de cardinalité).
- Mode de comparaison : faites glisser un rectangle sur la heatmap pour comparer les spans à l’intérieur (Selection) à tout ce qui se trouve à l’extérieur (Background). Utile pour isoler les écarts.
- Drill-down itératif : cliquez sur n’importe quelle barre pour filtrer (ou exclure) cette valeur. La heatmap est recalculée en fonction de la population filtrée, ce qui vous permet d’affiner progressivement jusqu’à ce que la cause devienne évidente.
Prérequis
Prise en main
- Dans la liste déroulante Data Source, sélectionnez une source contenant des traces. Le nom de la source est libre ; l’important est qu’elle soit configurée avec le type Trace. L’onglet Event Deltas n’est activé que pour les sources de ce type.
- Dans la section Analysis Mode, cliquez sur l’onglet Event Deltas.
Le heatmap
- Axe X : le temps
- Axe Y : une valeur numérique, par défaut la durée du span en millisecondes (échelle logarithmique)
Mode de distribution : anomalies de cardinalité
- Valeurs les plus fréquentes : quels services, endpoints, codes d’état ou hôtes dominent votre population de spans ? Cela met souvent en évidence un seul tenant, une version ou une route qui génère l’essentiel du trafic.
- Valeurs rares : des valeurs qui apparaissent, mais rarement. Un code d’état présent dans seulement
0.5%des spans, ou un hôte à peine visible, peut être le signal le plus intéressant. C’est dans la longue traîne que se cachent les régressions et les acteurs malveillants.
Mode de comparaison : écarts par rapport à la normale
Cas d’usage 1 : avant vs après une régression
SpanKind, SpanName et ScopeName montrent chacun une nette séparation orange/vert entre la Selection lente et le Background sain. Pris ensemble, ils donnent une signature de ce qui a changé au point d’inflexion.
C’est la bonne forme si vous voulez poser la question « qu’est-ce qui a changé ? » Une variante plus resserrée suit le même principe : lorsqu’un petit groupe de spans lents apparaît dans une bande par ailleurs calme (une brève poussée sur le bord droit, un groupe au milieu d’une période stable), tracez plutôt une petite boîte autour de ce seul groupe. La forme change la question : une bande verticale demande ce qui a changé au fil du temps ; une petite boîte ciblée demande ce qui est particulier dans ce groupe.
Cas d’usage 2 : lent ou rapide
Drill-down itératif
- Filtrer : ne conserver que les spans ayant cette valeur
- Exclure : supprimer les spans ayant cette valeur
- Copier : copier la valeur dans le presse-papiers
Les buckets agrégés Other (N), qui regroupent les valeurs de faible fréquence, ne sont pas cliquables. Pour filtrer une valeur précise dans ce bucket, utilisez directement la barre de recherche.
Personnaliser le heatmap
| Paramètre | Par défaut | Description |
|---|---|---|
| Scale | Log | Log convient aux larges plages de latence ; Linear est plus adapté aux distributions uniformes resserrées. |
| Value | (Duration)/1e6 | N’importe quelle expression numérique : taille de réponse, taux d’erreur, attribut de span personnalisé. |
| Count | count() | Agrégation utilisée pour la couleur. Remplacez-la par avg(), sum(), p95() ou des expressions comme countDistinct(field). |
- Passer Scale à Linear lorsque la plage de latence est étroite (par exemple, un service dont les spans s’exécutent tous entre 5 et 50 ms). L’échelle logarithmique gaspille de l’espace vertical dans la partie haute, là où il n’y a pas de données.
- Tracer autre chose que la durée sur l’axe Y. Définir Value sur
SpanAttributes.http.response.sizepermet d’étudier les réponses lentes et volumineuses ; une expression commeif(StatusCode = 'Error', 1, 0)trace la fréquence des erreurs au fil du temps pour l’ensemble des services. - Colorer selon autre chose que le count. Définir Count sur
p95(Duration)colore chaque bucket selon la tail latency plutôt que selon le volume, ce qui fait ressortir des zones rares mais lentes qu’une vue basée sur le count tend à masquer.countDistinct(TraceId)permet de distinguer le volume de traces du volume de spans lorsqu’une trace produit de nombreux spans.
Conseils pour une utilisation efficace
- Commencez par filtrer sur un seul service. La latence varie fortement d’un service à l’autre, et les mélanger brouille le signal. Utilisez la barre de recherche pour restreindre à un seul
ServiceName(ou à un seul endpoint) avant de commencer, afin que la heatmap et les distributions reflètent une population comparable. - Choisissez des sélections avec un contraste visuel net. Le mode de comparaison fonctionne mieux lorsque la bande Selection se distingue clairement du Background, par exemple une période dégradée qui débute à un moment identifiable, ou une queue lente nettement séparée du gros des données. Les sélections qui se chevauchent largement avec le reste des données ont tendance à faire ressortir du bruit plutôt que le véritable écart.
- Itérez : filtre, heatmap, filtre. Une seule sélection identifie rarement la cause. Considérez la première comparaison comme une hypothèse, filtrez sur la valeur la plus divergente, puis réexaminez la nouvelle heatmap et les distributions. Deux ou trois itérations suffisent généralement à ramener une régression à un ou deux attributs.
- Utilisez le mode de distribution sans sélection lorsqu’aucun contraste n’est encore visible (vous savez qu’il y a un problème, mais la heatmap paraît uniforme). Appliquez un filtre d’hypothèse, par exemple uniquement les spans d’erreur, uniquement les spans client, ou uniquement un endpoint, et laissez les distributions d’attributs vous orienter vers les valeurs ayant le plus d’impact avant de tracer le moindre rectangle.