分散トレースは、大量のスパンデータを生成します。サンプリングを行わないと、ストレージとコンピューティングのコストはトラフィックとともに増加し、ほとんどのトレースは正常で健全なリクエストを表します。Application Real-Time Monitoring Service (ARMS) は、エラー、低速リクエスト、トラフィック量の少ないインターフェースなど、重要なトレースを保持し、それ以外を破棄できる5つのサンプリングポリシーを提供します。これにより、トラブルシューティングとパフォーマンス分析に必要な可観測性カバー率を維持しながら、コストを削減できます。
すべてのサンプリング設定の変更はすぐに有効になります。アプリケーションの再起動は不要です。
用語
| 用語 | 定義 |
|---|---|
| スパン | リクエスト内の単一のオペレーション (RPC 呼び出しや内部メソッド呼び出しなど)。 |
| ルートスパン | トレース内の最初のスパン。ルートスパンには親がありません。 |
| ローカルルートスパン | 単一サービス内のトレースの最初のスパン。分散トレース内の各サービスには、独自のローカルルートスパンがあります。 |
| スパンコンテキスト | スパンに関連付けられ、プロセス境界を越えて伝播されるメタデータ。 |
| ヘッダーベースサンプリング | トレースの伝播が開始される前に、ルートスパンで行われるサンプリング決定。ヘッダーベースサンプリングは、完全なトレースを保証します。すべてのスパンがサンプリングされるか、まったくサンプリングされないかのいずれかです。 |
| 非ヘッダーベースサンプリング | ヘッダーベースサンプリングがトリガーされない場合に有効になるサンプリング。非ヘッダーベースサンプリングは、任意のローカルルートスパンでトリガーされる可能性があるため、トレースの完全性は保証されません。 |
サンプリングポリシーの選択
ARMS は、2つのヘッダーベースサンプリングポリシーと3つの非ヘッダーベースサンプリングポリシーを提供します。ヘッダーベースポリシーはルートスパンで決定され、完全なエンドツーエンドのトレースを保証します。非ヘッダーベースポリシーは個々のサービスで決定され、ヘッダーベースサンプリングでは見逃される可能性のあるトレースをキャプチャします。
| 目標 | 推奨ポリシー | カテゴリ |
|---|---|---|
| すべてのトレースの固定割合をサンプリング | 固定レートサンプリング | ヘッドベース |
| トラフィック量に関係なく、すべてのインターフェースでカバー率のバランスを取る | 適応型サンプリング | ヘッドベース |
| 1分あたりインターフェースごとに少なくとも1つのトレースを保証 | 全インターフェースの最小サンプリング | 非ヘッダーベース |
| エラーおよび低速リクエストのトレースを自動的にキャプチャ | 失敗または低速リクエストのサンプリング | 非ヘッダーベース |
| 特定のインターフェースを名前で常にサンプリング | カスタムサンプリング | 非ヘッダーベース |
複数のポリシーを同時にアクティブにできます。ARMS は、定義された順序でそれらを評価します。「サンプリング決定フローチャート」をご参照ください。
ヘッドベースサンプリングポリシー
ヘッダーベースサンプリングは、トレースのルートスパンで単一の決定を行います。トレースがサンプリングされると、すべてのダウンストリームスパンはスパンコンテキストを通じてその決定を継承します。これにより、完全なエンドツーエンドのトレースが保証されます。
固定レートサンプリング
固定レートサンプリングは、イングレスサービスで設定された割合でトレースを選択します。たとえば、10% のサンプリングレートは、約10個のトレースのうち1つがサンプリングされることを意味します。
サンプリングされたスパンには、属性 sample.reason: s4 が含まれます。
固定レートサンプリングの設定
ARMS コンソールにログインします。 左側のナビゲーションウィンドウで、を選択します。
上部のナビゲーションバーでリージョンを選択し、アプリケーションをクリックします。
説明 [言語] 列のアイコンが示すプログラミング言語は次のとおりです。 -
: Java - 
: Go - 
: Python - - (ハイフン): OpenTelemetry 向けマネージドサービスでモニタリングされているアプリケーション上部ナビゲーションバーで、 を選択します。
[サンプリング設定] セクションで、[サンプリング戦略] を [固定サンプリングレート] に設定します。サンプリングレートのパーセンテージ フィールドで、値を入力します。たとえば、10% のサンプリングレートにする場合は、
10を入力します。説明デフォルト値は 10 です。サンプリングレートが高いほど、より多くのシステムリソースを消費します。ワークロードでより広範なトレースカバー率が必要な場合を除き、デフォルト値を維持してください。
クリックします。[保存]。
適応型サンプリング
トラフィック量の多いインターフェースは固定レートサンプリングの結果を支配することが多く、トラフィック量が少ないが重要なインターフェースは過小評価されがちです。適応型サンプリングは、リクエスト量に関係なく、インターフェースごとに固定数のトレースを割り当てることで、この問題を解決します。
仕組み: ARMS は、リクエスト量が最も多い1,000個のインターフェースを識別し、Least Frequently Used (LFU) アルゴリズムを使用して、1分あたりインターフェースごとに10個のトレースをサンプリングします。残りのすべてのインターフェースは、1分あたり合計10個のトレースの結合予算を共有します。
例: ご利用のサービスに、1分あたり50,000件のリクエストを処理するインターフェース /api/orders/list と、1分あたり100件のリクエストしか処理しないインターフェース /api/orders/refund があるとします。適応型サンプリングを使用すると、どちらも1分あたり10個のサンプリングされたトレースを取得します。これにより、トラフィック量の多いリストフローに圧倒されることなく、トラフィック量の少ない払い戻しフローの可視性を維持できます。
サンプリングされたスパンには、属性 sample.reason: s6 が含まれます。
適応型サンプリングの設定
ARMS コンソールにログインします。左側のナビゲーションウィンドウで、を選択します。
上部のナビゲーションバーでリージョンを選択し、アプリケーションをクリックします。
説明 「[言語]」列のアイコンは、プログラミング言語を示します。-: Java - : Go - : Python - -（ハイフン）: OpenTelemetry 向けマネージドサービスで監視されるアプリケーション上部ナビゲーションバーで、 を選択します。
[サンプリング設定] セクションで、[サンプリング戦略] を [アダプティブ サンプリング] に設定します。
[保存] をクリックします。
非ヘッダーベースサンプリングポリシー
非ヘッダーベースサンプリングは、ヘッダーベースサンプリングがまだトレースを選択していない場合に、各サービスで独立してトリガーされます。決定はルートではなくトレース途中で行われるため、完全なエンドツーエンドのトレースは保証されません。ただし、これらのポリシーは、エラー、低速リクエスト、めったに呼び出されないインターフェースなど、ヘッダーベースサンプリングでは見逃される可能性のあるトレースをキャプチャします。
全インターフェースの最小サンプリング
ARMS は、1分あたりインターフェースごとに少なくとも1つのトレースを自動的にサンプリングします。これにより、固定レートサンプリングや適応型サンプリングでは完全にスキップされる可能性のある、トラフィック量が非常に少ないインターフェースを含む、すべてのインターフェースのベースラインの可視性が保証されます。
サンプリングされたスパンには、属性 sample.reason: s2 が含まれます。
失敗または低速リクエストのサンプリング
このポリシーは、失敗または低速リクエストのトレースを自動的にキャプチャするため、調査が必要な呼び出しのトレースデータを常に取得できます。
このポリシーを使用する前に、[コールチェーン圧縮] スイッチがオンになっていることを確認してください。 アプリケーション詳細ページに移動し、上部のナビゲーションバーからを選択して、[詳細設定] セクションを確認してください。 このスイッチはデフォルトでオンになっています。
以下のいずれかの条件が満たされると、トレースがサンプリングされます。
失敗したリクエスト: HTTP インターフェースが 200 以外のステータスコードを返すか、非 HTTP インターフェースがインストゥルメントされたメソッドから例外をスローします。
キャッチされない内部例外: 内部実行中に例外が発生したが、フレームワークのイングレスサービスに伝播されません。
遅いリクエスト： 呼び出しの持続時間が、[カスタム設定] ページで設定された遅い呼び出しのしきい値を超えます。
分位数が有効になっている場合、そのインターフェースの99パーセンタイルを超える期間の呼び出しも、低速呼び出しサンプリングルールに一致します。
sample.reason 属性の値は、トリガー条件によって異なります。
| 条件 | sample.reason の値 |
|---|---|
| 失敗したリクエスト | s9 |
| 異常な呼び出し (キャッチされない例外) | s11 |
| 低速リクエスト | s10 |
カスタムサンプリング
カスタムサンプリングを使用すると、正確な名前、プレフィックス、またはサフィックスでインターフェースを指定し、そのすべてのトレースをサンプリングできます。これは、決済処理インターフェースや新規デプロイされたサービスなど、完全なトレースカバー率を必要とするインターフェースに使用します。
サンプリングされたスパンには、属性 sample.reason: s3 が含まれます。
カスタムサンプリングの設定
ARMS コンソールにログインします。ARMS コンソールの左側のナビゲーションウィンドウで、 を選択します。
上部のナビゲーションバーでリージョンを選択し、アプリケーションをクリックします。
説明 注: [言語] 列のアイコンは、プログラミング言語を示します。-: Java - : Go - : Python - -（ハイフン）: OpenTelemetry 向けマネージドサービスでモニターされるアプリケーショントップナビゲーションバーで、 を選択します。
[サンプリング設定] セクションで、インターフェイス名、プレフィックス、またはサフィックスを指定します。
[保存] をクリックします。
サンプリングマーク
トレースコンテキストが EagleEye プロトコルを使用してサービス間で渡される場合、ARMS はサンプリング決定を伝達するためにサンプリングマークを使用します。EagleEye-Sampled リクエストヘッダーには、次の2つの値のいずれかが含まれます。
| 値 | 意味 |
|---|---|
s0 | サンプリングなし |
s1 | サンプリング済み |
ARMS は、トレースがサンプリングされた理由を sample.reason スパン属性に記録します。この属性を使用して、トレースエクスプローラー でトレースをフィルター処理と分析を行います。たとえば、s10 でフィルター処理すると、遅いリクエストによってサンプリングされたすべてのトレースが見つかります。
sample.reason の値 | サンプリングポリシー |
|---|---|
s2 | 全インターフェースの最小サンプリング |
s3 | カスタムサンプリング |
s4 | 固定レートサンプリング |
s5 | 予約済み |
s6 | 適応型サンプリング |
s7 | 予約済み |
s8 | Basic Edition サンプリング |
s9 | 失敗リクエストサンプリング |
s10 | 低速リクエストサンプリング |
s11 | 異常呼び出しサンプリング |
サンプリング決定フローチャート
次の図は、ARMS がサービス A、B、C にまたがるトレースのサンプリングポリシーをどのように評価するかを示しています。
フローチャートでは、3つの色分けされたパスを使用します。
紫 (ヘッダーベースサンプリング): トレースのルートスパンでのみ評価されます。サービス A で単一のサンプリング決定が行われ、すべてのダウンストリームサービスに伝播されます。
青 (カスタムサンプリングおよび最小サンプリング): ヘッダーベースサンプリングがトリガーされなかった場合に、各サービスで評価されます。サービス B がカスタムサンプリングまたは最小サンプリングを通じてトレースをサンプリングすると、サンプリング属性はサービス C に渡されます。各サービス (A、B、C) は独自の決定を行います。
緑 (失敗または低速リクエストサンプリング): 以前のポリシーのいずれもサンプリングをトリガーしなかった場合に、各サービスで評価されます。サービス B が失敗または低速応答のためにトレースをサンプリングした場合、サンプリング属性は 渡されません サービス C に。各サービスは独立した決定を行います。
関連項目
Trace Explorer でのトレースデータの分析:
sample.reasonおよびその他の属性をフィルター条件として、特定のトレースを調査します。サポートされているトレースプロトコル: EagleEye プロトコルおよびその他のサポートされている伝播フォーマットの詳細。