このトピックでは、Application Real-Time Monitoring Service (ARMS) でサポートされているトレースサンプリングモードについて説明します。シナリオに基づいて適切なモードを選択することで、必要なトレースデータを低コストで取得できます。
用語
span: リモート呼び出しや内部メソッド呼び出しなど、リクエスト内の特定の操作。
root span: トレース内の最初の span。
local root span: 単一 サービス内のトレースの最初の span。
span context: span のコンテキスト。 span context は、リクエスト内の特定の操作に関連付けられています。
head-based sampling: root span で事前にサンプリングの決定を行い、トレース全体がサンプリングされるようにします。
non-head based sampling: head-based sampling がトリガーされない場合に有効になり、トレース内の任意の local root span でトリガーされる可能性があります。ほとんどの場合、トレースの整合性は保証されません。
サンプリングポリシーとマーク
ARMS は、重要なトレースデータをサンプリングするために、2 つの head-based sampling ポリシーと 3 つの non-head based sampling ポリシーを提供します。
Head-based sampling ポリシー
Non-head based sampling ポリシー
サンプリングマーク
サンプリングマークは、EagleEye プロトコルを使用してプロセス間でトレースコンテキストが渡される場合に、トレースデータをサンプリングするかどうかを指定します。 リクエストヘッダーのキーは EagleEye-Sampled で、有効な値は次のとおりです。
s0: サンプリングされない
s1: サンプリングされる
サンプリングマークは、トレースデータがサンプリングされる local root span にサンプリング理由を記録することもできます。マークは属性の形式で span に格納されます。キーは sample.reason で、有効な値は次のとおりです。
s2: すべてのインターフェイスの最小サンプリング
s3: カスタムサンプリング
s4: 固定レートサンプリング
s5: 予約済み
s6: アダプティブサンプリング
s7: 予約済み
s8: Basic Edition サンプリング
s9: 失敗したリクエストのサンプリング
s10: 低速なリクエストのサンプリング
s11: 異常な呼び出しのサンプリング
Head-based sampling ポリシー
ARMS は、固定レートサンプリングとアダプティブサンプリングの 2 つの head-based sampling ポリシーをサポートしています。固定レートサンプリングは、最も一般的な head-based トレースサンプリングポリシーです。アダプティブサンプリングは、ARMS によって開発された費用対効果の高い head-based sampling ポリシーです。
固定レートサンプリング
トレースは、イングレス サービスで指定されたサンプリングレートに基づいてサンプリングされます。サンプリングされた span には、キーが sample.reason で値が s4 である属性が含まれています。
固定レートサンプリングポリシーを設定するには、次の手順を実行します。
ARMS console にログインします。左側のナビゲーションウィンドウで、 を選択します。
[アプリケーションリスト] ページで、上部のナビゲーションバーでリージョンを選択し、管理するアプリケーションの名前をクリックします。
説明[言語] 列に表示されるアイコンは、アプリケーションが記述されている言語を示します。
: Java アプリケーション
: Go アプリケーション
: Python アプリケーションハイフン ([-]): Managed Service for OpenTelemetry で監視されるアプリケーション。
上部のナビゲーションバーで、 を選択します。
[サンプリング設定] セクションで、サンプリングレートを設定できます。 [サンプリング戦略] パラメーターを [固定サンプリングレート] に設定します。 [サンプルレートの割合] フィールドにパーセント値を入力します。たとえば、10 と入力すると、サンプリングレートは 10% になります。
説明変更はすぐに有効になります。アプリケーションを再起動する必要はありません。デフォルト値は 10 です。サンプリングレートを上げると、追加のシステムリソースが消費されます。デフォルト値を維持することをお勧めします。
[保存] をクリックします。
アダプティブサンプリング
ビジネスによってトラフィックが大きく異なる場合があります。インターフェイス読み取りトラフィックは、書き込みトラフィックよりもはるかに大きいことが多く、インターフェイス書き込みに関連するトレースデータは、インターフェイス読み取りに関連するトレースデータよりも重要です。重要なトレースデータと重要度の低いトレースデータ間のサンプリングの不均衡を防ぐために、ARMS はアダプティブサンプリングを提供します。リクエストが最も多い 1,000 のインターフェイスのトレースは、LFU (Least Frequently Used) アルゴリズムに基づいて個別にサンプリングされます。これらのトレースごとに 1 分あたり 10 個のトレースがサンプリングされ、他のすべてのインターフェイスに対して 1 分あたり 10 個のトレースがサンプリングされます。サンプリングされた span には、キーが sample.reason で値が s6 である属性が含まれています。
アダプティブサンプリングポリシーを設定するには、次の手順を実行します。
ARMS console にログインします。左側のナビゲーションウィンドウで、 を選択します。
[アプリケーションリスト] ページで、上部のナビゲーションバーでリージョンを選択し、管理するアプリケーションの名前をクリックします。
説明[言語] 列に表示されるアイコンは、アプリケーションが記述されている言語を示します。
: Java アプリケーション: Go アプリケーション: Python アプリケーションハイフン ([-]): Managed Service for OpenTelemetry で監視されるアプリケーション。
上部のナビゲーションバーで、 を選択します。
[サンプリング設定] セクションで、[サンプリング戦略] パラメーターを [アダプティブサンプリング] に設定します。
説明変更はすぐに有効になります。アプリケーションを再起動する必要はありません。
[保存] をクリックします。
Non-head based sampling ポリシー
Head-based sampling は、トレース内の任意の span でトリガーされる可能性があり、トレースの整合性は保証されません。低速なリクエストまたは失敗したリクエストに関連する span や、頻度の低い span またはユーザー定義の span など、関心のある重要なトレースデータをすべてサンプリングできない場合があります。
すべてのインターフェイスの最小サンプリング
各インターフェイスのトレースは、1 分間に少なくとも 1 回自動的にサンプリングされます。サンプリングされた span には、キーが sample.reason で値が s2 である属性が含まれています。
失敗したリクエストまたは低速なリクエストのサンプリング
失敗したリクエストまたは低速なリクエストのトレースをサンプリングする前に、アプリケーション詳細ページに移動し、上部のナビゲーションバーから [構成] > [カスタム構成] を選択し、[詳細設定] セクションの [呼び出しチェーンの圧縮] スイッチをオンにします。このスイッチはデフォルトでオンになっています。
リクエストが次のいずれかの条件を満たす場合、関連するトレースは自動的にサンプリングされます。
HTTP インターフェイスの場合、200 以外の状態コードが返されます。他のインターフェイスの場合、イベントトラッキングに使用されるメソッドによって例外がスローされます。
インターフェイスの内部実行中に例外が発生し、フレームワークのイングレス サービスにスローされません。
操作呼び出しの時間が、[カスタム構成] ページで構成された低速呼び出しのしきい値を超えています。
説明分位数が有効になっている場合、その操作の 99 パーセンタイルを超える時間がかかる呼び出しも、低速呼び出しのサンプリングルールに一致します。
サンプリングされた span には、キーが sample.reason で値が s9、s11、または s10 である属性が含まれています。具体的な値は、どの条件が満たされるかによって異なります。
カスタムサンプリング
名前、プレフィックス、またはサフィックスを指定して、トレースを完全にサンプリングするインターフェイスを指定できます。サンプリングされた span には、キーが sample.reason で値が s3 である属性が含まれています。
カスタムサンプリングポリシーを設定するには、次の手順を実行します。
ARMS console にログインします。左側のナビゲーションウィンドウで、 を選択します。
[アプリケーションリスト] ページで、上部のナビゲーションバーでリージョンを選択し、管理するアプリケーションの名前をクリックします。
説明[言語] 列に表示されるアイコンは、アプリケーションが記述されている言語を示します。
: Java アプリケーション: Go アプリケーション: Python アプリケーションハイフン ([-]): Managed Service for OpenTelemetry で監視されるアプリケーション。
上部のナビゲーションバーで、 を選択します。
[サンプリング設定] セクションで、インターフェイス名、プレフィックス、またはサフィックスを指定します。
説明変更はすぐに有効になります。アプリケーションを再起動する必要はありません。
[保存] をクリックします。
フローチャート
A、B、C の 3 つの サービス間で生成されるトレースを例に挙げます。上記のサンプリングポリシーによって、span がサンプリングされるかどうかが決まります。次のフローチャートは、サンプリングの決定方法を示しています。各決定は、リクエストが A、B、または C にあるとき、および現在の span が local root span か root span かによって行う必要があります。
フローチャートでは、次の色が使用されています。
紫: トレースの root span でのみトリガーされる head-based sampling を示します。A では 1 つのサンプリング決定のみが行われます。
青: head-based sampling がトリガーされない場合、トレース内の任意の span でサンプリングをトリガーします。A がサンプリングしないことを決定したとします。リクエストが B にあるとき、B はカスタムサンプリング、最小サンプリング、またはそのいずれも実装しないかを決定します。サンプリングが実装されている場合、span に添付された属性は C に渡されます。A、B、C で 3 つのサンプリング決定が行われます。
緑: head-based sampling、カスタムサンプリング、および最小サンプリングがトリガーされない場合、トレース内の任意の span でサンプリングをトリガーします。A がサンプリングしないことを決定したとします。リクエストが B にあるとき、B はリクエストが低速か失敗したか、およびサンプリングを実装するかどうかを決定します。サンプリングが実装されている場合、span に添付された属性は C に渡されません。A、B、C で 3 つのサンプリング決定が行われます。
参照
トレースがサンプリングされた後、フィルター条件と集約ディメンションを構成して、トレースデータをリアルタイムで分析できます。詳細については、「トレース分析」をご参照ください。