トレース
リクエスト 1 件の処理にかかった時間とその結果を追いかけるための記録です。Datadog の APM では、1 つ以上のスパンが集まって 1 本のトレースになります。
概要
Datadog の公式ドキュメントは、トレースをアプリケーションがリクエストを処理するのに費やした時間とそのリクエストの状態を追跡するために使うものと説明しています。トレースは 1 つ以上のスパンで構成され、スパンどうしは親子の関係で結ばれます。1 件のリクエストが複数のサービスを渡り歩く構成では、識別子をサービス間で受け渡すことで、ばらばらに記録されたスパンが 1 本のトレースとして縫い合わされます。個々の処理の速さを測るだけでなく、どの区間で時間を使ったのかを 1 件単位で追えるところが、集約された数値だけを見る監視との違いです。
トレースは 1 件のリクエストの通り道をまとめたもの
トレースの役割は、リクエストの処理時間とその状態を 1 件単位で残すことです。中身は 1 つ以上のスパンで、スパンには親となるスパンの識別子が付くため、全体としては入り口のスパンを根に持つ枝分かれした形になります。入り口となるスパンは、そのトレースの起点として扱われます。
- 入り口のスパン: 受け取ったリクエストそのものを表す
- その子: 認証処理や外部 API の呼び出し
- さらにその子: データベースへの問い合わせ
- 各スパンが持つ親の識別子が、この階層をつなぎ止めている
この形になっていることの利点は、遅さの原因を差分で語れる点です。全体で 800 ミリ秒かかったという事実だけでは打ち手が決まりませんが、内訳のうち特定の問い合わせが大半を占めていると分かれば、手を入れる場所が 1 つに絞れます。平均値の集まりからは、この内訳は復元できません。
サービスをまたいでも 1 本になる仕組み
複数のサービスにまたがるリクエストを 1 本として扱うために、Datadog はトレースコンテキストの伝播という方法を使います。公式ドキュメントの説明では、トレースの識別子や親スパンの識別子といった値を HTTP ヘッダーへ差し込み、リクエストがシステムを流れていくときに一緒に運びます。受け取った側はその値を取り出してトレースを続け、Datadog は個々のスパンを 1 つの分散トレースへ縫い合わせます。 ここから素直に導けるのは、識別子が運ばれない経路では 1 本にならないということです。つなぎ目に計装されていない仕組みが挟まっていて、そこでヘッダーが引き継がれなければ、下流のスパンは別のトレースとして記録されます。トレースが途中で切れているように見えるときは、遅いサービスを探す前に、境界で識別子が渡っているかを確かめる方が早く原因に届きます。切れ目は性能の問題ではなく受け渡しの問題として現れるからです。
サービスとリソースという 2 つの読み方の軸
トレースを読むときには、2 つの語彙が繰り返し出てきます。公式ドキュメントはサービスを、マイクロサービス構成の構成要素であり、エンドポイントやクエリやジョブをまとめたものと説明します。リソースは、計装されたウェブのエンドポイントやデータベースのクエリ、背後で動くジョブといった、アプリケーションの特定の領域を表すものです。GET /productpage のような値がリソース名の例として挙げられています。 定義から素直に出てくる注意点として、リソース名にリクエストごとに変わる値を混ぜないという設計判断があります。リソースは特定の領域を表すという位置づけなので、名前に個別の識別番号が入ると、同じ種類の処理が別物として並び、まとめて傾向を見ることができなくなります。パスの一部が可変になるエンドポイントを扱うときに、この設計が効いてきます。名前の付け方を先に決めておくと、あとから画面が使いものにならなくなる事態を避けられます。
全部見える時間と、残る時間は別に決まる
運用で最初につまずくのは、取り込みと保持が別の設定だという点です。2026 年 8 月時点の公式ドキュメントによると、取り込みの制御ではトレースを最大で全量まで送り、ライブ検索と分析の対象として 15 分間扱えます。一方、保持フィルターはタグを基準にどのスパンを Datadog 側に索引付けするかを決め、その対象は 15 日間保持されます。公式ドキュメントが勧める組み立ては、全量を取り込み、そのうえで業務上意味のあるトレースを保持フィルターで 15 日間残すという形です。 この分離を知らないと、調査の途中で記録が消えたように見えます。実際には、全量が見えるのは直近の 15 分だけで、それより前は保持フィルターで選ばれたものしか残っていません。だからこそ、保持フィルターの条件は事故が起きてから考えるものではありません。エラーを含むトレース、決済のような業務上重要な経路、遅さが問題になる区間を、あらかじめ条件として書いておく必要があります。
気にし始める時期と、混同されやすい点
トレースを意識するのは、監視対象が 1 つのアプリケーションから複数のサービスの連携に変わったときです。単体で動いているうちは処理時間のメトリクスとログで足りますが、呼び出しが連鎖し始めると、どこで時間を使ったのかを 1 件単位で追えなければ原因の切り分けが進みません。 混同されやすい点を 3 つ挙げます。第一に、トレースをログの一種と考えること。ログは出来事の記録ですが、トレースは 1 件のリクエストの構造そのものを持ち、親子関係をたどれる点が違います。第二に、全量を取り込む設定にしたから全部後から調べられると考えること。全量が扱えるのは 15 分間で、その先は保持フィルターの結果次第です。第三に、1 件のリクエストが 1 つのスパンに対応すると考えること。トレースは 1 つ以上のスパンで構成され、内訳が分かることに価値があります。 用語の一次情報は Datadog の公式ドキュメント APM Terms and Concepts にあります。ここで触れた保持と取り込みの期間は 2026 年 8 月時点の記述です。トレースを集めて調査に使う製品側の仕組みは APM の解説で詳しく説明しています。