Trace Explorerによる詳細分析 - 異常の「真因」を高速に特定する
APMによって収集された膨大なデータは、ただ蓄積されているだけでは宝の持ち腐れです。一日に数百万、数千万件というリクエストが発生する大規模システムにおいて、「特定のユーザーが、特定の条件下で、特定のAPIでエラーを起こした」という針のような事実を探し出すためには、強力な検索エンジンが必要です。
Datadog Trace Explorer は、APMにおける「Google検索」とも言える強力な分析インターフェースです。タグを用いた多次元的なフィルタリング、システムの実行フローを可視化するフレームグラフ、そして全トレースを横断した統計分析を可能にするアナリティクス機能。これらを使いこなすことで、エンジニアは「なぜ遅いのか」「どこでエラーになったのか」という問いに対し、確固たる証拠（エビデンス）を持って答えを出せるようになります。
本記事では、Trace Explorerの基本操作から、フレームグラフの読み解き方、そして高度な分析ワークフローまで、徹底的に解説します。
1. トレースの検索：タグが導く最短ルート
Trace Explorerの最大の強みは、インフラストラクチャ・リストやログ・エクスプローラーと共通の「検索シンタックス」を使用できる点です。
1.1. 頻用される検索クエリの例
- エラーの特定:
@http.status_code:500(500エラーが発生したリクエストを抽出) - パフォーマンス低下の調査:
duration:>2s(処理に2秒以上かかった遅いリクエストを抽出) - 特定サービス・リソースの絞り込み:
service:payment-api resource:"POST /v1/checkout" - 特定ユーザーの影響調査:
@user.id:123456(カスタムタグを付与している場合)
1.2. 検索から解決への流れ（Mermaid図）
2. Flame Graph (フレームグラフ) の読み解き方
トレースをクリックした際に表示される「Flame Graph」は、プログラムの実行履歴を時系列に沿って視覚化したものです。
- 横軸 (Time): 時間の経過を表します。バーの長さがその処理に費やされた時間（Duration）です。長いバーは、そこが全体のパフォーマンスを決定付けている「ボトルネック」であることを示します。
- 縦軸 (Depth): 呼び出しの階層（スタック）を表します。上にあるバーが呼び出し元（Parent）、その下にあるのが呼び出し先（Child）です。
- 色: 通常、サービスごとに色が塗り分けられます。エラーが発生した箇所は赤色の枠線や背景で強調されます。
TIP
フレームグラフで「隙間」がある場合は、Agentが追跡していない外部通信や、アプリケーション内部の重い計算処理（同期処理）が原因である可能性があります。
3. スパン・メタデータと Error Tracking
個別のバー（スパン）をクリックすると、詳細なメタデータが表示されます。
- Tags: HTTPメソッド、クライアントIP、DBクエリなど。
- Error Info: エラーが発生している場合、スタックトレースがそのまま表示されます。
- Error Tracking: Datadogは、似たようなエラーを自動的にグループ化します。「このエラーはこの1時間で300回起きており、特定のバージョン（v1.2）でのみ発生している」といった分析が、何もしなくても提供されます。
4. トレース・アナリティクス：全体傾向の分析
個別のドリルダウンだけでなく、全体を俯瞰して「どのAPIが最もエラー率が高いか」といった統計情報を出すのがアナリティクス機能です。
| 分析手法 | 解決できる疑問 | 活用例 |
|---|---|---|
| Top List | 最も遅いサービス、最もエラーの多いエンドポイントは？ | 改善優先順位の策定 |
| Timeseries | 特定のエラー数は時間とともに増えているか？ | リリース後のデグレ検知 |
| Table | ユーザーごとの平均レスポンスタイムは？ | 特定顧客の満足度調査 |
| Distribution | レイテンシのP99（最悪値）はどの程度か？ | SLA/SLOの遵守状況確認 |
5. 相関分析：ログとメトリクスへの架け橋
Trace Explorerは孤立したツールではありません。Datadogの「Unified Observability」の中心地です。
- View Logs: そのトレースに関係するログだけを、ミリ秒精度の時系列で横に並べて表示します。デバッグ効率が飛躍的に高まります。
- View Infrastructure: トレースが発生した瞬間に、そのホストのCPUやメモリが不足していなかったかを確認できます。
6. セレクターとスパン・プロパティの活用
Trace Explorerでは、標準的なタグ以外にも「スパン・プロパティ」を使用した高度なフィルタリングが可能です。
resource_name: SQLクエリの断片や、エンドポイントのパス。これを用いて「重いクエリ」だけを抽出できます。http.response.headers.x_request_id: 特定のヘッダー情報。カスタマーサポート等で得られたリクエストIDから一発でトレースを探せます。error.type:TimeoutErrorやConnectionRefusedといった例外の型。
これらを「ファセット (Facets)」として登録することで、左側のサイドバーからチェックボックス形式で直感的にフィルタリングできるようになり、調査スピードが劇的に向上します。
7. まとめ：データに「物語」を語らせる
Trace Explorerを使いこなすことは、散らばったパズルのピースを繋ぎ合わせ、一つの「物語」を構築する作業に似ています。
単なる「500エラー」を、「昨日デプロイされたv2.1において、一部の決済リクエストがDBのデッドロックを引き起こし、結果として上位のチェックアウトAPIがタイムアウトした」という具体的なストーリーに変える。この解像度の高さこそが、Trace Explorerがエンジニアに提供する価値です。
まずは、自分のサービスで最も「長いバー」を持つトレースを探してみてください。そこには、これまで見過ごされてきた最適化のヒントや、隠れたバグの予兆が必ず隠されているはずです。
関連記事:
出典: