Continuous Profiler

トレースは経路、プロファイルは分布

APM のトレースは 1 つのリクエストがどのサービスのどの処理を通り、各スパンに何ミリ秒かかったかを記録します。これに対してプロファイルは、一定期間にプロセスが使った CPU 時間やメモリ割当を、実行中だった関数ごとに集計したものです。Datadog の Continuous Profiler は CPU / メモリ / I/O のボトルネックをメソッド名 / クラス名 / 行番号まで分解して示す、と公式ドキュメントは説明しています (2026 年 9 月時点・出典: Continuous Profiler)。トレースが答えるのは「この 1 件はなぜ遅かったか」、プロファイルが答えるのは「このサービスは何に時間とメモリを使っているか」です。両者は競合ではなく、解決する問いが違います。

プロファイルの型は CPU だけではない

「プロファイラー = CPU 使用率」と思われがちですが、集められる型は言語ごとに複数あります。Java では CPU / Wall Time / Allocations / Allocated Memory / Live Heap / Class Load / Thrown Exceptions / File I/O / Lock / Socket I/O の 10 種が公式ドキュメントに並びます (2026 年 9 月時点・出典: Profile Types)。CPU は「関数が CPU 上で動いた時間」、Wall Time は「I/O 待ちも含む経過時間」、Live Heap は「未回収のオブジェクトを割り当てた関数」を示し、メモリリーク調査に効きます。この区分があるから、CPU プロファイルが平坦なのに遅いサービスは Wall Time や Lock 側に原因がある、という切り分けを最初の一手で行えます。型の並びは言語で異なるため、自分の言語のページで確かめてください。

どの言語で使えて、何が前提になるか

有効化ページは Go / Java / Node.js / PHP / Python / Ruby / .NET / Rust / C / C++ の 10 言語を並べ、Java には GraalVM ネイティブイメージ向け (Preview) もあります (2026 年 9 月時点・出典: Enabling the Profiler)。JVM 系では Scala / Groovy / Kotlin / Clojure も対象で、Windows の Java では使える型が 4 種に絞られます。前提はホストの Datadog Agent (v7 以上を推奨) と、APM と同じ SDK です。SDK に同梱されているため、APM を既に入れた Java サービスならライブラリの追加は要りません。注意はサーバーレスで、Java のページには「サーバーレスプラットフォームでは非対応」と明記され、一部の言語は AWS Lambda 向けが Preview 段階です (同時点・同出典)。

遅いトレースから該当行へたどる Profiles タブ

分散トレーシングとプロファイラーの両方が有効なプロセスでは 2 つのデータが自動で結び付き、遅いスパンの画面の Profiles タブから、そのスパンの実行中に動いていたコードのプロファイルへ直接移れます (2026 年 9 月時点・出典: Investigate Slow Traces or Endpoints)。Profiles タブにはスパンの期間をスレッドごとに分解したタイムライン表示があり、「Open in Profiling」でフレームグラフに切り替えて幅の広い関数を探す流れです。調査の順番は「遅いエンドポイントを特定 → スパンを開く → 該当コードの行を見る」の一本道になります。前提として、Java ではこの連携は Linux と macOS で既定で有効、Windows では利用できません。手動計装したコードでは、スパンをアクティブなスコープで囲む書き方が連携の条件です (同時点・同出典)。

エンドポイント別に「どの関数が食っているか」を出す

サービス全体のフレームグラフには複数のエンドポイントの処理が混ざります。エンドポイント別プロファイル (Endpoint profiling) はフレームグラフを任意のエンドポイントに絞り込む機能で、応答時間を押し下げるメソッドの特定、CPU / メモリ / 例外を最も消費するエンドポイントの抽出、原因が自分のコードか第三者ライブラリかの判別に使えます (2026 年 9 月時点・出典: Investigate Slow Traces or Endpoints)。「Per endpoint call」では 1 リクエストあたりの消費として見られます。トラフィック増で総 CPU が上がったのか、1 件の処理が重くなったのかは対処が正反対で、この切り替えが区別を付けます。APM のサービスページの Profiling タブでは、レイテンシの変化をコード性能の変化と並べて見られます。無いと原因探しは差分の読み合わせになり、あると遅くなった行の名前を最初から見に行けます。

常時動かしても本番は重くならないのか

公式ドキュメントは、JDK Flight Recorder などの技術でホストの CPU とメモリへの影響を最小限に抑え、全サービスの本番で動かす設計だと説明しています (2026 年 9 月時点・出典: Continuous Profiler)。割合の数値は載っていません。Go の既定値は負荷の高い型 (Block / Mutex) を無効にしており (出典: Enabling the Profiler)、Go の実行トレース記録中はガベージコレクション程度の CPU 増加が起こり得ると注記されています (同時点・出典: Investigate Slow Traces or Endpoints)。保持期間は、フレームグラフ / コールグラフ / スレッドタイムラインは既定 8 日、プロファイルから作るメトリクスは 1 か月保持され、フレームグラフをノートブックへ書き出せば 1 年残ります。8 日でデプロイ前後を比較でき、1 か月のメトリクスで CPU 上位メソッドの推移を追えます。

料金の形は 3 通り - ホスト単価とコンテナ単価と Enterprise 同梱

課金はプロファイルを送るホスト数が基本です。料金の形は 3 通りあります。第一に Continuous Profiler 単体のホスト単価で、年契約が最も低く、月契約とオンデマンドは同じ単価に置かれています。第二にホストライセンスに含まれる割当を超えたコンテナに付くコンテナ単価で、年契約と月契約はコンテナ / 月、オンデマンドはコンテナ / 時という細かい刻みです。第三に APM Pro に Continuous Profiler を同梱した APM Enterprise のホスト単価です (2026 年 8 月時点の SKU 区分・出典: Datadog Pricing)。具体的な単価は同ページで確認してください。

両方を使う前提なら、料金ページで APM のホスト単価に Continuous Profiler のホスト単価を単独で足した合計と、APM Enterprise のホスト単価を比べて選びます。3 段のホスト単価と割当の全体像は APM 料金の解説に委ねます。ホスト単価が積み上がる構造は料金体系の読み解き方を参照してください。

いつ入れるか - APM で当たりを付けてから

プロファイラーは全ホストに最初から入れる種類の道具ではありません。APM で「どのサービスのどのエンドポイントが遅いか」の当たりが付いた後、そのサービスに入れて関数の粒度へ下りる、という順番が費用と効果の両面で合理的です。次の 3 段で考えると迷いません。

常時 on にする層は、CPU のホスト台数がそのまま費用になる高トラフィックのサービスや、ロック待ちが疑われる JVM サービスのように「関数レベルの改善が金額に直結する」層です。そこではプロファイラーのホスト単価が、削れたホスト台数分のインフラ費用で回収できるかを見ます。逆にバッチや社内向けの小さなサービスは、性能問題が出た期間だけ有効にする使い方で足ります。コンテナのオンデマンド単価が時間刻みで設定されている点は、この短期利用と相性が良い設計です。無いと「遅い原因はコードのどこか」で議論が止まり、あるとその議論が行番号の指定で終わる、というのがこの製品が変える会話です。