分散トレーシング
分散トレーシングとは、利用者の 1 つのリクエストが複数のサービスやデータベースを渡り歩く経路を、共通のトレース ID でつないで 1 本の記録として追う手法です。マイクロサービスのように処理が境界をまたぐ構成で、遅さやエラーがどの区間で生じたかを特定するために使います。
概要
分散トレーシングは、1 つのリクエストの処理経路を、フロントエンドからバックエンドのサービスやデータベースまで通して 1 本の記録にまとめる手法です。リクエストの入口で固有のトレース ID を発行し、サービスを呼び出すたびにその ID を一緒に渡すことで、別々のプロセスで生まれた作業の記録を後から 1 本に組み立てます。サービスごとのログを見比べても境界で話が切れてしまうとき、そして「遅い」という申告に対してどのサービスのどの処理が原因かを分単位ではなく処理単位で言い当てたいときに気にする概念です。
1 つのリクエストをサービス越しに 1 本へつなぐ
分散トレーシングは、アプリケーションが受けたリクエストがフロントエンドの端末からバックエンドのサービスやデータベースへ流れていく様子を追跡する手法です (2026 年 9 月時点・出典: Distributed Tracing)。1 台のサーバーで完結するモノリスなら、処理の流れはそのプロセスのスタックを見れば分かります。ところがマイクロサービスでは 1 つの注文処理が認証、在庫、決済、通知といった別々のサービスを次々に呼び出すため、どこで時間を使ったかを追うには、プロセスの境界をまたいで同じリクエストだと分かる仕掛けが要ります。その仕掛けがトレース ID で、これを鍵に組み立てた 1 本の記録が トレース、その中の作業 1 つ 1 つが スパン です。
トレース ID を運び、スパンを親子に積む
仕組みの核は、識別子を次のサービスへ渡し続けることです。リクエストが入口に届くと固有のトレース ID と最初の親スパンが作られ、別のサービスを呼び出すときはトレース ID と親スパン ID を HTTP ヘッダーに埋め込んで送ります。受け取った側はそれを取り出して自分のスパンに同じトレース ID を付け、さらに下流へ渡します (2026 年 9 月時点・出典: APM Terms and Concepts)。この受け渡しをトレースコンテキストの伝播と呼びます。
| 要素 | 何を表すか | どこで生まれるか |
|---|---|---|
| トレース ID | リクエスト 1 件を通して変わらない識別子 | 入口のサービスで 1 度だけ発行 |
| スパン | API 呼び出しやクエリなど 1 単位の作業と、その所要時間とエラー | 作業を行った各サービス |
| 親スパン ID | どの作業から呼ばれたかという親子関係 | 呼び出し時にヘッダーで下流へ渡す |
| メタデータ | 顧客 ID や地域などの付帯情報 | 各スパンに付ける |
スパンが同じトレース ID を持つので、収集側は別々のプロセスから届いた断片を 1 本に組み立て直せます。親スパンを上に、子スパンを発生順に下へ並べて描いたものがフレームグラフで、長い区間とエラーの位置が一目で読めます。
ログだけでは境界で話が切れる
同じことをログで追えないか、という疑問は自然です。ログはアプリケーション、インフラ、ネットワークのどの層からでも出て、1 行ごとに時刻付きで出来事を記録します。ただし各サービスが独立に書き出すため、あるリクエストの行を別のサービスの行と結び付ける鍵が最初からは存在しません。これが無いと、障害調査は 5 つのサービスのログを時刻でにらみ合わせ、どの行が同じ注文のものかを人が推測する作業になります。分散トレーシングはアプリケーション層だけを対象にする代わりに、リクエストが境界を越えていく経路をそのまま見せ、どこで詰まったかを処理単位で指し示します (2026 年 9 月時点・出典: Distributed Tracing)。そこから先、なぜ遅かったのかを掘るときに、そのトレースに結び付いたログを読む、という役割分担が実務の型です。
全部は残せないというサンプリングの妥協
トラフィックの多いシステムでは、スパンが 1 分間に数百万個生まれることがあります (2026 年 9 月時点・出典: Distributed Tracing)。全てを保存し続けるのは費用の面で現実的でないため、一部だけを残すサンプリングが行われます。代表的な決め方は 2 通りです。リクエストの入口で残すか捨てるかを確率で決める方式は head-based sampling と呼ばれ、Datadog でも既定の仕組みです (2026 年 9 月時点・出典: Ingestion Mechanisms)。軽い代わりに、後から重要だと分かる 1 件を最初から捨てている可能性があります。いったん集めてから遅かったものやエラーを含むものを選んで残す方式は取りこぼしが少ない代わりに、選ぶまでの間すべてを受け止める器が要ります。入口で確率的に決める方式で失われやすいのが「稀に起きる悪い 1 件」で、平均的なリクエストの姿はどちらの方式でも十分に残ります。Datadog が案内する「100% 送ってから保持フィルターで残す」組み合わせは トレース の項で説明しています。取り込みを絞る側の仕組みは 取り込みコントロール の項にまとめています。
標準は OpenTelemetry で受け止めるのは APM
伝播の形式や計装の API がツールごとに違うと、あるサービスが付けたトレース ID を別のツールで計装したサービスが読めず、そこでトレースが切れます。この分断を防ぐために、計装の API とデータの形式をベンダーに依存しない形で定めた標準が OpenTelemetry です。Datadog もベンダー中立の計装を望む場合の選択肢として案内しています (2026 年 9 月時点・出典: Application Instrumentation)。受け口の種類と使える機能の差は OpenTelemetry の解説 を参照してください。Datadog で分散トレーシングを実現するのが APM で、Agent の導入時に Single Step Instrumentation を使えばコードを変えずに対応フレームワークのトレース収集が始まります。必要に応じて手動の SDK 設定やコードで書くカスタムスパンを重ねられます。まず自動計装で全体の経路を見えるようにし、遅い区間が分かってからそのサービスにだけ独自のスパンを足す、という順番が手戻りの少ない進め方です。