3.3. プロセッサー


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

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

3.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]
# ...
Copy to Clipboard

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

timeout

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

200ms

send_batch_size

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

8192

send_batch_max_size

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

0

metadata_keys

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

[]

metadata_cardinality_limit

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

1000

3.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]
# ...
Copy to Clipboard

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

3.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"]
# ...
Copy to Clipboard

Resource Detection Processor を使用する OpenTelemetry Collector

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

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

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

        timeout: 2s
        override: false
# ...
Copy to Clipboard

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

3.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
# ...
Copy to Clipboard

3.3.5. Resource Processor

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

Resource Detection 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
# ...
Copy to Clipboard

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

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

# ...
Copy to Clipboard

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

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

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

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

# ...
Copy to Clipboard

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>"
# ...
Copy to Clipboard

3.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']
# ...
Copy to Clipboard

Kubernetes Attributes Processor を使用する OpenTelemetry Collector

# ...
  config:
    processors:
         k8sattributes:
             filter:
                 node_from_env_var: KUBE_NODE_NAME
# ...
Copy to Clipboard

3.3.8. Filter Processor

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

重要

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

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

OTLP Exporter が有効になっている 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

# ...
Copy to Clipboard

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

3.3.9. Routing Processor

Routing Processor は、ログ、メトリクス、またはトレースを特定のエクスポーターにルーティングします。このプロセッサーは、リソース属性や、受信した gRPC またはプレーン HTTP 要求からヘッダーを読み取り、読み取った値に応じてトレース情報を関連するエクスポーターに送信できます。

重要

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

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

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

# ...
  config:
    processors:
      routing:
        from_attribute: X-Tenant 
1

        default_exporters: 
2

        - jaeger
        table: 
3

        - value: acme
          exporters: [jaeger/acme]
    exporters:
      jaeger:
        endpoint: localhost:14250
      jaeger/acme:
        endpoint: localhost:24250
# ...
Copy to Clipboard

1
ルートを実行するときのルックアップ値の HTTP ヘッダー名。
2
属性値が次のセクションの表に存在しない場合のデフォルトのエクスポーター。
3
どの値をどのエクスポーターにルーティングするかを定義するテーブル。

必要に応じて、attribute_source 設定を作成して、from_attribute フィールドで指定した属性を検索する場所を定義することもできます。サポートされる値は、HTTP ヘッダーを含むコンテキストを検索するための context と、リソース属性を検索するための resource です。

3.3.10. 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>"
# ...
Copy to Clipboard

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

3.3.11. 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>
# ...
Copy to Clipboard

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

3.3.12. 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>
# ...
Copy to Clipboard

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)
# ...
Copy to Clipboard

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

trace_statements

resourcescopespanspanevent

metric_statements

resourcescopemetricdatapoint

log_statements

resourcescopelog

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

ignore

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

silent

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

propagate

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

3.3.13. 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>
          },
        ]
# ...
Copy to Clipboard

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

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

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

    # ...
          policies:
            [
              {
                name: <always_sample_policy>,
                type: always_sample,
              },
            ]
    # ...
    Copy to Clipboard
  • 次のポリシーは、指定された範囲内の期間のトレースのみをサンプリングします。

    # ...
          policies:
            [
              {
                name: <latency_policy>,
                type: latency,
                latency: {threshold_ms: 5000, upper_threshold_ms: 10000} 
    1
    
              },
            ]
    # ...
    Copy to Clipboard
    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
    
              },
            ]
    # ...
    Copy to Clipboard
    1
    指定されている 50 および 100 という値は例です。
  • 次のポリシーは、トレースの一部のみをサンプリングします。

    # ...
          policies:
            [
              {
                name: <probabilistic_policy>,
                type: probabilistic,
                probabilistic: {sampling_percentage: 10} 
    1
    
              },
            ]
    # ...
    Copy to Clipboard
    1
    指定されている 10 という値は例です。
  • 次のポリシーは、ステータスコード (OKERROR、または UNSET) 別にトレースをサンプリングします。

    # ...
          policies:
            [
              {
                name: <status_code_policy>,
                type: status_code,
                status_code: {status_codes: [ERROR, UNSET]}
              },
            ]
    # ...
    Copy to Clipboard
  • 次のポリシーは、リソースおよびレコード属性の文字列値のマッチによってトレースをサンプリングします。

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

    # ...
          policies:
            [
              {
                name: <rate_limiting_policy>,
                type: rate_limiting,
                rate_limiting: {spans_per_second: 35} 
    1
    
              },
            ]
    # ...
    Copy to Clipboard
    1
    指定されている 35 という値は例です。
  • 次のポリシーは、スパンの最小数と最大数 (両端の値を含む) によってトレースをサンプリングします。

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

    # ...
          policies:
            [
              {
                name: <trace_state_policy>,
                type: trace_state,
                trace_state: { key: <key3>, values: [<value1>, <value2>] }
              },
            ]
    # ...
    Copy to Clipboard
  • 次のポリシーは、ブール属性 (リソースとレコード) によってトレースをサンプリングします。

    # ...
          policies:
            [
              {
                name: <bool_attribute_policy>,
                type: boolean_attribute,
                boolean_attribute: {key: <key4>, value: true}
              },
            ]
    # ...
    Copy to Clipboard
  • 次のポリシーは、スパンまたはスパンイベントの特定の 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>\"",
                  ]
                }
              },
            ]
    # ...
    Copy to Clipboard
  • 次のポリシーは、複数のポリシーの組み合わせに基づいてトレースをサンプリングする 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> ] }
                    },
                  ]
                }
              },
            ]
    # ...
    Copy to Clipboard
    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}
                    }
                  ]
                }
              },
            ]
    # ...
    Copy to Clipboard
  • 次のポリシーは、上記のサンプラーを組み合わせて、順序付けとサンプラーごとのレート割り当てを使用してトレースをサンプリングします。

    # ...
          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
                        }
                      ]
                  }
              },
            ]
    # ...
    Copy to Clipboard
    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 値を設定できます。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat