- 分布モード (常時有効) : ヒートマップ上で選択範囲がない場合、現在のスパン集団における各属性の値の分布が表示されます。支配的な値や、異常にまれな値 (カーディナリティの外れ値) を見つけるのに役立ちます。
- 比較モード: ヒートマップ上で長方形をドラッグすると、その内側のスパン (Selection) と外側のすべて (Background) を比較できます。偏りや逸脱の切り分けに役立ちます。
- 反復的ドリルダウン: 任意のバーをクリックすると、その値で絞り込み (または除外) できます。ヒートマップは絞り込み後の集団に対して再描画されるため、原因が明らかになるまでさらに絞り込めます。
前提条件
はじめに
- Data Source ドロップダウンから、トレースを保持しているログソースを選択します。ログソース名は任意ですが、重要なのは、そのログソースが Trace タイプとして設定されていることです。イベントデルタ タブは、そのようなログソースでのみ有効です。
- Analysis Mode セクションで、イベントデルタ タブをクリックします。
ヒートマップ
- X axis: 時間
- Y axis: 数値 (既定ではスパンの継続時間 (ミリ秒、対数スケール) )
分布モード: カーディナリティの外れ値
- 高頻度: どのサービス、エンドポイント、ステータスコード、またはホストがスパン全体の大半を占めているでしょうか。多くの場合、トラフィックの大部分を占める単一のテナント、バージョン、またはルートが浮かび上がります。
- 低頻度: 出現はするものの、まれな値です。
0.5%のスパンにしか現れないステータスコードや、ほとんど現れないホストは、むしろ最も興味深いシグナルかもしれません。回帰や問題のある要因は、このロングテールに潜んでいます。
比較モード: 通常状態からの逸脱
ユースケース 1: 回帰の前後
SpanKind、SpanName、ScopeName はいずれも、遅い Selection と正常な Background の間で、オレンジと緑がくっきり分かれています。これらを合わせて見ると、変曲点で何が変わったのかを特定できます。
これは、「何が変わったのか?」を知りたいときに適した形です。より絞り込んだバリエーションでも、同じ手順を使えます。静かな帯の中に遅いスパンの小さな塊がある場合 (右端の短いバーストや、安定した期間の途中にあるクラスターなど) は、そのクラスターだけを小さなボックスで囲んでください。形が変われば、問いも変わります。縦長の帯は 時間の中で何が変わったか を問い、小さく絞ったボックスは このクラスターに特有なのは何か を問います。
ユースケース 2: 遅いものと速いもの
段階的なドリルダウン
- Filter: この値を持つ スパン のみを残します
- Exclude: この値を持つ スパン を除外します
- Copy: 値をクリップボードにコピーします
出現頻度の低い値をまとめた集計 Other (N) バケットはクリックできません。そのバケット内の特定の値でフィルタするには、検索バー を直接使用してください。
ヒートマップをカスタマイズする
| パラメーター | デフォルト | 説明 |
|---|---|---|
| Scale | Log | Log は広い latency の範囲に適しています。狭く uniform な分布には Linear のほうが適しています。 |
| Value | (Duration)/1e6 | レスポンスサイズ、エラー率、カスタムの スパン attribute など、任意の数値 expression を指定できます。 |
| Count | count() | 色分けに使う aggregation です。avg()、sum()、p95()、または countDistinct(field) のような expression に切り替えられます。 |
- latency の範囲が狭い場合 (たとえば、すべての スパンs が 5~50 ms で実行される service) には、Scale を Linear に切り替えます。Log スケールでは、データが存在しない上側の領域に縦方向の表示範囲が無駄に使われます。
- Y 軸に Duration 以外をプロットします。 Value を
SpanAttributes.http.response.sizeに設定すると、低速でサイズの大きいレスポンスを調査できます。if(StatusCode = 'Error', 1, 0)のような expression を使うと、services 全体にわたる時間経過ごとのエラー頻度をプロットできます。 - count 以外で色分けします。 Count を
p95(Duration)に設定すると、各 bucket は件数ではなく tail latency に応じて色分けされるため、count ベースのビューでは埋もれてしまう、まれでも低速な領域を浮かび上がらせることができます。countDistinct(TraceId)を使うと、1 つの trace が多数の スパンs を生成する場合に、trace volume と span volume を区別できます。
効果的に使うためのヒント
- まずは 1 つのサービスに絞り込みます。 レイテンシはサービスごとに大きく異なるため、複数を混在させるとシグナルが埋もれてしまいます。作業を始める前に検索バーで 1 つの
ServiceName(または 1 つのエンドポイント) に絞り込み、ヒートマップと分布が比較可能な母集団を反映するようにします。 - 視覚的なコントラストが明確な Selection を選びます。 比較モードは、Selection の帯が Background とはっきり区別できるときに最も効果を発揮します。たとえば、はっきりした時点から始まる性能劣化の期間や、大半のデータから明確に分離した遅いテールなどです。残りのデータと大きく重なる Selection では、実際の差異ではなくノイズが目立ちやすくなります。
- filter、heatmap、filter の順で繰り返します。 1 回の Selection だけで原因を特定できることはほとんどありません。最初の比較は仮説と捉え、最も差が大きい値で filter し、更新されたヒートマップと分布を再確認します。通常は 2 ~ 3 回繰り返すことで、リグレッションの原因を 1 ~ 2 個の属性まで絞り込めます。
- まだコントラストが見えない場合は、Selection なしで分布モードを使います (問題があることはわかっていても、ヒートマップが均一に見える場合) 。error スパンs のみ、client スパンs のみ、または 1 つのエンドポイントのみに絞るといった仮説ベースの filter を適用し、長方形を描く前に、属性の分布から影響の大きい値を見つけます。