概要

取り込み制御ページは、Agent とトレーシングライブラリのすべてのサービスに対する取り込み構成に対するきめ細かい可視性を提供します。すべての取り込みメカニズムは公開されており、構成することができます。

取り込み制御ページでは、スパンボリュームを完全に可視化し、完全に制御することができます。その結果、以下のことが可能になります。

• ビジネスと観測可能性の目標に最も関連性の高いデータを取り込みます。
• 未使用のトレースデータを Datadog プラットフォームに送信しないようにすることで、ネットワークコストを削減します。
• 全体のコストをコントロールし、管理します。

トレース取り込み量低減の効果

特定のサービスの取り込み量を減らすことにしても、リクエスト、エラー、およびレイテンシーのメトリクス (RED (Requests, Errors, and Duration) メトリクスとして知られている) は、サンプリング構成に関係なく、アプリケーションの 100% のトラフィックに基づいて計算されているため、100% の精度を維持します。これらのメトリクスは、Datadog APM の購入時に含まれています。アプリケーションのトラフィックを完全に可視化するために、これらのメトリクスを使用して、ダッシュボード、モニター、SLO を作成し、サービスやリソースの潜在的なエラーを発見することができます。

注: アプリケーションやサービスが OpenTelemetry ライブラリでインスツルメンテーションされ、SDK レベルやコレクターレベルでサンプリングを設定した場合、APM メトリクスはデフォルトでサンプルデータセットに基づきます。詳しくは OpenTelemetry による取り込みサンプリングをご覧ください。

トレースデータは非常に反復性が高いため、取り込みサンプリングでも問題を調査するためのトレースサンプルは利用可能です。高スループットのサービスでは、通常、すべてのリクエストを収集する必要はありません。十分重要な問題は、常に複数のトレースで症状を示すはずです。取り込み制御は、予算の範囲内で、問題のトラブルシューティングに必要な可視性を確保するのに役立ちます。

スパンからのメトリクス

スパンからのメトリクスは、取り込まれたスパンに基づいています。

取り込みサンプリングレートを下げると、count タイプのメトリクスに影響があります。** Distribution** タイプのメトリクス、例えば duration メトリクスは、サンプリングがほぼ均一で、レイテンシーの分布がトラフィックを代表するままであるため、影響を受けません。

モニター

スパンからのメトリクスを使用するすべての ** metric** モニターは、取り込み量の減少の影響を受けます。trace.__ メトリクスに基づくメトリクスモニターは、100% のトラフィックに基づいて計算されるため、正確さを維持します。

カウントベースの Trace analytics モニターにも影響があります。モニター管理ページで type:trace-analytics モニターを探し、トレース分析モニターが作成されているかどうかを確認してください。

サービスの取り込み構成を評価する

アプリケーションのインスツルメンテーションの現状を評価するために、Agent とトレースライブラリの構成に関する詳細な情報を提供するトレース取り込み制御ページを活用してください。

月間の取り込み割り当ての範囲内かどうかの把握

取り込み月間使用量 KPI を使用して、APM ホストごとに取り込まれるスパンの月間割り当て 150 GB (すべての APM ホストで合計) と比較して、使用量を推定します。

APM の高度な使用量調査

各サービスごとに取り込み構成を調べることができます。サービス行をクリックすると、Service Ingestion Summary が表示され、以下が示されます。

• Ingestion reason breakdown: どの取り込みメカニズムが取り込み量を担っているか
• Top sampling decision makers: デフォルトの取り込みメカニズムに関して、取り込まれたスパンに対してどの上流サービスがサンプリング決定をしているか

また、取り込みの使用や量に関する過去の傾向をより深く理解するためのすぐに使えるダッシュボードも利用可能です。このダッシュボードを複製すると、ウィジェットの編集やさらなる分析が可能になります。

取り込み量を減らす

取り込み量の大部分を占めるサービスの特定

どのサービスが取り込み量の大部分を占めているかを確認するには、表を Downstream Bytes/s でソートします。この列では、どのサービスがサンプリング決定の大部分を行い、それが下流のサービスにも影響を及ぼしているかを見分けることができます。

サービスがトレースを開始している場合、Downstream Bytes/s には、サービスがサンプリング決定を行った下流サービスからのスパン量も含まれます。

Traffic Breakdown 列を見ると、サービスのサンプリング構成がよくわかります。

Downstream Bytes/s レートが高く、サンプリングレートも高いサービス (トラフィック内訳列の青く塗りつぶされた部分として表示) の場合、このサービスのサンプリングレートを下げると、取り込み量に高い影響を与えることが予想されます。

Agent レベルで取り込みサンプリングレートをグローバルに構成する

The Configuration column tells you whether or not your services are configured with sampling rules. If the top services are labelled with AUTOMATIC configuration, changing the Agent configuration will reduce the volume globally accross services.

Agent レベルで取り込み量を減らすには、DD_APM_MAX_TPS (デフォルトでは 10 に設定) を構成して、ヘッドベースのサンプリング量のシェアを減らしてください。デフォルトのサンプリングメカニズムについて詳しくはこちら。

注: この構成オプションは、Datadog トレーシングライブラリを使用しているときのみ有効になります。Agent の OTLP Ingest が OpenTelemetry でインスツルメンテーションされたアプリケーションからデータを収集する場合、DD_APM_MAX_TPS を変更しても、トレーシングライブラリで適用されるサンプリングレートは変わりません。

さらに、エラーやレアトレースの量を減らすには

• エラーサンプリングのシェアを減らすために、DD_APM_ERROR_TPS を構成します。
• DD_APM_DISABLE_RARE_SAMPLER を true に設定すると、レアトレースのサンプリングが停止します。

ライブラリレベルでサービスの取り込みサンプリングレートを独立して構成する

一部の高スループットサービスのサンプリングレートを構成することで、「超過」取り込み量の大部分を低減することができます。

サービスをクリックすると、Service Ingestion Summary が表示されます。サイドパネルの Ingestion reasons breakdown をご覧ください。各メカニズムに起因する取り込み量のシェアの概要を確認することができます。

取り込み量のほとんどの主な理由がヘッドベースサンプリング (auto または rule) である場合、トレースライブラリレベルでサンプリングルールを設定することで、取り込み量を構成することができます。

サービスのサンプリングレートを構成するには、Manage Ingestion Rate ボタンをクリックします。サービスの言語と適用したい取り込みサンプリングレートを選択します。

注: 構成の変更を適用するには、アプリケーションを再デプロイする必要があります。Datadog では、環境変数を設定することで変更を適用することを推奨しています。

OpenTelemetry によるトレースサンプリング

アプリケーションやサービスが OpenTelemetry ライブラリでインスツルメンテーションされ、OpenTelemetry コレクターを使用している場合、以下の OpenTelemetry サンプリング機能を使用することができます。

• TraceIdRatioBased と ParentBased は、SDK レベルで trace_id に基づく決定論的なヘッドベースサンプリングを実装することができる 2 つの組み込みサンプラーです。
• Tail Sampling Processor と Probabilistic Sampling Processor は、コレクターレベルで一連のルールに基づいてトレースをサンプリングすることが可能です。

2 つのオプションのいずれかを使用すると、APM メトリクスのサンプリングが行われます。

取り込み理由の用語集

どの取り込みメカニズムが取り込み量の大部分を担っているのかを把握する

トレースをサンプリングするデフォルトのメカニズムは、ヘッドベースサンプリングです。トレースをサンプリングするかどうかの判断はライフサイクルの最初に行われ、 常に完全なトレースを表示して分析できるようにするために、 リクエストのコンテキストで下流に伝搬されます。

ヘッドベースサンプリングは、トレースライブラリまたは Datadog Agent から構成可能です。

その他のいくつかの取り込み理由は、Ingestion Control ページと datadog.estimated_usage.apm.ingested_bytes メトリクスのタグとして表示されます。これらの取り込み理由は、取り込み量の原因になっている可能性があります。

さらに、サンプリングされたスパン量には、他の製品が関与している可能性があります。

• synthetics と synthetics-browser: API およびブラウザテストは、テストによって生成されたトレースに接続されています。
• rum: Web アプリケーションやモバイルアプリケーションからのリクエストは、対応するバックエンドのトレースとリンクしています。
• lambda と xray: X-Ray または Datadog ライブラリでインスツルメントされた AWS lambda 関数から生成されたトレース。

取り込みの理由については、取り込みメカニズムに関するドキュメントを参照してください。

その他の参考資料

お役に立つドキュメント、リンクや記事:

取り込み制御ページドキュメント