Probabilistic サンプラープロセッサー

スパンおよびログレコードのサンプリングに複数のモードをサポートします。

Probabilistic サンプラープロセッサはスパンおよびログレコードのサンプリングに複数のモードをサポートします。サンプリングは、個々の項目をステートレスに考慮して、要求ごとに実行されます。サポートされるパイプラインタイプは、traces と logs です。詳細については「パイプラインでデータを処理する」を参照してください。

トレーススパンの場合、プロセッサは TraceID に適用される設定されたサンプリングパーセンテージに基づく確率的サンプリングをサポートします。さらに、 sampling.priority 設定を使用して、サンプラーに 0% または 100% のサンプリングを適用させることができます。

注: トレースサンプリング全体については、「テール サンプリング プロセッサ」を参照してください。

ログレコードについては、埋め込まれた TraceID を使用し、スパンに適用されるのと同じロジックに従うようにプロセッサを設定することも、選択したログレコード属性にハッシュを適用するようにサンプラーを設定することもできます。また、サンプリング優先度もサポートします。

はじめに

以下の手順に従って、コンポーネントの設定とアクティベーションを行ってください：

  1. Splunk Distribution of the OpenTelemetry Collector をホストまたはコンテナプラットフォームにデプロイします：

  2. 次のセクションで説明するように、probabilistic_sampler プロセッサーを設定します。

  3. 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

設定を完了するには、構成ファイルの service セクションの traces または logs パイプラインにプロセッサを含めます。例：

service:
  pipelines:
    logs:
      processors: [probabilistic_sampler]

設定オプション

プロセッサーには以下のコンフィギュレーション・オプションがあります：

  • sampling_percentageします。必須。32 ビット浮動小数点。項目がサンプリングされる割合。100 以上の場合、すべての項目がサンプリングされ、0 はすべての項目を拒否します。

  • hash_seedします。オプション。デフォルトは 0 です。32 ビットの符号なし整数。ハッシュアルゴリズムの計算に使用される整数。特定の階層（たとえば、同じロードバランサの背後）のコレクタはすべて、同じ hash_seed を持つ必要があることに注意してください。

  • fail_closedします。オプション。デフォルトは true です。ブール値。サンプリング関連のエラーがある項目を拒否するかどうか。

ログ固有の設定については、次のオプションを参照してください。

  • attribute_sourceします。オプション。デフォルトは "traceID" です。Stringfrom_attribute 内の属性を検索する場所を定義します。使用できる値は、traceID または record です。

  • from_attributeします。オプション。デフォルトは無効です。String 一意のログレコード ID など、サンプリングの目的で使用するログレコード属性の名前。この属性の値は、トレース ID が存在しない場合、または attribute_source がレコードに設定されている場合にのみ使用されます。

  • sampling_priorityします。オプション。デフォルトは無効です。Stringsampling_percentage 設定とは異なるサンプリング優先順位を設定するために使用されるログレコード属性の名前。100 以上の場合、すべてのログレコードがサンプリングされ、0 はすべてのログレコードを拒否します。

プロセッサーを理解する

一貫性の保証

一貫性のある確率サンプラーとは、例えばTraceIDによって、グループ内の各スパンまたはログレコードの独立したサンプリング決定をサポートするサンプラーであり、同時に以下のように完全性の可能性を最大化します。

一貫した確率サンプリングでは、与えられたトレース内の任意のスパンについて、サンプリング確率の低いサンプラーがサンプリングのためにスパンを選択した場合、そのスパンはサンプリング確率の高い構成のサンプラーによっても選択されます。

完全なサンプリングを達成する

システムに異なるサンプリング確率の複数のコレクタを配置するときは、これらのガイドラインを考慮してください。たとえば、フロントエンドサーバーにサービスを提供するコレクタは、サブトレースの完全性を壊すことなく、バックエンドサーバーにサービスを提供するコレクタよりも小さいサンプリング確率で設定できます。

トレースは、そのすべてのメンバーがサンプリングされたときに完了します。「サブトレース」は、そのすべての子孫がサンプリングされたときに完了します。通常、トレースおよびロギング SDK は、コンテキストに基づいてサンプリングされる親ベースのサンプラーを設定します。

以下に該当する場合、結果が不完全になる可能性があります。

  • 非ルートスパンまたはログは、例えば、非ルートスパンに TraceIDRatioBased サンプラーを使用するなど、親ベースのアプローチを使用する代わりに、独立したサンプリング決定を行います。

  • このようなプロセッサーは、スパンとログレコードを独立してサンプリングします。

この問題を最小限に抑えるには、一貫性を保つようにします。一貫した確率スキームで 1%、10%、50% の確率を使用するには、10% サンプラーがサンプリングを行う場合は 50% サンプラーでサンプリングを行い、1% サンプラーがサンプリングを行う場合は 10% サンプラーでサンプリングする必要があります。最初の階層で 1% のサンプリング、2 番目の階層で 10% のサンプリング、一番下の階層で 50% のサンプリングを行う 3 階層システムを設定できます。この設定では、トレースの 1% が完了し、トレースの 10% が第 2 階層でサブトレースを完了し、整合性プロパティにより、トレースの 50% が第 3 階層でサブトレースを完了します。

注意: 一貫した確率サンプラーを確率の混合で安全に使用し、サブトレースの完全性を保持するためには、子スパンとログレコードは親コンテキスト以上の確率でサンプリングする必要があります。

サンプリングランダム性を設定

一貫性を達成するために、サンプリングのランダム性は入力データの決定論的な側面から取られます：

  • traces パイプラインの場合、ランダム性のソースは常にTraceIDです。

  • logs パイプラインの場合、設定されている場合、ランダム性のソースはTraceIDまたは他のログレコード属性になります。

    • attribute_source を traceID に設定すると、TraceIDが使用されます。

    • attribute_source を record に設定した場合、またはTraceIDフィールドが存在しない場合、設定されている場合は、from_attribute がランダム性のソースとして使用されます。

サンプリング優先度を設定する

サンプリング優先メカニズムは、すべてのモードにおいて確率的決定よりも優先されるオーバーライドです。

注意: サンプリングの優先順位は、ログとトレースで動作が異なります。

traces パイプラインでは、優先順位属性が 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 に設定します。

設定

次の表は、probabilistic_sampler プロセッサーの構成オプションを示します：

同梱

https://raw.githubusercontent.com/splunk/collector-config-tools/main/cfg-metadata/processor/probabilistic_sampler.yaml

トラブルシューティング

__ ___ ___ _ ______ _____________ _____ ________ ___ ___ ___ ____ __ ___ ____ ____ __ ______ _____________ ______ ___ ___ ___ ____ __ ___ _________ _____

_________ __ ______ _____________ _____ _________

_________ __ ___________ _________ ___ ____ _____ _____

  • ___ _ ________ ___ ___ _______ _______ _________ _______ __ ______ ________

  • ____ ___ ______ ______________ ____ _____ _____ _______ __ ___________ ____ __________ _________ ___ ______ _________ __________ __ _____ ___ ____ _______