Universal Service Monitoring

結論 - 計装なしで見えるのはサービスの健全性まで

USM の線引きを最初に固めます。公式ドキュメントは USM を「コードを計装せずに、スタック全体のサービス健全性メトリクスを見る」機能と定義し、設定済みの Datadog Agent と統合サービスタグ付けだけに依存すると説明しています (2026 年 9 月時点・出典: Universal Service Monitoring)。出力として挙げられているのはリクエスト数 / エラー / 所要時間のゴールデンシグナルと、カタログやサービスマップに載る依存関係で、個々のリクエストがサービスの中でどの処理を通ったかというスパン単位の情報は挙げられていません。それは APM のトレースの領分です。

この表の上 2 行だけで足りる場面が意外に多く、そこを USM に任せると、APM の計装工数とホスト単価を「下 2 行が本当に要るサービス」へ集中できます。

前提は Agent と system-probe、対応 OS とコンテナ環境

前提になるのは Agent の system-probe です。設定ページ (2026 年 9 月時点) では、Agent 6.40 / 7.40 以上、Linux カーネル 4.14 以上、Windows 2012 R2 以上、対応プロトコルは HTTP / HTTPS (OpenSSL) です (出典: Setting up USM)。前提は、Linux はサービスがコンテナで動くこと (コンテナ外は Preview)、Windows は VM 上で動くことです。GKE Autopilot は system-probe が使えず対象外です。追加プロトコルと暗号化方式は Preview で、設定ページの項目は Go / Node.js の TLS、Istio (Agent 7.50 以上)、HTTP/2、Kafka Console です (同時点・同出典)。判定は「Linux のコンテナか Windows の VM か」「HTTP / HTTPS か」の 2 点でほぼ済みます。

サービス名はどこから来るのか

計装なしで「どのサービスか」を判別する鍵は環境変数です。USM はプロセスの起動時に存在する環境変数からサービス名を検出し、Linux では /proc/PID/environ、Windows ではシステム API から読み取ると公式ドキュメントは説明しています (2026 年 9 月時点・出典: Setting up USM)。前提条件として統合サービスタグ付けの env タグをデプロイに付けることが必須で、service と version は任意です。任意でも service を付けなければ、カタログで同じサービスが別名で並ぶ原因になります。つまり USM は「コードに手を入れない」機能ですが、「デプロイ定義に手を入れない」機能ではありません。Kubernetes のマニフェストや ECS のタスク定義に タグを 3 つ書く作業は残り、その 3 つが APM を後から入れたときにも同じサービスとして繋がる接着剤になります。

見えるものはカタログとサービスマップと 3 つの指標

Agent の設定後、約 5 分でサービスがカタログに現れると公式は案内しています。サービスページの左上に universal.http.server (受信) か universal.http.client (送信) の操作名が出ていれば USM 由来です (2026 年 9 月時点・出典: Universal Service Monitoring)。できることは、カタログとサービスマップでサービスと依存関係を可視化すること、サービスページでゴールデンシグナルを見て Deployment Tracking でコード変更と突き合わせること、universal.http.* メトリクスからモニター、ダッシュボード、SLO を作ることの 3 つです。効くのは最後の項目で、計装していないサービスにも「エラー率 1% 超で通知」「月間 99.9% の可用性」という運用の型を、計装済みと同じ書式で当てられます。監視の抜けが「計装したか」で決まる状態から抜けられるのが価値です。

APM との段差はどこにあるか

USM と APM の段差は 3 つあります。まず粒度で、USM の出力はサービス単位のメトリクスで、1 リクエストの中の DB 呼び出しや外部 API の所要時間というスパンの内訳は APM の計装が作ります。次にプロトコルで、USM の対応は HTTP と HTTPS (OpenSSL) で、追加のプロトコルと暗号化方式は Preview です (2026 年 9 月時点・出典: Setting up USM)。最後に動作の場所で、USM は Agent 側の別プロセスとして動くため、アプリのコード内で実行時に設定した環境変数は検出できず、アプリ内で動く APM の計装ライブラリは読める、と同ページの制限事項にあります。この 3 つ目は「APM ではサービス名が付くのに USM では別名になる」現象の原因で、対処は環境変数をアプリ起動前にデプロイ定義で設定することです。段差を知っていれば、USM と APM の数字が食い違っても「見ている層が違う」と読めます。

料金はどう考えるか - 単独の SKU は公開表に無い

2026 年 8 月時点の公式料金ページに USM は独立した SKU として載っておらず、課金に関する公式ドキュメントの料金ページにも USM の項はありません (2026 年 9 月時点)。したがって本記事では単価を書かず、契約上の扱いは Datadog Pricing の公開価格表と営業窓口での確認に委ねます。費用の考え方で確かなのは 2 点です。ひとつは、USM は Agent を置いたホストで動くため、そのホストがインフラ監視の課金対象 (Pro / Enterprise のホストあたり月額) に既に入っている構成が前提になること。もうひとつは、USM は SDK を要求しないため、APM を入れる前の段階で全サービスの健全性を揃えられ、APM のホスト単価を払う対象を後から選べることです。SKU の積み上がり方は料金体系の読み解き方を参照してください。本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。

USM で足りる条件、APM が要る条件

線引きを条件の形にすると次のようになります。

他チームが持つサービスの方が多い組織では、USM が最初に効く相手は自分のサービスではなく隣のチームのサービスです。右の列は「直す人がいて、直すために内訳が要る」サービスに限られます。この分け方をすると、APM の計装工数とホスト単価を、それが本当に効く少数のサービスに集中させる根拠ができます。ホスト間の通信フローを見るネットワーク監視とは見る層が異なり、USM はサービス単位の HTTP の健全性を担当します。

段階移行の順番は USM から APM へ

USM は APM の代替ではなく、APM をどこに入れるかを決めるための最初の一段です。順番は次の 3 段で考えます。

この順番の利点は、1 段目でタグを揃える作業が 2 段目と 3 段目にそのまま効くことです。コンテナ監視のために置いた Agent と、そのタグが USM の前提を満たし、後から APM を入れても同じサービスとして繋がります。逆に APM から始めると、計装したサービスだけが見え、計装していないサービスは監視の外に残るため、「見えている範囲」と「動いている範囲」がずれたまま運用が進みます。無いと監視の網は計装の有無で穴だらけになり、あると全サービスの健全性を同じ画面で並べたうえで深掘りの対象を選べる、というのが USM の変える景色です。