このトピックでは、Application Real-Time Monitoring Service (ARMS) がサポートする様々なトレースサンプリングモードについて説明します。シナリオに応じて適切なモードを選択することで、より低コストで必要なトレースデータを取得できます。
基本概念
スパン：リクエスト内の特定の操作。リモート呼び出しのエントリや内部メソッドの呼び出しなど。
ルートスパン：トレース内の最初のスパン。
ローカルルートスパン：単一アプリケーション内のトレースセグメントの最初のスパン。
スパンコンテキスト：同一トレース内のすべての操作をリンクするために、リクエストと共に伝播される情報。
ヘッドベースサンプリング：ルートスパンでのみ実行されるサンプリング戦略。ほとんどの場合、この方法により完全なトレースが保持されます。
非ヘッドベースサンプリング：ヘッドベースサンプリングがトレースをサンプリングしない場合に、任意のローカルルートスパンでトリガーされるサンプリング戦略。この方法では通常、完全なトレースを保証できません。
サンプリング戦略とマーク
より価値の高いトレースデータを確実に取得できるよう、ARMS は複数のサンプリング戦略を提供しています。これには、2 つのヘッドベースサンプリング戦略と 3 つの非ヘッドベースサンプリング戦略が含まれます。
ヘッドベースサンプリング戦略
非ヘッドベースサンプリング戦略
サンプリングマーク
EagleEye プロトコルを使用してプロセス間でトレースコンテキストを伝播する場合、ARMS はトレースがサンプリングされたかどうかを記録します。リクエストヘッダーのキーは EagleEye-Sampled で、その値は次のとおりです。
s0：サンプリングされていない
s1：サンプリングされた
トレースがサンプリングされたローカルルートスパンでは、サンプリング理由がスパン属性として記録され、キーは sample.reason です。可能な値は次のとおりです。
s2：全インターフェイスの最小サンプリング
s3：カスタムサンプリング
s4：固定レートサンプリング
s5：予約済み
s6：適応型サンプリング
s7：予約済み
s8：Basic Edition サンプリング
s9：失敗したリクエストのサンプリング
s10：低速リクエストのサンプリング
s11：異常な呼び出しのサンプリング
s12：ビジネストレースのサンプリング
ヘッドベースサンプリング戦略
ARMS は、2 つのヘッドベースサンプリング戦略を提供しています。固定レートサンプリングは分散トレーシングで最も一般的なアプローチで、適応型サンプリングは ARMS が開発したコスト効率の高い代替手段です。
固定レートサンプリング
この戦略は、指定された割合に基づいて、リクエストのエントリポイントでトレースをサンプリングします。この戦略を使用してサンプリングされたスパンは、属性 sample.reason とその値 s4 でマークされます。トレース詳細ページでは、スパンの [属性] に sample.reason フィールドが含まれます。固定レートサンプリングの場合、その値は s4 です。
固定レートサンプリングを設定するには、次の手順を実行します。
ARMS コンソールにログインします。 左側のナビゲーションウィンドウで、 を選択します。
[アプリケーションリスト] ページの上部で、宛先リージョンを選択し、対象のアプリケーションをクリックします。
説明[言語] 列のアイコンは、次のとおりです。
：アプリケーションモニタリングに接続された Java アプリケーション。
：アプリケーションモニタリングで監視される Go アプリケーション。
：アプリケーションモニタリングで監視される Python アプリケーション。[-]: Managed Service for OpenTelemetry に統合されたアプリケーション。
トップナビゲーションバーで、 を選択します。
[サンプリング設定] セクションで、[サンプリング戦略] を [固定サンプリングレート] に設定します。[サンプリングレートのパーセンテージ] フィールドに、数値を入力します。たとえば、10 を入力すると、トレースの 10% がサンプリングされます。
説明変更は、アプリケーションを再起動しなくてもすぐに有効になります。デフォルト値は、Java および Go アプリケーションでは 10、Python アプリケーションでは 100 です。サンプリングレートが高いほど、より多くのシステムリソースを消費するため、デフォルト値を維持することを推奨します。
[Save] をクリックします。
適応型サンプリング
実際のシナリオでは、アプリケーション内の異なるサービス間でトラフィックが大きく異なる場合があります。読み取りインターフェイスは、書き込みインターフェイスよりもはるかに多くのリクエストを受信することがよくありますが、そのトレースデータは一般的に価値が低い傾向にあります。固定レートサンプリングが、高トラフィックで低価値のトレースを過度に取得することを防ぐため、ARMS は適応型サンプリング戦略を提供しています。この戦略は、頻度ベースのアルゴリズムを使用して、呼び出し量の多い上位 1,000 のインターフェイスを選択します。これらの各インターフェイスのサンプリングは分離され、1 秒あたり 10 トレースのレートでサンプリングされます。上位 1,000 以外のインターフェイスは、単一の「その他」カテゴリにグループ化され、1 秒あたり 10 トレースの合計クォータを共有します。この戦略によってサンプリングされたスパンは、属性 sample.reason と値 s6 でマークされます。適応型サンプリングを有効にすると、スパンの [属性] でこの sample.reason を確認でき、値が s6 の場合は、このサンプリング理由が適用されたことを示します。
適応型サンプリングを設定するには、次の手順を実行します。
ARMS コンソールにログインします。 左側のナビゲーションウィンドウで、 を選択します。
[アプリケーション一覧] ページの上部で、宛先リージョンを選択し、対象のアプリケーションをクリックします。
説明[言語] 列のアイコンは、以下のとおりです。
：アプリケーションモニタリングに接続された Java アプリケーション。：アプリケーションモニタリングで監視される Go アプリケーション。：アプリケーションモニタリングで監視される Python アプリケーション。[-]: Managed Service for OpenTelemetry と統合されたアプリケーション。
上部のナビゲーションバーで、を選択します。
[サンプリング設定] セクションで、[サンプリング戦略] を [適応サンプリング] に設定します。
説明変更は、アプリケーションを再起動しなくてもすぐに有効になります。
[Save] をクリックします。
非ヘッドベースサンプリング戦略
ヘッドベースサンプリング戦略では、エラー、高レイテンシ、例外を含むスパンや、非常に低トラフィックまたはカスタム定義されたインターフェイスからのスパンなど、特に関心の高い特定の特性を持つスパンの取得を保証できません。トレードオフとして、これらの戦略はトレース内の任意のポイントでサンプリング決定を行うため、トレースの完全性を保証できません。
全インターフェイスの最小サンプリング
設定は不要です。この戦略は、各インターフェイスについて 1 分あたり少なくとも 1 つのトレースが自動的にサンプリングされることを保証します。この方法でサンプリングされたスパンは、属性 sample.reason と値 s2 でマークされます。
失敗したリクエストまたは低速リクエストのサンプリング
このサンプリング戦略を使用するには、[Custom Configurations] ページの [Call chain compression] 機能が有効になっていることを確認してください。この機能はデフォルトで有効になっています。
インターフェイス呼び出しが次のいずれかの条件を満たす場合、トレースがサンプリングされます。
インターフェイスエラー：HTTP ベースのインターフェイスでレスポンスコードが 200 ではない場合。その他のタイプのインターフェイスで、インストルメントされたメソッドが例外をスローする場合。
内部実行例外：インターフェイス呼び出しの内部実行中に例外が発生するものの、フレームワークのエントリポイントのインストルメンテーションには伝播されない場合。
高レイテンシ：インターフェイスの呼び出し時間が、[Custom Configurations] ページで設定されたインターフェイスの [低速呼び出しのしきい値] を超える場合。
説明分位数統計も有効になっている場合、呼び出し時間がそのインターフェイスの P99 レイテンシを超えると、低速リクエストのサンプリングルールもトリガーされます。
これらの理由でサンプリングされたスパンは、sample.reason 属性でマークされ、それぞれ s9 (インターフェイスエラー) 、s11 (内部例外) 、または s10 (高レイテンシ) に設定されます。
カスタムサンプリング
他のサンプリング戦略で必要なすべてのトレースを取得できない場合は、カスタムサンプリングを使用して、特定のインターフェイスが常にサンプリングされる (100% のサンプリングレート) ようにすることができます。インターフェイスは、完全一致名、プレフィックス、またはサフィックスで定義できます。この戦略によってサンプリングされたスパンには、キーが sample.reason、値が s3 の属性が含まれます。
カスタムサンプリングを設定するには、次の手順を実行します。
ARMS コンソールにログインします。 左側のナビゲーションウィンドウで、 を選択します。
[アプリケーションリスト] ページの上部で、宛先リージョンを選択し、ターゲットアプリケーションをクリックします。
説明[言語] 列のアイコンは、次の意味を示します。
：アプリケーションモニタリングに接続された Java アプリケーション。：アプリケーションモニタリングで監視される Go アプリケーション。：アプリケーションモニタリングで監視される Python アプリケーション。[-]: Managed Service for OpenTelemetry と統合されたアプリケーション。
上部のナビゲーションバーで、 を選択します。
[サンプリング設定] セクションで、フルサンプリングするインターフェイス、インターフェイスプレフィックス、およびインターフェイスサフィックスを指定します。
説明変更は、アプリケーションを再起動しなくてもすぐに有効になります。
[Save] をクリックします。
仕組み
A > B > C というトレースパスを考えます。ビジネス呼び出しのスパンをレポートする最終決定は、サンプリング戦略の組み合わせによって決定されます。次のフローチャートに示されている決定プロセスは、A、B、C にリクエストが到着するたびに実行されます。ただし、現在のスパンがルートスパンかローカルルートスパンかによって、一部のステップはスキップされます。
フローチャートの色には、次の意味があります。
紫：標準的なヘッドベースサンプリング。トレースのルートスパンでのみトリガーされます。A > B > C の例では、この戦略は A でのみトリガーされます。
青：ヘッドベースサンプリングがトリガーされない場合、トレース内の任意のノードでトリガーされる可能性があります。たとえば、A がリクエストをサンプリングしないと決定した場合、B は独自のカスタムサンプリングと全インターフェイスの最小サンプリング戦略に基づいて、サンプリングするかどうかを再評価します。B がサンプリングすると決定した場合、サンプリングマークを C に伝播します。この戦略は、A、B、C でトリガーされる可能性があります。
緑：現在のサンプリング決定が「サンプリングしない」である場合、任意のノードでトリガーされる可能性がありますが、ダウンストリームサービスのサンプリング決定には影響しません。たとえば、A がリクエストをサンプリングしないと決定した場合でも、B は失敗したリクエストまたは低速リクエストのサンプリング戦略に基づいてサンプリングすると決定する可能性があります。この場合、B はサンプリングマークを C に伝播しません。この戦略は、A、B、C でトリガーされる可能性があります。
次のステップ
トレースがサンプリングされた後、フィルター条件と集約ディメンションを使用して、トレースエクスプローラーでトレースデータをリアルタイムで分析します。