Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

4.3. プロセッサー

プロセッサーは、データを受信してからエクスポートするまでにデータを処理します。プロセッサーはオプションです。デフォルトでは、プロセッサーは有効になっていません。プロセッサーは、すべてのデータソースに対して有効にする必要があります。すべてのプロセッサーがすべてのデータソースをサポートするわけではありません。データソースによっては、複数のプロセッサーが有効になっている可能性があります。プロセッサーの順序が重要であることに注意してください。

現在、Red Hat build of OpenTelemetry では、次の一般提供およびテクノロジープレビューのプロセッサーが利用可能です。

4.3.1. Batch Processor
リンクのコピー

Batch Processor は、トレースとメトリクスをバッチ処理して、テレメトリー情報を転送するために必要な送信接続の数を減らします。

Batch Processor を使用する場合の OpenTelemetry Collector カスタムリソースの例

# ...
  config:
    processors:
      batch:
        timeout: 5s
        send_batch_max_size: 10000
    service:
      pipelines:
        traces:
          processors: [batch]
        metrics:
          processors: [batch]
# ...

Expand
表4.2 Batch Processor で使用されるパラメーター
パラメーター説明デフォルト

timeout

バッチサイズに関係なく、特定の期間後にバッチを送信します。

200ms

send_batch_size

指定された数のスパンまたはメトリクスの後にテレメトリーデータのバッチを送信します。

8192

send_batch_max_size

バッチの最大許容サイズ。send_batch_size 以上である必要があります。

0

metadata_keys

アクティブにすると、client.Metadata で見つかった一意の値セットごとにバッチャーインスタンスが作成されます。

[]

metadata_cardinality_limit

metadata_keys を設定すると、プロセス中に処理されるメタデータのキーと値の組み合わせの数が制限されます。

1000

4.3.2. Memory Limiter Processor
リンクのコピー

Memory Limiter Processor は、Collector のメモリー使用量を定期的にチェックし、ソフトメモリーリミットに達したときにデータ処理を一時停止します。このプロセッサーは、トレース、メトリクス、およびログをサポートします。先行コンポーネント (通常はレシーバー) は、同じデータの送信を再試行することが想定されており、受信データにバックプレッシャーを適用する場合があります。メモリー使用量がハードリミットを超えると、Memory Limiter Processor によってガベージコレクションが強制的に実行されます。

Memory Limiter Processor を使用する場合の OpenTelemetry Collector カスタムリソースの例

# ...
  config:
    processors:
      memory_limiter:
        check_interval: 1s
        limit_mib: 4000
        spike_limit_mib: 800
    service:
      pipelines:
        traces:
          processors: [batch]
        metrics:
          processors: [batch]
# ...

Expand
表4.3 Memory Limiter Processor で使用されるパラメーター
パラメーター説明デフォルト

check_interval

メモリー使用量の測定間の時間。最適な値は 1s です。トラフィックが急増するパターンの場合は、check_interval を減らすか、spike_limit_mib を増やすことができます。

0s

limit_mib

ハードリミット。ヒープに割り当てられるメモリーの最大量 (MiB 単位)。通常、OpenTelemetry Collector の合計メモリー使用量は、この値より約 50 MiB 大きくなります。

0

spike_limit_mib

スパイクリミット。これは、予想されるメモリー使用量の最大スパイク (MiB 単位) です。最適な値は、limit_mib の約 20% です。ソフトリミットを計算するには、limit_mib から spike_limit_mib を減算します。

limit_mib の 20%

limit_percentage

limit_mib と同じですが、使用可能な合計メモリーのパーセンテージとして表されます。limit_mib 設定は、この設定よりも優先されます。

0

spike_limit_percentage

spike_limit_mib と同じですが、使用可能な合計メモリーのパーセンテージとして表されます。limit_percentage 設定と併用することを目的としています。

0

4.3.3. Resource Detection Processor
リンクのコピー

Resource Detection Processor は、OpenTelemetry のリソースセマンティック標準に合わせて、ホストリソースの詳細を識別します。このプロセッサーは、検出された情報を使用して、テレメトリーデータ内のリソース値を追加または置き換えることができます。このプロセッサーはトレースとメトリクスをサポートします。このプロセッサーは、Docket メタデータディテクターや OTEL_RESOURCE_ATTRIBUTES 環境変数ディテクターなど、複数のディテクターで使用できます。

重要

Resource Detection Processor はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

Resource Detection Processor に必要な OpenShift Container Platform の権限

kind: ClusterRole
metadata:
  name: otel-collector
rules:
- apiGroups: ["config.openshift.io"]
  resources: ["infrastructures", "infrastructures/status"]
  verbs: ["get", "watch", "list"]
# ...

Resource Detection Processor を使用する OpenTelemetry Collector

# ...
  config:
    processors:
      resourcedetection:
        detectors: [openshift]
        override: true
    service:
      pipelines:
        traces:
          processors: [resourcedetection]
        metrics:
          processors: [resourcedetection]
# ...

環境変数ディテクターを備えた Resource Detection Processor を使用する OpenTelemetry Collector

# ...
  config:
    processors:
      resourcedetection/env:
        detectors: [env]
1 

        timeout: 2s
        override: false
# ...

1
使用するディテクターを指定します。この例では、環境ディテクターが指定されています。

4.3.4. Attributes Processor
リンクのコピー

Attributes Processor は、スパン、ログ、またはメトリクスの属性を変更できます。入力データをフィルタリングして照合し、特定のアクションに対してそのようなデータを含めたり除外したりするようにこのプロセッサーを設定できます。

このプロセッサーはアクションのリストを操作し、設定で指定された順序でアクションを実行します。次のアクションがサポートされています。

Insert
指定されたキーがまだ存在しない場合は、入力データに新しい属性を挿入します。
更新
キーがすでに存在する場合は、入力データの属性を更新します。
Upsert
挿入アクションと更新アクションを組み合わせます。キーがまだ存在しない場合は、新しい属性を挿入します。キーがすでに存在する場合は属性を更新します。
Delete
入力データから属性を削除します。
Hash
既存の属性値を SHA1 としてハッシュします。
Extract
正規表現ルールを使用して、ルールで定義された入力キーからターゲットキーまでの値を抽出します。ターゲットキーがすでに存在する場合は、Span Processor の to_attributes 設定と同様に、既存の属性をソースとしてターゲットキーがオーバーライドされます。
Convert
既存の属性を指定された型に変換します。

Attributes Processor を使用する OpenTelemetry Collector

# ...
  config:
    processors:
      attributes/example:
        actions:
          - key: db.table
            action: delete
          - key: redacted_span
            value: true
            action: upsert
          - key: copy_key
            from_attribute: key_original
            action: update
          - key: account_id
            value: 2245
            action: insert
          - key: account_password
            action: delete
          - key: account_email
            action: hash
          - key: http.status_code
            action: convert
            converted_type: int
# ...

4.3.5. Resource Processor
リンクのコピー

Resource Processor は、リソース属性に変更を適用します。このプロセッサーは、トレース、メトリクス、およびログをサポートします。

Resource Processor を使用する OpenTelemetry Collector

# ...
  config:
    processors:
      attributes:
      - key: cloud.availability_zone
        value: "zone-1"
        action: upsert
      - key: k8s.cluster.name
        from_attribute: k8s-cluster
        action: insert
      - key: redundant-attribute
        action: delete
# ...

属性は、属性の削除、属性の挿入、または属性のアップサートなど、リソース属性に適用されるアクションを表します。

4.3.6. Span Processor
リンクのコピー

Span Processor は、スパン属性に基づいてスパン名を変更するか、スパン名からスパン属性を抽出します。このプロセッサーは、スパンのステータスを変更したり、スパンを追加したり除外したりすることもできます。このプロセッサーはトレースをサポートしています。

スパンの名前変更には、from_attributes 設定を使用して、新しい名前の属性を指定する必要があります。

重要

Span Processor はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

スパンの名前変更に Span Processor を使用する OpenTelemetry Collector

# ...
  config:
    processors:
      span:
        name:
          from_attributes: [<key1>, <key2>, ...]
1 

          separator: <value>
2 

# ...

1
新しいスパン名を形成するキーを定義します。
2
オプションの区切り文字。

このプロセッサーを使用して、スパン名から属性を抽出できます。

スパン名からの属性抽出に Span Processor を使用する OpenTelemetry Collector

# ...
  config:
    processors:
      span/to_attributes:
        name:
          to_attributes:
            rules:
              - ^\/api\/v1\/document\/(?P<documentId>.*)\/update$
1 

# ...

1
このルールは、抽出の実行方法を定義します。さらにルールを定義できます。たとえば、この場合、正規表現が名前と一致すると、documentID 属性が作成されます。この例では、入力スパン名が /api/v1/document/12345678/update の場合、出力スパン名は /api/v1/document/{documentId}/update となり、新しい "documentId"="12345678" 属性がスパンに追加されます。

スパンステータスを変更できます。

ステータス変更に Span Processor を使用する OpenTelemetry Collector

# ...
  config:
    processors:
      span/set_status:
        status:
          code: Error
          description: "<error_description>"
# ...

4.3.7. Kubernetes Attributes Processor
リンクのコピー

Kubernetes Attributes Processor では、Kubernetes メタデータを使用して、スパン、メトリクス、およびログリソース属性を自動的に設定できます。このプロセッサーは、トレース、メトリクス、およびログをサポートします。このプロセッサーは、Kubernetes リソースを自動的に識別し、そこからメタデータを抽出して、この抽出されたメタデータをリソース属性として関連するスパン、メトリクス、ログに組み込みます。Kubernetes API を利用してクラスター内で動作しているすべての Pod を検出し、IP アドレス、Pod UID、およびその他の関連メタデータの記録を維持します。

Kubernetes Attributes Processor に必要な最小限の OpenShift Container Platform 権限

kind: ClusterRole
metadata:
  name: otel-collector
rules:
  - apiGroups: ['']
    resources: ['pods', 'namespaces']
    verbs: ['get', 'watch', 'list']
  - apiGroups: ['apps']
    resources: ['replicasets']
    verbs: ['get', 'watch', 'list']
# ...

Kubernetes Attributes Processor を使用する OpenTelemetry Collector

# ...
  config:
    processors:
         k8sattributes:
             filter:
                 node_from_env_var: KUBE_NODE_NAME
# ...

4.3.8. Filter Processor
リンクのコピー

Filter Processor は、OpenTelemetry Transformation Language を活用して、テレメトリーデータを破棄する基準を確立します。これらの条件のいずれかが満たされると、テレメトリーデータは破棄されます。OR 論理演算子を使用すると、条件を組み合わせることができます。このプロセッサーは、トレース、メトリクス、およびログをサポートします。

重要

Filter Processor はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

Filter Processor が有効になっている OpenTelemetry Collector カスタムリソース

# ...
  config:
    processors:
      filter/ottl:
        error_mode: ignore
1 

        traces:
          span:
          - 'attributes["container.name"] == "app_container_1"'
2 

          - 'resource.attributes["host.name"] == "localhost"'
3 

# ...

1
エラーモードを定義します。ignore に設定すると、条件によって返されたエラーが無視されます。propagate に設定すると、エラーがパイプラインに返されます。エラーが発生すると、ペイロードが Collector から削除されます。
2
container.name == app_container_1 属性を持つスパンをフィルタリングします。
3
host.name == localhost リソース属性を持つスパンをフィルタリングします。

4.3.9. Cumulative-to-Delta Processor
リンクのコピー

Cumulative-to-Delta Processor は、モノトニックな累積合計メトリクスおよびヒストグラムメトリクスをモノトニックなデルタメトリクスに変換します。

include: または exclude: フィールドを使用し、strict メトリクス名一致または regexp メトリクス名一致を指定すると、メトリクスをフィルタリングできます。

このプロセッサーはメトリクスの前の値を保存することで差分を計算します。そのため、複数の Collector のデプロイメントではなく、1 つのステートフルな Collector インスタンスにメトリクスデータを送信するようにメトリクスソースを設定する必要があります。

このプロセッサーは、モノトニック以外の合計と指数ヒストグラムを変換しません。

重要

Cumulative-to-Delta Processor はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

Cumulative-to-Delta Processor が有効になっている OpenTelemetry Collector カスタムリソースの例

# ...
mode: sidecar
1 

config:
  processors:
    cumulativetodelta:
      include:
2 

        match_type: strict
3 

        metrics:
4 

        - <metric_1_name>
        - <metric_2_name>
      exclude:
5 

        match_type: regexp
        metrics:
        - "<regular_expression_for_metric_names>"
# ...

1
Collector のライフサイクルをメトリクスソースに関連付けるには、累積的な時間的メトリクスを出力するアプリケーションのサイドカーとして Collector を実行できます。
2
オプション: このスタンザで、変換するメトリクスを明示的に定義することにより、プロセッサーが変換するメトリクスを制限できます。このフィールドを省略すると、プロセッサーは exclude フィールドにリストされているメトリクスを除くすべてのメトリクスを変換します。
3
metrics フィールドに指定した値を、strict パラメーターを使用して完全一致として定義するか、regex パラメーターを使用して正規表現として定義します。
4
変換するメトリクスの名前をリストします。プロセッサーは、完全一致または正規表現のマッチを変換します。メトリクスが include フィルターと exclude フィルターの両方に一致する場合、exclude フィルターが優先されます。
5
オプション: ここでメトリクスを明示的に定義することで、特定のメトリクスを変換から除外できます。

4.3.10. Group-by-Attributes Processor
リンクのコピー

Group-by-Attributes Processor は、同じ属性を共有するすべてのスパン、ログレコード、メトリクスデータポイントを、その属性に一致するリソースに再割り当てすることでグループ化します。

重要

Group-by-Attributes Processor はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

少なくとも、このプロセッサーを設定するには、次の例のように、スパン、ログレコード、またはメトリクスデータポイントをグループ化するために使用する属性キーの配列を指定する必要があります。

Group-by-Attributes Processor を使用する場合の OpenTelemetry Collector カスタムリソースの例

# ...
  config:
    processors:
      groupbyattrs:
        keys:
1 

          - <key1>
2 

          - <key2>
# ...

1
グループ化する属性キーを指定します。
2
処理対象のスパン、ログレコード、またはメトリクスデータポイントに、指定の属性キーが 1 つ以上含まれている場合、そのスパン、ログレコード、またはデータポイントが、同じ属性の値を共有するリソースに再割り当てされます。そのようなリソースが存在しない場合は、新しいリソースが作成されます。処理対象のスパン、ログレコード、またはメトリクスデータポイントに指定の属性キーが存在しない場合は、現在のリソースに関連付けられたままになります。同じリソースの複数のインスタンスがまとめられます。

4.3.11. Transform Processor
リンクのコピー

Transform Processor を使用すると、指定したルールに基づいて、OpenTelemetry Transformation Language (OTTL) でテレメトリーデータを変更できます。このプロセッサーは、シグナルタイプごとに、特定の OTTL コンテキストタイプに関連付けられた一連の条件とステートメントを処理し、設定で指定されたとおりに、受信したテレメトリーデータに対して条件とステートメントを順番に実行します。各条件とステートメントで、さまざまな関数を使用してテレメトリーデータにアクセスおよび変更できます。そのため、条件を使用して関数を実行するかどうかを決定できます。

ステートメントは、すべて OTTL で記述します。さまざまなシグナル、トレース、メトリクス、ログに対して複数のコンテキストステートメントを設定できます。context タイプの値で、関連するステートメントを解釈するときにプロセッサーが使用する必要がある OTTL コンテキストを指定します。

重要

Transform Processor はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

設定の概要

# ...
config:
    processors:
      transform:
        error_mode: ignore
1 

        <trace|metric|log>_statements:
2 

          - context: <string>
3 

            conditions:
4 

              - <string>
              - <string>
            statements:
5 

              - <string>
              - <string>
              - <string>
          - context: <string>
            statements:
              - <string>
              - <string>
              - <string>
# ...

1
オプション: 次の表「オプションの error_mode フィールドの値」を参照してください。
2
変換するシグナルを指定します。
3
次の表「context フィールドの値」を参照してください。
4
オプション: 変換を実行するための条件。

Transform Processor を使用する場合の OpenTelemetry Collector カスタムリソースの例

# ...
  config:
    transform:
      error_mode: ignore
      trace_statements:
1 

        - context: resource
          statements:
            - keep_keys(attributes, ["service.name", "service.namespace", "cloud.region", "process.command_line"])
2 

            - replace_pattern(attributes["process.command_line"], "password\\=[^\\s]*(\\s?)", "password=***")
3 

            - limit(attributes, 100, [])
            - truncate_all(attributes, 4096)
        - context: span
4 

          statements:
            - set(status.code, 1) where attributes["http.path"] == "/health"
            - set(name, attributes["http.route"])
            - replace_match(attributes["http.target"], "/user/*/list/*", "/user/{userId}/list/{listId}")
            - limit(attributes, 100, [])
            - truncate_all(attributes, 4096)
# ...

1
トレースシグナルを変換します。
2
リソースのキーを保持します。
3
属性を置き換え、パスワードフィールド内の文字列をアスタリスクに置き換えます。
4
スパンレベルで変換を実行します。
Expand
表4.4 context フィールドの値
シグナルステートメント有効なコンテキスト

trace_statements

resource、scope、span、spanevent

metric_statements

resource、scope、metric、datapoint

log_statements

resource、scope、log

Expand
表4.5 オプションの error_mode フィールドの値
値説明

ignore

ステートメントによって返されたエラーを無視してログに記録し、次のステートメントに進みます。

silent

ステートメントによって返されたエラーを無視してログに記録せず、次のステートメントに進みます。

propagate

パイプラインにエラーを返し、ペイロードをドロップします。暗黙のデフォルト設定です。

4.3.12. Tail Sampling Processor
リンクのコピー

Tail Sampling Processor は、すべてのスパンの完了時に、ユーザー定義のポリシーに従ってトレースをサンプリングします。テールベースのサンプリングを使用すると、関心のあるトレースをフィルタリングし、データの取り込みと保存のコストを削減できます。

重要

Tail Sampling Processor はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

このプロセッサーは、スパンを新しいバッチに再構成し、スパンから元のコンテキストを削除します。

ヒント
  • このプロセッサーは、パイプラインにおいて、コンテキストに依存するプロセッサーの下流に配置してください。たとえば、Kubernetes Attributes Processor の後に配置します。
  • Collector をスケーリングする場合は、指定されたサンプリングポリシーに基づいてこのプロセッサーがサンプリングに関する決定を正しく行えるように、1 つの Collector インスタンスが同じトレースのすべてのスパンを受信するようにしてください。これを実現するには、2 つの Collector レイヤーをセットアップします。1 つ目の Collector レイヤーには Load Balancing Exporter を設定し、2 つ目の Collector レイヤーには Tail Sampling Processor を設定します。

Tail Sampling Processor を使用する場合の OpenTelemetry Collector カスタムリソースの例

# ...
config:
  processors:
    tail_sampling:
1 

      decision_wait: 30s
2 

      num_traces: 50000
3 

      expected_new_traces_per_sec: 10
4 

      policies:
5 

        [
          {
            <definition_of_policy_1>
          },
          {
            <definition_of_policy_2>
          },
          {
            <definition_of_policy_3>
          },
        ]
# ...

1
プロセッサー名。
2
オプション: 最初のスパンの時間から数えた、プロセッサーが各トレースのサンプリングに関する決定を行うまでの決定遅延時間。デフォルトは 30s です。
3
オプション: メモリーに保持されるトレースの数。デフォルトは 50000 です。
4
オプション: 予想される 1 秒あたりの新しいトレースの数。これは、データ構造の割り当てに役立ちます。デフォルトは 0 です。
5
トレース評価用のポリシーの定義。プロセッサーは、指定されたすべてのポリシーに照らして各トレースを評価し、トレースをサンプリングするかドロップします。

次のリストからポリシーを選択して組み合わせることができます。

  • 次のポリシーはすべてのトレースをサンプリングします。 

    # ...
      policies:
        [
          {
            name: <always_sample_policy>,
            type: always_sample,
          },
        ]
# ...

  • 次のポリシーは、指定された範囲内の期間のトレースのみをサンプリングします。 

    # ...
      policies:
        [
          {
            name: <latency_policy>,
            type: latency,
            latency: {threshold_ms: 5000, upper_threshold_ms: 10000}
    1 
    
          },
        ]
# ...
    1
    指定されている 5000 および 10000 という値は例です。最も早い開始時刻の値と最も遅い終了時刻の値を確認することで、必要なレイテンシーの値を推定できます。upper_threshold_ms フィールドを省略すると、このポリシーは指定された threshold_ms 値を超えるすべてのレイテンシーをサンプリングします。

  • 次のポリシーは、リソースおよびレコード属性の数値のマッチによってトレースをサンプリングします。 

    # ...
      policies:
        [
          {
            name: <numeric_attribute_policy>,
            type: numeric_attribute,
            numeric_attribute: {key: <key1>, min_value: 50, max_value: 100}
    1 
    
          },
        ]
# ...
    1
    指定されている 50 および 100 という値は例です。

  • 次のポリシーは、トレースの一部のみをサンプリングします。 

    # ...
      policies:
        [
          {
            name: <probabilistic_policy>,
            type: probabilistic,
            probabilistic: {sampling_percentage: 10}
    1 
    
          },
        ]
# ...
    1
    指定されている 10 という値は例です。

  • 次のポリシーは、ステータスコード (OK、ERROR、または UNSET) 別にトレースをサンプリングします。 

    # ...
      policies:
        [
          {
            name: <status_code_policy>,
            type: status_code,
            status_code: {status_codes: [ERROR, UNSET]}
          },
        ]
# ...

  • 次のポリシーは、リソースおよびレコード属性の文字列値のマッチによってトレースをサンプリングします。 

    # ...
      policies:
        [
          {
            name: <string_attribute_policy>,
            type: string_attribute,
            string_attribute: {key: <key2>, values: [<value1>, <val>*], enabled_regex_matching: true, cache_max_size: 10}
    1 
    
          },
        ]
# ...
    1
    このポリシー定義は、完全一致と正規表現による値のマッチングの両方をサポートしています。cache_max_size フィールドに指定されている 10 という値は例です。

  • 次のポリシーは、1 秒あたりのスパン数のレートによってトレースをサンプリングします。 

    # ...
      policies:
        [
          {
            name: <rate_limiting_policy>,
            type: rate_limiting,
            rate_limiting: {spans_per_second: 35}
    1 
    
          },
        ]
# ...
    1
    指定されている 35 という値は例です。

  • 次のポリシーは、スパンの最小数と最大数 (両端の値を含む) によってトレースをサンプリングします。 

    # ...
      policies:
        [
          {
            name: <span_count_policy>,
            type: span_count,
            span_count: {min_spans: 2, max_spans: 20}
    1 
    
          },
        ]
# ...
    1
    トレース内の全スパンの合計がしきい値の範囲外である場合、トレースはサンプリングされません。指定されている 2 および 20 という値は例です。

  • 次のポリシーは、TraceState 値のマッチによってトレースをサンプリングします。 

    # ...
      policies:
        [
          {
            name: <trace_state_policy>,
            type: trace_state,
            trace_state: { key: <key3>, values: [<value1>, <value2>] }
          },
        ]
# ...

  • 次のポリシーは、ブール属性 (リソースとレコード) によってトレースをサンプリングします。 

    # ...
      policies:
        [
          {
            name: <bool_attribute_policy>,
            type: boolean_attribute,
            boolean_attribute: {key: <key4>, value: true}
          },
        ]
# ...

  • 次のポリシーは、スパンまたはスパンイベントの特定の OTTL ブール条件によってトレースをサンプリングします。 

    # ...
      policies:
        [
          {
            name: <ottl_policy>,
            type: ottl_condition,
            ottl_condition: {
              error_mode: ignore,
              span: [
                "attributes[\"<test_attr_key_1>\"] == \"<test_attr_value_1>\"",
                "attributes[\"<test_attr_key_2>\"] != \"<test_attr_value_1>\"",
              ],
              spanevent: [
                "name != \"<test_span_event_name>\"",
                "attributes[\"<test_event_attr_key_2>\"] != \"<test_event_attr_value_1>\"",
              ]
            }
          },
        ]
# ...

  • 次のポリシーは、複数のポリシーの組み合わせに基づいてトレースをサンプリングする AND ポリシーです。 

    # ...
      policies:
        [
          {
            name: <and_policy>,
            type: and,
            and: {
              and_sub_policy:
              [
                {
                  name: <and_policy_1>,
                  type: numeric_attribute,
                  numeric_attribute: { key: <key1>, min_value: 50, max_value: 100 }
    1 
    
                },
                {
                  name: <and_policy_2>,
                  type: string_attribute,
                  string_attribute: { key: <key2>, values: [ <value1>, <value2> ] }
                },
              ]
            }
          },
        ]
# ...
    1
    指定されている 50 および 100 という値は例です。

  • 次のポリシーは、複数のポリシーの組み合わせに基づいてサンプリングからトレースをドロップする DROP ポリシーです。 

    # ...
      policies:
        [
          {
            name: <drop_policy>,
            type: drop,
            drop: {
              drop_sub_policy:
              [
                {
                  name: <drop_policy_1>,
                  type: string_attribute,
                  string_attribute: {key: url.path, values: [\/health, \/metrics], enabled_regex_matching: true}
                }
              ]
            }
          },
        ]
# ...

  • 次のポリシーは、上記のサンプラーを組み合わせて、順序付けとサンプラーごとのレート割り当てを使用してトレースをサンプリングします。 

    # ...
      policies:
        [
          {
            name: <composite_policy>,
            type: composite,
            composite:
              {
                max_total_spans_per_second: 100,
    1 
    
                policy_order: [<composite_policy_1>, <composite_policy_2>, <composite_policy_3>],
                composite_sub_policy:
                  [
                    {
                      name: <composite_policy_1>,
                      type: numeric_attribute,
                      numeric_attribute: {key: <key1>, min_value: 50}
                    },
                    {
                      name: <composite_policy_2>,
                      type: string_attribute,
                      string_attribute: {key: <key2>, values: [<value1>, <value2>]}
                    },
                    {
                      name: <composite_policy_3>,
                      type: always_sample
                    }
                  ],
                  rate_allocation:
                  [
                    {
                      policy: <composite_policy_1>,
                      percent: 50
    2 
    
                    },
                    {
                      policy: <composite_policy_2>,
                      percent: 25
                    }
                  ]
              }
          },
        ]
# ...
    1 2
    適用されるポリシーの順序に従ってスパンの割合を割り当てます。たとえば、max_total_spans_per_second フィールドに 100 という値を設定した場合、rate_allocation セクションで次のように値を設定できます。policy: <composite_policy_1> セクションで、50 パーセントの値を設定して 1 秒あたり 50 スパンを割り当てます。policy: <composite_policy_2> セクションで、25 パーセントの値を設定して 1 秒あたり 25 スパンを割り当てます。残りの容量を埋めるには、name: <composite_policy_3> セクションの type フィールドに always_sample 値を設定できます。

4.3.13. Probabilistic Sampling Processor
リンクのコピー

大量のテレメトリーデータを処理し、処理するデータ量を減らすことでコストを削減したい場合は、Tail Sampling Processor の代わりに Probabilistic Sampling Processor を使用できます。

重要

Probabilistic Sampling Processor は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

プロセッサーは、指定された割合のトレース範囲またはログレコードをステートレスに、そしてリクエストごとにサンプリングします。

プロセッサーは、使用された有効サンプリング確率に関する情報をテレメトリーデータに追加します。

  • トレーススパンでは、プロセッサーは、しきい値とオプションのランダム性情報を W3C Trace Context tracestate フィールドにエンコードします。
  • ログレコードでは、プロセッサーはしきい値とランダム性の情報を属性としてエンコードします。

以下は、トレース範囲をサンプリングするための Probabilistic Sampling Processor の OpenTelemetryCollector カスタムリソース設定の例です。 

# ...
  config:
    processors:
      probabilistic_sampler:
1 

        sampling_percentage: 15.3
2 

        mode: "proportional"
3 

        hash_seed: 22
4 

        sampling_precision: 14
5 

        fail_closed: true
6 

# ...
service:
  pipelines:
    traces:
      processors: [probabilistic_sampler]
# ...
1
トレースパイプラインの場合、ランダム性のソースとなるのは、スパントレース ID のハッシュ値です。
2
必須。スパンをサンプリングする割合を、32 ビット浮動小数点数のパーセンテージ値で受け入れます。
3
任意。サンプリングロジックのモードにサポートされている文字列値 (デフォルトは hash_seed、proportional、または equalizing) を受け入れます。hash_seed モードは、トレース ID に Fowler–Noll–Vo (FNV) ハッシュ関数を適用し、そのハッシュ値をサンプリングのパーセンテージ値と比較します。トレース ID 以外のテレメトリー単位で hash_seed モードを使用することもできます。proportional モードでは、総スパン量の厳密な確率ベースの比率がサンプリングされ、OpenTelemetry および World Wide Web Consortium の仕様に基づいています。equalizing モードは、パイプライン全体でサンプリング確率を最小値に下げたり、クライアント SDK にさまざまなサンプリング設定がある Collector デプロイメントで均一なサンプリング確率を適用したりする際に役立ちます。
4
任意。ハッシュアルゴリズムの計算に使用される 32 ビットの符号なし整数を受け入れます。このフィールドが設定されていない場合、デフォルトのシード値は 0 です。複数の層の Collector インスタンスを使用する場合は、同じ層のすべての Collector を同じシード値に設定する必要があります。
5
任意。サンプリングしきい値をエンコードするために使用される 16 進数の桁数を決定します。整数値を受け入れます。サポートされる値は 1-14 です。デフォルト値 4 では、しきい値に 16 を超える有効ビットが含まれる場合、つまり 56 ビットを使用する proportional モードの場合、しきい値は丸められます。proportional モードを選択した場合は、前のサンプラーによって適用された精度を維持するために、より大きな値を使用します。
6
任意。サンプリングエラーのあるスパンを拒否します。ブール値を受け入れます。デフォルト値は true です。

以下は、ログレコードをサンプリングするための Probabilistic Sampling Processor の OpenTelemetryCollector カスタムリソース設定の例です。 

# ...
  config:
    processors:
      probabilistic_sampler/logs:
        sampling_percentage: 15.3
1 

        mode: "hash_seed"
2 

        hash_seed: 22
3 

        sampling_precision: 4
4 

        attribute_source: "record"
5 

        from_attribute: "<log_record_attribute_name>"
6 

        fail_closed: true
7 

# ...
service:
  pipelines:
    logs:
      processors: [ probabilistic_sampler/logs ]
# ...
1
必須。スパンをサンプリングする割合を、32 ビット浮動小数点数のパーセンテージ値で受け入れます。
2
任意。サンプリングロジックモードにサポートされている文字列値 (デフォルトは hash_seed、equalizing、または proportional) を受け入れます。hash_seed モードは、トレース ID または指定されたログレコードの属性に Fowler–Noll–Vo (FNV) ハッシュ関数を適用し、そのハッシュ値をサンプリングのパーセンテージ値と比較します。また、hash_seed モードは、トレース ID 以外のテレメトリー単位で使用することもできます。たとえば、service.instance.id リソース属性を使用して、一定の割合の Pod からログレコードを収集できます。equalizing モードは、パイプライン全体でサンプリング確率を最小値に下げたり、クライアント SDK にさまざまなサンプリング設定がある Collector デプロイメントで均一なサンプリング確率を適用したりする際に役立ちます。proportional モードでは、総スパン量の厳密な確率ベースの比率がサンプリングされ、OpenTelemetry および World Wide Web Consortium の仕様に基づいています。
3
任意。ハッシュアルゴリズムの計算に使用される 32 ビットの符号なし整数を受け入れます。このフィールドが設定されていない場合、デフォルトのシード値は 0 です。複数の層の Collector インスタンスを使用する場合は、同じ層のすべての Collector を同じシード値に設定する必要があります。
4
任意。サンプリングしきい値をエンコードするために使用される 16 進数の桁数を決定します。整数値を受け入れます。サポートされる値は 1-14 です。デフォルト値 4 では、しきい値に 16 を超える有効ビットが含まれる場合、つまり 56 ビットを使用する proportional モードの場合、しきい値は丸められます。proportional モードを選択した場合は、前のサンプラーによって適用された精度を維持するために、より大きな値を使用します。
5
任意。from_attribute でログレコード属性を検索する場所を定義します。ログレコード属性はランダム性のソースとして使用されます。デフォルトの traceID 値または record 値を受け入れます。
6
任意。一意のログレコード ID など、サンプリングハッシュの計算に使用されるログレコード属性の名前。文字列値を受け入れます。デフォルト値は "" です。このフィールドは、トレース ID が存在しないか、トレース ID サンプリングが無効になっているか、attribute_source フィールドが record 値に設定されている状況で、ランダム性のソースとしてログレコード属性を指定する必要がある場合にのみ使用してください。
7
任意。サンプリングエラーのあるスパンを拒否します。ブール値を受け入れます。デフォルト値は true です。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る