リソース (APM)
APM のリソースとは、Datadog APM でサービスの中の特定の処理を表す単位で、Web サービスならエンドポイント、データベースサービスなら正規化したクエリ、それ以外ならバックグラウンドジョブがこれに当たる。同じリソース名のスパンが集計され、傾向を読む軸になる。
概要
リソースは、サービスの中の 1 つの処理を表す APM の単位で、GET /productpage のような HTTP メソッドとルートの組や、ShoppingCartController#checkout のような処理名が名前になります。Web サービスでは web.request という固定のスパン名の下に動的なエンドポイントが並び、データベースサービスでは db.query の下に個々のクエリが並びます。取り込みの時点で数値 ID や GUID、クエリパラメーターの値が {num} / {guid} / {val} に置き換えられ、同じ処理が同じ名前に揃います。気にするのは、リソース一覧が ID 入りの名前で膨れて読めなくなったときと、正規化で消えた区別を取り戻したいときです。
サービスの中の 1 つの処理を指す名前
APM のリソースは、サービスの中の特定の処理を表す Datadog APM の単位です (2026 年 9 月時点・出典: APM Terms and Concepts / Resource Page)。公式ドキュメントは典型として、計装された Web エンドポイント、データベースクエリ、バックグラウンドジョブの 3 つを挙げています。名前の例として示されるのは GET /productpage のような HTTP メソッドとルートの組と、ShoppingCartController#checkout のような処理名です。Web ストアのサービスなら、決済、カートの更新、商品の追加といったエンドポイントが自動計装でそれぞれリソースになります。リソースごとにトレースメトリクスが集計され、ダッシュボードやモニターに使えるほか、専用のリソースページが自動で作られます。
スパン名は固定、リソース名は可変という二層
リソースを捉える近道は、スパンの名前とリソースの名前を分けて考えることです。公式ドキュメントの説明では、Web サービスの動的なエンドポイントは web.request という固定のスパン名でまとめられます (2026 年 9 月時点・出典: APM Terms and Concepts)。データベースサービスのクエリは db.query というスパン名の下に並びます。つまりスパン名は「どんな種類の作業か」を表す固定の語で、リソース名は「その作業の中のどの処理か」を表す可変の語です。この二層があるため、同じ web.request のスパンでも、リソース名が違えば別の行として集計され、同じなら 1 つの行にまとまります。エンドポイントがどのサービスに属するかも、この入口スパンの名前で決まります。
- リクエストが届き、入口のスパンが作られる (スパン名 =
web.request) - 入口スパンにリソース名が付く (HTTP メソッドとルート、例:
GET /productpage) - 同じリソース名のスパンがまとめられ、トレースメトリクスとして集計される
- リソースページにリクエスト数、エラー、レイテンシのグラフとして並ぶ
取り込み時の正規化 - {guid} / {num} / {val}
Datadog は取り込みの時点で、スパン名とリソース名に含まれるランダムな GUID、数値 ID、クエリパラメーターの値を固定の文字列に置き換えます。公式ドキュメントはこれを quantization と呼びます (2026 年 9 月時点・出典: Quantization of APM Data)。GUID は {guid}、非英数字に囲まれた 6 桁以上の数字と文字列末尾の数字は {num}、クエリパラメーターの値は {val} に置き換わります。置換はトレースメトリクスの名前、そのメトリクスの resource_name タグ、取り込まれた全スパンのリソース名とスパン名に及びます。例えば末尾に GUID を含むスパン名は find_user_{guid} のように揃い、メトリクス名も trace.find_user_guid.hits の形になります。リソース名の末尾が temp_128390123 のような数字なら temp_{num} に揃います。
なぜ揃えるのか - カーディナリティの外側に出ないため
正規化が既定で入っている理由を、公式ドキュメントは名前の汚染を抑えるためと説明しています。分析の目的では同じ処理であるスパンとリソースを、ランダムな文字列のせいで別物として並べないための措置です (2026 年 9 月時点・出典: Quantization of APM Data)。リソース名はトレースメトリクスのタグになるので、名前の種類の数がそのまま系列の数になります。注文 ID を含む URL や値を埋め込んだ生の SQL がそのまま名前になれば、1 リクエストごとに 1 系列が生まれ、一覧も集計も読めなくなります。伸び方の性質はカーディナリティの項に譲ります。既定の置換で足りないときは、計装側でリソース名を自分で設定するか、Agent の apm_config.replace_tags で独自の置換規則を書きます。ただし名前を変えると新しいメトリクスとタグが生まれるため、置換後の名前に依存していたクエリは更新が必要になると、公式ドキュメントは注意しています。
リソースページで見える指標とエンドポイントの定義
リソースごとにリソースページが自動生成されます (2026 年 9 月時点・出典: Resource Page)。既定のグラフは Requests and Errors、Errors、Latency、Avg Time per Request の 4 つで、レイテンシの分布も並びます。依存マップは、選んだサービスとリソースを通るリクエストに範囲を絞り、上流と下流のサービス依存を流れ図で示します。スパン要約は、そのリソースを含むトレースを対象に、スパンごとの 1 トレース当たりの平均出現数、含まれるトレースの割合、平均所要時間、実行時間に占める平均割合を並べる表で、サービスの入口スパンを含むリソースだけで使えます。リソースがエンドポイント、つまりサービスが特定の URL パスで公開する HTTP リソースに当たる場合は、定義の節が追加されます。データベースクエリの側をさらに深く見るならデータベースモニタリング、どのスパンが検索できる形で残るかはリテンションフィルターの項が担当です。