Probabilistic サンプラープロセッサー 🔗
The Probabilistic sampler processor supports several modes of sampling for spans and log records. Sampling is performed on a per-request basis, considering individual items statelessly. The supported pipeline types are traces
and logs
. See パイプラインでデータを処理する for more information.
トレーススパンの場合、プロセッサーはTraceIDに適用される設定されたサンプリングパーセンテージに基づく確率的サンプリングをサポートします。さらに、sampling.priority
設定を使用して、サンプラーに0%または100%のサンプリングを適用させることができます。
注釈
For whole trace sampling, see テールサンプリングプロセッサー.
ログレコードについては、埋め込まれたTraceIDを使用し、スパンに適用されるのと同じロジックに従うようにプロセッサーを設定することも、選択したログレコード属性にハッシュを適用するようにサンプラーを設定することもできます。また、サンプリング優先度もサポートします。
はじめに 🔗
以下の手順に従って、コンポーネントの設定とアクティベーションを行ってください:
Splunk Distribution of the OpenTelemetry Collector をホストまたはコンテナプラットフォームにデプロイします:
Configure the
probabilistic_sampler
processor as described in the next section.Collector を再起動します。
サンプル構成 🔗
OpenTelemetry仕様を使用して、トレースIDに従ってログレコードの15%をサンプリングします:
processors:
probabilistic_sampler:
sampling_percentage: 15
logID属性に従ってログをサンプリングする:
processors:
probabilistic_sampler:
sampling_percentage: 15
attribute_source: record # possible values: one of record or traceID
from_attribute: logID # value is required if the source is not traceID
priorityという属性に従って、ログレコードにサンプリングの優先順位を与えます:
processors:
probabilistic_sampler:
sampling_percentage: 15
sampling_priority: priority
To complete the configuration, include the processor in the traces
or logs
pipeline of the service
section of your configuration file. For example:
service:
pipelines:
logs:
processors: [probabilistic_sampler]
設定オプション 🔗
プロセッサーには以下のコンフィギュレーション・オプションがあります:
sampling_percentage
。必須。32ビット浮動小数点。項目をサンプリングする割合。100
と等しいか大きい場合、すべての項目をサンプリングし、0
はすべての項目を拒否します。hash_seed
. Optional,0
by default. 32-bit unsigned integer. An integer used to compute the hash algorithm. Note that all collectors for a given tier (for example, behind the same load balancer) must have the samehash_seed
.fail_closed
。オプション。デフォルトはtrue
。ブーリアン。サンプリング関連のエラーがある項目を拒否するかどうか。
Logs-specific configuration:
attribute_source
。オプション。デフォルトは"traceID"
。文字列。from_attribute
のどこで属性を探すかを定義します。指定できる値はtraceID
またはrecord
です。from_attribute
。オプション、デフォルトでは無効。文字列。一意のログレコードIDなど、サンプリング目的で使用されるログレコード属性の名前。この属性の値は、トレースIDがない場合、またはattribute_source
がrecordに設定されている場合にのみ使用されます。sampling_priority
。オプション、デフォルトでは無効。文字列。sampling_percentage
設定とは異なるサンプリング優先度を設定するために使用されるログレコード属性名。100
と等しいかそれ以上の場合、すべてのログレコードをサンプリングし、0
はすべてのログレコードを拒否します。
Understand the processor 🔗
一貫性の保証 🔗
一貫性のある確率サンプラーとは、例えばTraceIDによって、グループ内の各スパンまたはログレコードの独立したサンプリング決定をサポートするサンプラーであり、同時に以下のように完全性の可能性を最大化します。
一貫した確率サンプリングでは、与えられたトレース内の任意のスパンについて、サンプリング確率の低いサンプラーがサンプリングのためにスパンを選択した場合、そのスパンはサンプリング確率の高い構成のサンプラーによっても選択されます。
Achieve complete sampling 🔗
システムに異なるサンプリング確率の複数のコレクターを配置するときは、これらのガイドラインを考慮してください。例えば、フロントエンドサーバーにサービスを提供するコレクターは、サブトレースの完全性を壊すことなく、バックエンドサーバーにサービスを提供するコレクターよりも小さいサンプリング確率で設定できます。
トレースは、そのメンバーすべてがサンプリングされたときに完了します。「サブトレース」は、その子孫のすべてがサンプリングされたときに完了します。通常、トレースとロギングSDKは、コンテキストに基づいてサンプリングする、親ベースのサンプラーを設定します。
次の場合、結果が不完全な場合があります:
非ルートスパンまたはログは、例えば、非ルートスパンに
TraceIDRatioBased
サンプラーを使用するなど、親ベースのアプローチを使用する代わりに、独立したサンプリング決定を行います。このようなプロセッサーは、スパンとログレコードを独立してサンプリングします。
この問題を最小限にするには、一貫性を持たせることです。一貫した確率スキームで1%、10%、50%の確率を使用するには、10%サンプラーがサンプリングするときに50%サンプラーがサンプリングしなければならず、1%サンプラーがサンプリングするときに10%サンプラーがサンプリングしなければなりません。第1層で1%サンプリング、第2層で10%サンプリング、最下層で50%サンプリングの3層システムを設定できます。この設定では、一貫性プロパティにより、1% のトレースが完了し、第2層で10%のトレースがサブトレースを完了して、第3層で50%のトレースがサブトレースを完了します。
注意
一貫した確率サンプラーを確率の混合で安全に使用し、サブトレースの完全性を保持するためには、子スパンとログレコードは親コンテキスト以上の確率でサンプリングする必要があります。
Set sampling randomness 🔗
一貫性を達成するために、サンプリングのランダム性は入力データの決定論的な側面から取られます:
traces
パイプラインの場合、ランダム性のソースは常にTraceIDです。logs
パイプラインの場合、設定されている場合、ランダム性のソースはTraceIDまたは他のログレコード属性になります。attribute_source
をtraceID
に設定すると、TraceIDが使用されます。attribute_source
をrecord
に設定した場合、またはTraceIDフィールドが存在しない場合、設定されている場合は、from_attribute
がランダム性のソースとして使用されます。
Set sampling priority 🔗
サンプリング優先メカニズムは、すべてのモードにおいて確率的決定よりも優先されるオーバーライドです。
注意
サンプリングの優先順位は、ログとトレースで動作が異なります。
traces
パイプラインでは、優先順位属性が 0
の場合、設定された確率は0%に変更され、アイテムはサンプラーを通過しません。優先度属性が0以外の場合、設定された確率は100%に設定されます。サンプリング優先度属性は設定できず、sampling.priority
と呼ばれます。
logs
パイプラインでは、優先度属性が 0
の場合、設定された確率は0%に修正され、項目はサンプラーを通過しません。それ以外の場合、ログのサンプリング優先度属性はパーセンテージとして解釈されます。100
と等しいか大きい場合、すべてのログレコードをサンプリングします。ログサンプリング優先度属性を設定するには、sampling_priority
を使用します。
サンプリングアルゴリズム 🔗
ハッシュシード 🔗
ハッシュシード法は、スパンとログレコードの場合はトレースIDに、ログの場合は指定された属性の値に適用されるFNVハッシュ関数を使用します。ランダムであると推定されるハッシュ値は、サンプリング率に対応するしきい値と比較されます。
このモードを有効にするには、次のいずれかを実行します:
hash_seed
をゼロ以外の値に設定します。attribute_source
をrecord
に設定したログ記録のサンプル。
ハッシュが一貫しているためには、ある階層(たとえば、同じロードバランサーの後ろ)のすべてのコレクターが同じ hash_seed
を持っている必要があります。また、追加のサンプリング要件をサポートするために、異なるコレクター層で異なる hash_seed
を活用することもできます。
このモードでは14ビットのサンプリング精度を使用します。
エラー処理 🔗
このプロセッサーは、到着データにランダム性がない場合、エラーとみなします。これには、TraceIDフィールドが16ゼロバイトなど、無効である場合や、ログレコード attribute_source
の情報がゼロバイトである場合などが含まれます。
デフォルトでは、エラーが検出された場合、データは拒否されます。この動作を変更し、エラーデータをプロセッサに通過させるには、fail_closed
プロパティを false
に設定します。
設定 🔗
The following table shows the configuration options for the probabilistic_sampler
processor:
トラブルシューティング 🔗
Splunk Observability Cloudをご利用のお客様で、Splunk Observability Cloudでデータを確認できない場合は、以下の方法でサポートを受けることができます。
Splunk Observability Cloudをご利用のお客様
Submit a case in the Splunk Support Portal .
Contact Splunk Support .
見込み客および無料トライアルユーザー様
Splunk Answers のコミュニティサポートで質問し、回答を得る
Splunk #observability ユーザーグループの Slack チャンネルに参加して、世界中の顧客、パートナー、Splunk 社員とのコミュニケーションを図る。参加するには、Get Started with Splunk Community マニュアルの チャットグループ を参照してください。