取り込みコントロール

概要

取り込みコントロールは、アプリケーションが Datadog へ送るトレースのうちどれを取り込むかを決める仕組みと、その状況を一覧する画面を指します。サービスごとに取り込み量と内訳が並び、サンプリングで対象外になった分、送信元のレート制限で破棄された分、Agent の資源不足で欠けた分を色で見分けられます。レートの決め方は月あたりの量の目標を伝える方式とリソース単位の手動設定の二通りで、条件を満たせば再デプロイなしに反映できます。

絞るのは送る量で、集計する量ではない

取り込みコントロール (Ingestion Control) は、アプリケーションが Datadog へ送る トレース のうち、どれを実際に取り込むかを決める仕組みと、その状況を一覧する画面のことです。名前のとおり量を絞る機能ですが、絞られるのは送られてくるトレースだけで、レイテンシやエラー率といった APM のメトリクスは常にすべてのトレースから計算されます。サンプリングの設定を変えてもグラフの数値が痩せないのは、この二段構えのためです。画面の上部には直近 1 時間の取り込み量と、そこから見積もった月間の使用量が並びます。サービス単位の表は datadog.estimated_usage.apm.ingested_spans と datadog.estimated_usage.apm.ingested_bytes という利用量メトリクスで作られていて、サービス名・環境・取り込み理由のタグで切り分けられます。どのサービスがどれだけ送っているかを、推測ではなく数字で確かめられる場所だと考えるとよいでしょう。取り込んだトレースの量は APM の使用量としてそのまま費用に効いてくるため、公式ドキュメント もこの画面を取り込み量の予算を管理する入り口として位置づけています (2026 年 8 月時点)。どこまでの可視性を保ち、どこから先を絞るかという釣り合いを、数字を見ながら決められることがこの仕組みの存在意義です。

内訳の色が破棄の理由を示す

サービスごとの行には、送られたトレースの行き先を色で分けた内訳が表示されます。減っている事実だけでなく、なぜ減ったのかが色で分かる点が重要です。

最後の赤い分類だけは設定の結果ではなく事故です。欠けたトレースは前後のつながりを追えなくなるので、割り当てる CPU とメモリを増やして解消します。

レートの決め方は二通りある

サービスごとの取り込み量を調整する方法は二通り用意されています。ひとつは適応的なサンプリングで、月あたりの取り込み量の目標を伝えると、Datadog がサービスのレートを自動で調整し続けます。すべてのサービスとエンドポイントを見える状態に保ったまま、量の上限だけを決めたいときに向きます。もうひとつはリソース単位の手動設定です。エンドポイントなどのリソース名ごとに割合を書き、ワイルドカード (*) を使えば似た名前をまとめて指定できます。重要な決済処理だけ全件、健全性確認は数パーセント、といった濃淡を自分で決めたい場合はこちらです。どちらも、Remote Configuration (リモート設定) を使える環境なら Datadog の画面からサービスを再デプロイせずに反映できます。その条件は、Datadog Agent 7.41.1 以上、Remote Configuration の有効化、APM の Remote Configuration を書き込める権限、そして言語ごとに定められた SDK の最低版 (Java なら v1.34.0 など) です (2026 年 8 月時点)。設定ファイルを生成して手元で適用し、再デプロイする経路が使えるのはリソース単位の手動設定だけで、適応的なサンプリングを使うには Remote Configuration の条件を満たす必要があります。

ルールが無いときに働く三つの既定値

サービス側に何もルールを書いていない場合、判断は Datadog Agent に委ねられます。既定では Agent ごとに毎秒 10 トレースを目標としてレートが自動計算され (2026 年 8 月時点)、環境変数 DD_APM_TARGET_TPS か Remote Configuration でこの目標値を変えられます。それだけでは失敗や珍しい処理が取りこぼされるため、二つの補助が用意されています。エラーを含むトレースは目標から漏れた分も Agent ごとに毎秒 10 件まで拾われ (DD_APM_ERROR_TPS)、出現頻度の低いトレースは毎秒 5 件まで拾えますが、こちらは既定で無効です (DD_APM_ENABLE_RARE_SAMPLER)。障害調査で見たいのは平均的な成功例よりも失敗例と稀な例なので、この二つの存在は覚えておく価値があります。これらの値も Remote Configuration なら Agent の再起動なしに反映できます (Agent 7.42.0 以上)。リモートで指定した値は、環境変数や設定ファイルに書いたローカルの値より優先されます。

設定が重なったときに勝つのはどれか

同じサービスに複数の場所から設定が入ることは珍しくありません。優先順位は次の順で、上にあるものが下を上書きします。

この六段は三つの原則に言い換えられます。送信元ライブラリの設定は Agent の設定より強く、個別のルールは全体の割合より強く、リモートの設定は手元の設定より強い、という順序です。意図した割合にならないときは、まず上位の層に別の設定が残っていないかを疑うとよいでしょう。

実効レートの揺れと、上流で決まる量

一点目は、短い期間で見た実効レートです。1 時間から 4 時間程度の窓では、100 パーセントに設定していても表示される実効レートが 100 パーセントを下回ることがあります。これは統計的な収束の都合で、設定が効いていないわけではありません。判断は窓を広げてから行います。二点目は、自分の設定だけでは量が決まらないサービスがあることです。トレースを最初に受け取ったサービスがサンプリングの判断を下すと、その判断は下流のサービスにも引き継がれます。そのため、上流から呼ばれる側のサービスは、自分の画面を触っても量が変わらないことがあります。画面の取り込み理由と、判断を下したサービスの一覧を見れば、量の出どころをたどれます。詳細は Datadog の Ingestion Controls を参照してください。