概要
Trace Queries を使用すると、トレース構造内の複数のスパンのプロパティとそれらスパン間の関係に基づいて、トレース全体を見つけることができます。トレースクエリを作成するには、2 つ以上のスパンクエリを定義し、それぞれのスパンクエリによって返されるスパンの、検索されたトレース構造内の関係を指定します。
Trace Query エクスプローラーから、トレースの検索、フィルタリング、グループ化、視覚化を行うことができます。
構造ベースのトレースクエリにより、次のような質問に答えることができます。
- どのトレースが 2 つのサービス間の依存関係を含んでいるか (
service A は service B へのダウンストリームコールを持っている)？ - バックエンドサービスのエラーによって影響を受ける API エンドポイントは？
Trace Queries を使用して、調査を加速し、関連するトレースを見つけます。
トレースクエリエディタ
トレースクエリは、2 つ以上のスパンクエリをトレースクエリ演算子で結合したものです。
スパンクエリ
スパンクエリ構文を使用して、特定の環境、サービス、またはエンドポイントからのスパンをクエリします。オートコンプリート候補を使用して、ファセットと最近のクエリを表示します。
Add another span query をクリックして、スパンクエリを追加し、トレースクエリステートメントで使用します。
トレースクエリ演算子
a、b、c などのラベルが付けられた複数のスパンクエリを、それぞれのスパンクエリを表す文字の間に演算子を使用して、Traces matching フィールドのトレースクエリに結合します。
| 演算子 | 説明 | 例 |
|---|
&& | And: どちらのスパンもトレース内にある | サービス web-store のスパンとサービス payments-go のスパンを含むトレース:
service:web-store && service:payments-go |
|| | Or: どちらか一方のスパンがトレース内にある | サービス web-store またはサービス mobile-store からのスパンを含むトレース:
service:web-store || service:mobile-store |
-> | 間接関係: 右のクエリにマッチするスパンのアップストリームにある、左のクエリにマッチするスパンを含むトレース | サービス checkoutservice がサービス quoteservice のアップストリームにある場合のトレース:
service:checkoutservice -> service:quoteservice |
=> | 直接関係: 右のクエリにマッチするスパンの直接の親である、左のクエリにマッチするスパンを含むトレース | サービス checkoutservice がサービス shippingservice を直接呼び出している場合のトレース:
service:checkoutservice => service:shippingservice |
NOT | 除外: クエリに一致するスパンを 含まない トレース | サービス web-store のスパンは含むが、サービス payments-go のスパンは含まないトレース:
service:web-store && NOT(service:payments-go) |
トレースレベルのフィルター
Where ステートメントで、スパン数やトレースのエンドツーエンドの持続時間のようなトレースレベルの属性にフィルターを適用することで、トレースの結果セットをさらにフィルタリングします。
| フィルター | 説明 | 例 |
|---|
span_count(a) | スパンの発生回数 | 10 回を超える mongo データベースへの呼び出しを含むトレース:
- queryA:service:web-store-mongo @db.statement:"SELECT * FROM stores
- Traces matching:a
- Where:span_count(a):>10 |
total_span_count | トレース内のスパン数 | 1000 を超えるスパンを含むトレース:
Wheretotal_span_count:>1000 |
trace_duration | エンドツーエンドのトレース期間 | エンドツーエンドの実行時間が 5 秒を超えるトレース :
Where:trace_duration:>2s |
フローマップ
フローマップを使用すると、Trace Queries にマッチする結果のトレースから、リクエストパスとサービスの依存関係を理解することができます。マップを使用して、エラーパス、異常なサービス依存関係、またはデータベースへのリクエストレートが異常に高いことを特定します。
注: フローマップは取り込みトラフィックのサンプルによって生成されます。
スパンクエリにマッチするサービスノードはハイライトされ、クエリ条件がトレースのどの部分を対象としているかを示します。
1 つのサービスに関する詳細情報を得るには、そのサービスのノードにカーソルを合わせると、そのリクエストレートとエラーレートのメトリクスが表示されます。2 つのサービス間のリクエストレートとエラーレートのメトリクスを表示するには、2 つのサービスを接続するエッジにカーソルを合わせます。
特定のサービスへの依存を含まないトレースを除外するには、マップ上のそのサービスのノードをクリックします。
トレースリスト
トレースリストには、選択した時間範囲内でクエリにマッチする最大 50 のサンプルトレースが表示されます。
レイテンシーブレイクダウンにカーソルを合わせると、リクエスト実行中にどこに (どのサービスに) 時間が費やされたかを知ることができます。
注: テーブルに表示される情報は、トレースの root スパンからの属性であり、期間を含みます。トレースのエンドツーエンド期間を表すものではありません。
分析
Timeseries、Top List、Table などの他の視覚化のいずれかを選択すると、1 つまたは複数のディメンションでグループ化された結果を経時的に集計することができます。集計オプションの詳細については、スパンの視覚化を参照してください。
これらの集計オプションに加えて、どのスパンクエリ (a、b、c など) からスパンを集計するかを選択する必要もあります。集計オプションでタグと属性を使用するスパンにマッチするクエリを選択してください。
例えば、サービス web-store のスパン (クエリ a) と、いくつかのエラーを含むサービス payments-go のスパン (クエリ b) を含むトレースをクエリし、@merchant.tier でグループ化されたスパンのカウントを視覚化する場合、クエリ a のスパンを使用します。これは、merchant.tier がサービス payments-go の属性ではなく、サービス web-store のスパンの属性であるためです。
Trace Queries ソースデータの仕組み
Datadog は、Trace Queries 用のデータをインデックスするために インテリジェント リテンション フィルター を使用します。これは次の処理によって実現されます:
これら 2 つのサンプリング メカニズムは 完全なトレース を取得します。つまり、Trace Queries が正確な結果を返すよう、トレース内のすべてのスパンが常にインデックス化されます。
注: フラットサンプリングと多様性サンプリングによってインデックス化されたスパンは、インデックス化されたスパンの使用量にカウントされないため、請求には影響しません。
1% フラットサンプリング
retained_by:flat_sampled
フラットな 1% サンプリングは trace_id に基づいて適用されます。つまり、同一トレースに属するすべてのスパンは同じサンプリング判定を共有します。詳細は 1% フラット サンプリングのドキュメント を参照してください。
多様性サンプリング
retained_by:diversity_sampling
15 分ごとに、ダイバーシティ サンプリングは environment 、service 、operation 、resource の各組み合わせごとに、少なくとも 1 つのスパンと関連するトレースを保持します。これはレイテンシの p75 、 p90 、および p95 パーセンタイルで実行され、トラフィックの少ないエンドポイントであっても、service ページや resource ページで常にサンプル トレースを見つけられるようにします。詳細は ダイバーシティ サンプリングのドキュメント を参照してください。
その他の参考資料
