- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
トレースデータは反復される傾向があります。アプリケーションの問題が、たった 1 つのトレースで特定され、他のトレースがないことはほとんどありません。高スループットのサービス、特に注意を要するインシデントの場合、問題は複数のトレースで繰り返し症状が現れます。その結果、サービスやエンドポイントのトレースやトレース内のスパンをすべて収集する必要はありません。Datadog APM 取り込み制御メカニズムは、問題のトラブルシューティングに必要な可視性を維持しながら、ノイズを削減し、コストを管理するのに役立ちます。
取り込みの仕組みは、Datadog Agent と Datadog トレーシングライブラリ内の構成です。OpenTelemetry SDK を使用してアプリケーションのインスツルメンテーションを行っている場合は、OpenTelemetry による取り込みサンプリングをお読みください。
このガイドでは、遭遇する可能性のある主なユースケースに応じて、いつ、どのように取り込み制御の構成を使用するかを理解するのに役立ちます。本書は、以下の内容をカバーしています。
Datadog 環境で現在使用されている取り込みメカニズムを確認するには、Ingestion Control ページに移動してください。
この表は、サービス別の取り込みボリュームに関する洞察を提供します。構成列は、現在のセットアップの最初の指標となります。これは、次のことを示しています。
AUTOMATIC
となります。Datadog Agent の取り込みロジックの仕様については、こちらをご覧ください。CONFIGURED
となります。サービスをクリックすると、各サービスで使用されているサンプリングの決定要因 (Agent やトレーシングライブラリ、ルールやサンプルレートなど) や、取り込みスパンのサービスで利用されている取り込みサンプリングメカニズムの詳細を確認できます。
上記の Service Ingestion Summary の例では、Ingestion reasons breakdown テーブルに、このサービスの取り込み理由のほとんどが rule
(ユーザー定義サンプリングルール) に由来することが示されています。
このサービスのトップサンプリング決定要因は、web-store
サービスが、web-store
、shopist-web-ui
、shipping-worker
、synthetics-browser
、product-recommendation
からサンプリング決定を受けることを示しています。これらの 5 つのサービスはすべて、web-store
のサービススパンに影響を与える全体的なサンプリング決定に寄与しています。Web ストアの取り込みを微調整する方法を決定する場合、5 つのサービスすべてを考慮する必要があります。
トランザクショントレース全体を取り込むことで、個々のリクエストに対するエンドツーエンドのサービスリクエストの流れを可視化することができます。
完全なトレースは、ヘッドベースサンプリングメカニズムで取り込むことができます。トレースが作成されたときに、トレースを維持するか削除するかの決定は、トレースの最初のスパン、ヘッドから決定されます。この決定は、リクエストコンテキストを通じてダウンストリームサービスに伝搬されます。
Datadog Agent は、トレースの保持と削除を決定するために、アプリケーショントラフィックに基づいて、トレース作成時に適用する各サービスのデフォルトサンプリングレートを計算します。
また、サービスごとにサンプリングレートを構成することで、Agent のデフォルトサンプリングレートをオーバーライドすることができます。詳しくは、特定のサービスに対してより多くのトレースを保持する方法を参照してください。
デフォルトのサンプリングレートは、Agent ごとに 1 秒間に 10 個の完全なトレースを目標に計算されています。これはトレースの目標数であり、一定期間のトレースを平均化した結果です。これはハード的な制限ではありません。また、トラフィックの急増により、短時間のうちに Datadog に送信されるトレースが大幅に増加することがあります。
Datadog Agent のパラメーター max_traces_per_second
または環境変数 DD_APM_MAX_TPS
を構成することで、この目標を増減することができます。ヘッドベースサンプリングの取り込みメカニズム]5の詳細はこちらをご覧ください。
注: Agent の構成を変更すると、この Datadog Agent にトレースを報告するすべてのサービスのパーセントサンプリングレートに影響します。
ほとんどのシナリオで、この Agent レベルの構成は割り当てられたクォータ内にとどまり、アプリケーションのパフォーマンスを十分に可視化し、ビジネスのための適切な意思決定を支援します。
サービスやリクエストがビジネスにとって重要なものである場合、その可視性を高めたいと思うものです。Datadog に関連するすべてのトレースを送信して、個々のトランザクションを調べることができるようにするとよいでしょう。
デフォルトでは、サンプリングレートは、Datadog Agent あたり 1 秒あたり 10 トレースを目標に計算されます。トレーシングライブラリでサンプリングルールを構成することで、デフォルトで計算されたサンプリングレートをオーバーライドすることができます。
サービス別にサンプリングルールを構成することができます。ルールの指定したサービスから始まるトレースには、Agent のデフォルトサンプリングレートの代わりに、定義されたパーセンテージサンプリングレートが適用されます。
環境変数 DD_TRACE_SAMPLING_RULES
を設定することで、サンプリングルールを構成することができます。
例えば、my-service
という名前のサービスのトレースの 20% を送信するには
DD_TRACE_SAMPLING_RULES='[{"service": "my-service", "sample_rate": 0.2}]'
サンプリングルールの取り込みメカニズムについて詳しくはこちら。
エラースパンを持つトレースは、しばしばシステム障害の症状です。エラーのあるトランザクションの割合を高く保つことで、常にいくつかの関連する個々のリクエストにアクセスすることができます。
ヘッドベースサンプリングされたトレースに加えて、エラーサンプリングレートを上げることで、ヘッドベースサンプリングで関連トレースが保持されない場合でも、各 Agent が追加のエラースパンを保持することができます。
注:
DD_APM_FEATURES=error_rare_sample_tracer_drop
を設定することで、トレーシングライブラリルールまたは manual.drop
でドロップしたスパンが含まれます。詳細は、取り込みのメカニズムのドキュメントのエラートレースセクションに記載されています。環境変数 DD_APM_ERROR_TPS
を設定することで、Agent ごとに 1 秒間に何個のエラーチャンクをキャプチャするかを構成することができます。デフォルト値は、1 秒間に 10
個のエラーです。すべてのエラーを取り込みたい場合は、任意の高い値を設定してください。エラーサンプリングを無効にするには、DD_APM_ERROR_TPS
を 0
に設定します。
トレースされたデータベース呼び出しは大量の取り込みデータを表し、アプリケーションのパフォーマンスメトリクス (エラーカウント、リクエストヒットカウント、レイテンシーなど) はデータベースの健全性を監視するのに十分です。
データベース呼び出しをトレースすることで生じるスパン量を減らすために、トレースの先頭でサンプリングを構成します。
データベースサービスがトレースを開始することはほとんどありません。通常、クライアントデータベーススパンは、インスツルメンテーションされたバックエンドサービススパンの子です。
どのサービスがデータベーストレースを開始するかを知るには、取り込み制御ページ Service Ingestion Summary の Top Sampling Decision Makers
トップリストグラフを使用します。これらの特定のサービスに対してヘッドベースサンプリングを構成すると、取り込まれるデータベーススパンの量が減少し、不完全なトレースが取り込まれないようにすることができます。分散型トレーシングは、保持されるか、完全に削除されます。
例えば、web-store-mongo
のデータベース呼び出しのトレースでは、99% の確率で web-store
と shipping-worker
のサービスからトレースが発生します。そのため、web-store-mongo
のトレース量を減らすには、web-store
と shipping-worker
のサービスに対してサンプリングを構成します。
サンプリングルールの構文については、サンプリングルール構成セクションを参照してください。
バックエンドサービスの web-store
は、トレースごとに何度も Mongo データベースを呼び出しており、不要なスパンボリュームを大量に作り出しています。
バックエンドサービス web-store
の トレースサンプリングルール を構成し、Mongo スパンを含むトレース全体の 10% を保持します。
DD_TRACE_SAMPLING_RULES='[{"service": "web-store", "sample_rate": 0.1}]'
オプションとして、すべての web-store
スパンを保持したい場合は、バックエンドサービス web-store
のスパンの 100% を保持するシングルスパンサンプリングルールを構成してください。このサンプリングでは、上記の 10% 以外のデータベース呼び出しスパンは取り込まれません。
DD_SPAN_SAMPLING_RULES='[{"service": "web-store", "sample_rate": 1}]'
注: スパンサンプリングルールの構成は、取り込みスパンから得られるスパンベースメトリクスを使用する場合に特に有効です。
お役に立つドキュメント、リンクや記事: