APM

APM で見えるもの - トレース・サービス・リソース

Datadog APM の中心にあるのは分散トレーシングです。アプリケーションが受けたリクエストがシステムの中をどう流れたかを記録し、Trace Explorer で 1 件ずつ検索・分析できます。また、集計された性能はサービスページとリソースページで見る形になっており、サービスの健全性・パフォーマンスの指標・デプロイ前後の変化を追跡できます (2026 年 8 月時点・出典: Datadog APM ドキュメント)。インフラ監視がホストという「箱」の視点なのに対し、APM は箱の中を通る「処理」の視点で、両者は補完関係にあります。トレースという概念そのものは用語辞典のトレースの項で整理しています。

計装の始め方 - 対応言語と 2 つの方式

トレースを取るにはアプリケーションへの計装 (SDK の組み込み) が必要です。公式の SDK は Java・Python・Ruby・Go・Node.js・PHP・C++・Rust・.NET Core・.NET Framework・Android・iOS に対応しています (2026 年 8 月時点・出典: 対応ライブラリ一覧)。導入方式は大きく 2 つあり、Single Step Instrumentation はコードを変更せず 1 つのコマンドで SDK を自動的に組み込む方式、コードベースのカスタム計装はトレーシング API の呼び出しをコードに書き足して独自のスパンを作る方式です。両者は「SDK を入れる手段」と「スパンを細かく制御する手段」という別の役割なので、併用できます。なお、送信されたトレースは Agent が受け取る構成が前提のため、先に Datadog Agent の導入を済ませておく流れになります。ベンダー中立の計装を選びたい場合は OpenTelemetry で計装したデータを Datadog へ送る経路も公式に案内されています。

トレースをどう読むか

1 本のトレースは、リクエストが通過した処理の単位 (スパン) のつながりでできています。読むときの入口は 2 つあり、個別の遅いリクエストを調べたいときは Trace Explorer から該当のトレースを開いて、どのスパンに時間が費やされたかを確認します。全体傾向をつかみたいときはサービスページから入り、どのサービスのどのリソース (エンドポイントやクエリの単位) でレイテンシやエラーが集中しているかを見ます。「個別の 1 件」と「集計された傾向」を行き来できるのが APM の読み方の基本で、障害調査では傾向から怪しいリソースへ絞り、最後に個別トレースで確定させる順番が定石です。

課金は 2 階建て - ホスト課金とスパン取り込み量

APM の課金はホスト単位の基本料金と、スパンの取り込み量・保持量という 2 階建てで、ここが課金事故の典型ポイントです。課金項目と単位の構造は次のとおりで、具体的な単価は Datadog 料金ページで確認してください。

重要なのは無償割当の仕組みで、取り込みスパンは APM ホスト 1 台につき月 150 GB、Indexed Spans は 1 台につき月 100 万スパン (15 日保持) の割当が全 APM ホストで合算されます。公式 FAQ には、2 ホストで片方 250 GB + 片方 50 GB = 計 300 GB なら追加課金なし、という例が示されています。つまり「ホスト数 × 割当」の総枠を超えた分だけが従量課金になる構造で、トラフィックの多い少数ホスト構成では割当をあふれやすい点に注意が要ります。契約形態の面では、ホスト課金と Indexed Spans は年契約の方がオンデマンドより単価が低く、スパンの追加取り込みは使った GB 数に比例する従量です。

サンプリング設計 - 全量取るか、絞るか

スパンの取り込み量は Ingestion Controls でサービス単位・リソース単位のサンプリングレートとして調整でき、長期に残すスパンは Retention filters で選べます (15 日保持の対象スパンを指定する仕組み・2026 年 8 月時点)。設計判断としては、導入初期は全量に近く取り込んで系全体の実態をつかみ、取り込み量の内訳が見えてきた段階で「量が多いのに調査価値の低いサービス」から絞るのが順当です。最初から強く絞ると、まれにしか起きない遅延やエラーのトレースが取れておらず、いざ調査したいときに手がかりを失います。逆に全量を恒久的に取り続けると、前節の割当を超えた分が 1 GB あたりの従量課金として静かに積み上がります。「どのサービスの、どんなリクエストを、何のために残すか」を言葉にできる状態がサンプリング設計のゴールです。

Lambda・コンテナ環境の注意点

ホスト単位の課金は、常駐するホストが存在しない環境ではそのまま当てはまりません。AWS Lambda には専用の課金単位があり、2026 年 8 月時点ではトレース済み 100 万起動あたりの単価で、1 起動 = 1 トップレベルスパンと定義されています。AWS Fargate などのコンテナ実行基盤にも、トレース済みアクティブインスタンス単位という別建ての料金があり、いずれも年契約とオンデマンドで単価が異なります (出典: Datadog 料金ページ)。サーバーレス中心の構成で APM を見積もるときは、ホスト課金の表ではなくこちらの SKU で計算しないと、見積もりと請求が大きくずれます。起動回数の多い Lambda 関数群では「100 万起動あたり」という課金単位が効いてくるため、どの関数をトレース対象にするかの取捨選択が実質的なコスト設計になります。

導入の向き不向き

APM が最も効くのは、複数のサービスやデータベースが連携していて「遅さの原因がどこにあるか」を切り分けたい構成です。逆に、単一のホストで動くモノリスをそのまま監視したいだけなら、まずログ管理とインフラ監視で足りるかを考える価値があります。料金の構造で見ると、APM はインフラ監視のホスト単価の上に APM 固有のホスト単価が別建てで上乗せされるため、監視ホスト 1 台あたりの支払いはインフラ監視だけの構成より明確に増えます。この上乗せに見合う調査時間の短縮があるか、が判断軸になります。一方で、障害のたびに複数チームがログを突き合わせて数時間を費やしているような組織では、トレース 1 本で因果が追える価値がホスト単価の差をすぐに回収します。