サービスマップ
サービスマップとは、Datadog APM が集めたトレースからサービス同士の呼び出し関係を自動で描き、依存の全体像と詰まりの場所を 1 枚の図で見せる画面のこと。ノードがサービス、線が呼び出しの集計を表し、枠の色でそのサービスの健全性が分かる。
概要
サービスマップは、APM でトレースを集めているサービスを部品として並べ、観測された呼び出しの向きを線でつないだ図です。APM か RUM を入れていれば追加の設定は要らず、計装したサービスと接続は直後から現れ、対応するトレースが 30 日届かないと自動で消えます。図は env ごとに別のものが描かれ、ファセットやサービス名で絞り込めます。気にするのは、リクエストが遅いのにどのサービスが原因か絞れないとき、知らない外部呼び出しやサービスが増えていないか点検したいとき、サービスの持ち主とチームの境界を確かめたいときです。トレースが 1 本につながる仕組みは分散トレーシングの項に任せ、ここでは画面の読み方に絞ります。
トレースを材料にして依存関係を描く画面
サービスマップは、APM が集めたトレースを材料にして、アプリケーションをサービスという部品に分解し、観測された依存関係をリアルタイムに描く画面です。公式ドキュメントは、ボトルネックの特定と、アーキテクチャの中をデータがどう流れるかの理解に使う画面だと説明しています (2026 年 9 月時点・出典: Service Map)。材料は APM と RUM のデータで、それらを入れていれば追加の設定なしに表示できます。人が構成図を描いて保守するのではなく、実際に流れたリクエストから図が生まれる、という点がこの画面の価値です。設計書に無い呼び出しも、流れていれば線になります。サービスをまたいだリクエストが 1 本のトレースにつながる仕組みは分散トレーシングの項に任せ、ここでは描かれた図の読み方に絞ります。
ノード 1 つが 1 サービス、線 1 本が呼び出しの集計
図の要素はそれぞれ意味が決まっています。ノードは APM で計装されたとおりのサービスで、Software Catalog に並ぶサービスと一致します。線は 1 つのサービスから別のサービスへの呼び出しを集計したもので、個々のトレースのフレームグラフに出る呼び出しの積み重ねです。
| 要素 | 表すもの | 補足 |
|---|---|---|
| ノード | APM で計装された 1 つのサービス | 選んだ時間範囲にデータがあるものだけ描かれる |
| 線 (エッジ) | サービス間の呼び出しの集計 | マウスを重ねると向きが動く線で示される |
| 枠の色 (赤 / 黄) | そのサービスの Service Health | Watchdog の異常、人を呼び出すモニター、インシデントを 1 つの状態にまとめたもの |
| 折りたたまれたノード | 絞り込みで隠れた中継サービス | 絞り込んだ 2 つのサービスが、条件外のサービス経由でつながるときに現れる |
| 消えるまでの期間 | 30 日 | 対応するトレースが 30 日届かないとサービスも線も自動で消える |
公式ドキュメントが色の意味として挙げているのは、Service Health による枠の赤と黄の 2 色だけです。遅延やエラー率の大小は図の見た目ではなく、ノードを開いたサービスの画面で確かめます。図に載るのは選んだ時間範囲にデータがあるサービスだけなので、夜間バッチのように動く時間が限られるサービスは、範囲を広げないと現れません。
絞り込みと範囲の切り替えは別の操作
似ているようで違う操作が 2 つあります。1 つは絞り込みで、サービス名のあいまい一致か、Datadog がサービスに自動で付けるファセットで行います。ファセットには Web サーバー / データベース / キャッシュといったサービスの種類、直近のデプロイ時刻、モニターの状態が含まれます (2026 年 9 月時点・出典: Service Map)。もう 1 つは範囲の切り替えで、図は env と、任意で設定する第 2 のプライマリタグごとに描かれます。別の env を選ぶと、その範囲のサービスだけで構成された別の図に切り替わり、env をまたいで呼び出す線は引かれません。範囲を変えたのに知らないサービスが出てきたときは、この 2 つの操作のどちらを使っているかを先に確かめます。チームやアプリケーション単位のグループ化もでき、サービスの持ち主を図の上で確かめる使い方が公式ドキュメントに挙がっています。
左から右へ読む - 利用者側から根本原因側へ
ノードにマウスを重ねると、そのサービスのリクエストの流れが動く線で示され、どちらからどちらへ呼んでいるかが分かります。クリックして検査 (inspect) に入ると、そのサービスだけが切り出され、左側に呼んでくる側、右側にこのサービスが呼ぶ側が並びます。公式ドキュメントは、左にあるサービスほど利用者に近く、右にあるサービスほど根本原因である可能性が高いと説明しています (2026 年 9 月時点・出典: Service Map)。障害のときの読み方はこの一言に尽きます。利用者に近い入口のサービスが赤くても原因は右側にあることが多いので、赤い枠を右へたどり、その先に赤いサービスが無くなった地点を最初に開く候補にします。検査の画面では各ノードをさらに検査でき、依存関係を 1 段ずつたどれます。タグservice は APM のサービスを識別する特別な鍵で、同じ鍵をホストマップやログに付けておくと、図の各ノードから同じサービスのログやインフラの画面へ移れます。
知らない呼び出し先を見つけたときがサービスマップの出番
設計書と実態がずれたときに、この画面の出番が来ます。図はトレースから生まれるので、誰かが足した外部 API への呼び出しや、廃止したはずのサービスへの線が、構成図を書き直さなくても現れます。逆に、あるべき線が無いのはトレースが届いていない合図です。図が描けない期間があるなら、ルートスパンを含む完全なトレースが揃わなかった可能性を公式ドキュメントは挙げています (2026 年 9 月時点・出典: Service Map)。モニターに service タグを付けておくと、その状態が図の上に出るので、業務指標のモニターをサービスに紐づける入口にもなります。ホストマップとの違いは単位です。ホストマップは機械の箱を六角形で並べ、サービスマップはコードの単位であるサービスと、その間の呼び出しを並べます。箱が健全でも呼び出しが詰まることはあり、その逆もあるので、2 つの図は置き換えではなく重ねて読むものです。