サービス (APM)
APM のサービスとは、Datadog APM で同じ仕事をするプロセスの集まりに付ける名前で、トレースを束ねて性能を集計する最初の単位のこと。エンドポイント群を持つ API や、クエリ群を持つデータベースが 1 つのサービスになり、名前は計装側の設定で決まる。
概要
サービスは、Datadog APM が集めたスパンを最初に束ねる単位で、同じ仕事をするプロセスの集まりに付けた名前です。URL エンドポイントの群を API サービスに、データベースクエリの群を 1 つのデータベースサービスに、定期ジョブの群を crond サービスにまとめる、というのが公式ドキュメントの例です。サービスごとにスループット、レイテンシ、エラー率のトレースメトリクスが集計され、サービスページ、サービスマップ、カタログの並びの単位になります。名前は計装ライブラリの設定と service タグで決まるため、決め方が揺れるとサービスが分裂し、集計も画面も細切れになります。気にするべきなのは計装を入れる前と、サービス一覧が増えて見通しが悪くなったときです。
同じ仕事をするプロセスの集まりに付ける名前
APM のサービスは、同じ仕事をするプロセスの集まりに付ける名前です。公式ドキュメントは Web フレームワークやデータベースを例に挙げます。インスタンスを増減させる単位としてエンドポイント、クエリ、ジョブをまとめたもの、という説明です (2026 年 9 月時点・出典: APM Terms and Concepts / Service Page)。具体例も 3 つ示されていて、URL エンドポイントの群は API サービスに、データベースクエリの群は 1 つのデータベースサービスに、定期ジョブの群は crond サービスにまとまります。トレースを構成するスパンには必ずサービス名が付くので、サービスは APM のデータが最初に束ねられる軸になります。全てのサービスはカタログに並び、サービスマップでは依存の絵の中の 1 つの丸として描かれます。
名前はどこで決まるか - base service と 2 種類の上書き
サービス名の出発点は、計装ライブラリに設定する DD_SERVICE の既定名です。公式ドキュメントはこれを base service と呼びます (2026 年 9 月時点・出典: Base Service, Integration Overrides, and Custom Overrides)。ただしスパンごとに別のサービス名が付くことがあり、それが 2 種類の上書きです。Datadog の SDK がデータベース、キュー、外部依存を表すためにクライアント側のスパンへ自動で別名を付けるのが integration override です。共有ライブラリやミドルウェア層を見分けるために人が手で付けるのが custom override です。環境とリリースの区別は名前に混ぜず、env と version のタグで持たせます。この 3 点セットの意味はタグ付けの解説に譲ります。
| 名前 | 誰が付けるか | 何を表すか |
|---|---|---|
| base service | 計装の設定 (DD_SERVICE) の既定名 | そのプロセス群そのもの |
| integration override | SDK の統合が自動で付ける | クライアントスパンから見たデータベース、キュー、外部依存 |
| custom override | 利用者が手で付ける | 共有ライブラリやミドルウェア層など、サービス内部の特定の部品 |
なぜ期待したエンドポイントがサービスページに出ないのか
サービス名を揃えたのに、あるはずの HTTP エンドポイントがサービスページに並ばないことがあります。公式ドキュメントはこの疑問に注記で答えています (2026 年 9 月時点・出典: APM Terms and Concepts)。エンドポイントとサービスを結びつけるのはサービス名だけではなく、そのトレースの入口となるスパンの span.name も条件になる、という内容です。例として挙がるのは Web ストアのサービスで、入口のスパン名が web.request である場合です。つまり、同じサービス名を名乗っていても入口のスパン名が別物だと、エンドポイントは別の場所に現れます。計装を自分で書いたときや、フレームワークの自動計装と手書きのスパンが混ざったときに、この条件を思い出すと原因に早く着きます。
サービスページで先に見る数字
カタログでサービスを選ぶとサービスページが開きます (2026 年 9 月時点・出典: Service Page)。公式ドキュメントがそこで見られるものとして挙げるのは、サービスの健全性、モニターの状態、Watchdog Insights、サマリーカード、既定のグラフ、リソースの一覧、依存関係の 7 つです。それにデプロイや Error Tracking などの追加セクションが続きます。既定のグラフは Requests and Errors、Errors、Latency、Avg Time per Request の 4 つで、性能の 3 つの顔が並びます。サマリーカードには直近のデプロイ、Error Tracking の問題、SLO、進行中のインシデント、セキュリティシグナルの要約が出ます。リソースの一覧はリクエスト数、レイテンシ、エラー、時間で並べ替えられ、混んでいる処理や壊れている処理を示します。見張りの単位として機能するのは、モニターや SLO をこの単位で置けるからです。
分裂したサービスをどう揃えるか
名前が揺れる典型は、ホスト名、環境名、バージョンをサービス名に混ぜてしまう形です。同じ仕事が別サービスに分かれ、集計もサービスマップも細切れになります。揃えるには、base service を 1 つの DD_SERVICE に決め、環境差は env、リリース差は version のタグに持たせることです。もう 1 つの膨張源が integration override です。公式ドキュメントは、依存先を表す推定エンティティがあれば integration override は不要で、サービス一覧とマップを汚し得ると述べています。不要な上書きは画面か設定の変更で外せます (2026 年 9 月時点・出典: Base Service, Integration Overrides, and Custom Overrides)。課金の単位はホストとスパンの量であり、その仕組みは APM の解説にあります。気にする時期は、計装前に規約を決めるときと、一覧が増えて見通しが悪くなったときです。