Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

4.3. Processors

处理器处理接收和导出的数据。处理器是可选的。默认情况下，不启用处理器。每个数据源都必须启用处理器。不是所有处理器都支持所有数据源。根据数据源，可能会启用多个处理器。请注意，处理器的顺序很重要。

目前，红帽构建的 OpenTelemetry 提供了以下正式发行(GA)和技术预览处理器：

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 使用的参数
参数描述default

timeout

将批处理发送到特定的持续时间，无论批处理大小如何。

200ms

send_batch_size

在指定数量的 span 或 metrics 后发送遥测数据的批处理。

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 的内存用量，并在达到软内存限制时暂停数据处理。这个处理器支持 trace、metrics 和 logs。前面的组件（通常是接收器）应该重试发送同一数据，并可能对传入的数据应用回溯。当内存用量超过硬限制时，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 使用的参数
参数描述default

check_interval

内存用量测量之间的时间。最佳值为 1s。对于 spiky 流量模式，您可以减少 check_interval 或增加 spike_limit_mib。

0s

limit_mib

硬限制，即堆上分配的最大内存量（以 MiB 为单位）。通常，OpenTelemetry Collector 的内存用量大约比这个值高 50 MiB。

0

spike_limit_mib

spike 限制，这是 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 的资源语义标准保持一致。使用检测到的信息，此处理器可以在遥测数据中添加或替换资源值。这个处理器支持 trace 和 metrics。您可以将这个处理器与多个检测器一起使用，如 Docket 元数据检测器或 OTEL_RESOURCE_ATTRIBUTES 环境变量检测器。

重要

Resource Detection Processor 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

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]
# ...

OpenTelemetry Collector 使用带有环境变量检测器的资源检测器

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

        timeout: 2s
        override: false
# ...

1
指定要使用的检测器。在本例中，指定了环境检测器。

4.3.4. Attributes Processor
复制链接

Attributes Processor 可以修改 span, log, 或 metric 的属性。您可以配置此处理器来过滤和匹配输入数据，并为特定操作包含或排除此类数据。

处理器对操作列表进行操作，按配置中指定的顺序执行它们。支持以下操作：

insert
当指定的键尚不存在时，将新属性插入到输入数据中。
Update（更新）
如果密钥已存在，更新输入数据中的属性。
Upsert
合并 insert 和 update 操作：如果键尚不存在，则插入新属性。如果密钥已存在，则更新 属性。
删除
从输入数据中删除属性。
Hash
将现有属性值哈希为 SHA1。
extract
通过使用输入键的正则表达式规则将值提取到规则中定义的目标键。如果目标键已存在，它将被像使用现有属性作为源的 Span 处理器 to_attributes 设置一样覆盖。
Convert
将现有属性转换为指定类型。

OpenTelemetry Collector 使用 ttributes Processor

# ...
  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 应用对资源属性的更改。这个处理器支持 trace、metrics 和 logs。

使用 Resource Processor 的 OpenTelemetry 收集器

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

属性代表应用到资源属性的操作，如删除属性、插入属性或 upsert 属性。

4.3.6. Span Processor
复制链接

Span Processor 根据其属性修改 span 名称，或者从 span 名称中提取 span 属性。此处理器也可以更改 span 状态，并包含或排除 span。这个处理器支持 trace。

span rename 需要使用 from_attributes 配置为新名称指定属性。

重要

Span Processor 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

OpenTelemetry Collector 使用 Span Processor 重命名 span

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

          separator: <value>
2 

# ...

1
定义组成新 span 名称的密钥。
2
可选分隔符。

您可以使用处理器从 span 名称中提取属性。

OpenTelemetry Collector 使用 Span Processor 从范围名称中提取属性

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

# ...

1
此规则定义如何执行提取。您可以定义更多规则：例如，如果正则表达式与名称匹配，则会创建一个 documentID 属性。在本例中，如果输入 span 名称是 /api/v1/document/12345678/update，则会产生 /api/v1/document/{documentId}/update 输出 span 名称，并且新的 "documentId"="12345678" 属性被添加到 span 中。

您可以修改 span 状态。

OpenTelemetry Collector 使用 Span Processor 进行状态更改

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

4.3.7. Kubernetes Attributes Processor
复制链接

Kubernetes Attributes Processor 使用 Kubernetes 元数据启用 span、metrics 和 log 资源属性的自动配置。这个处理器支持 trace、metrics 和 logs。此处理器自动识别 Kubernetes 资源，从它们中提取元数据，并将此提取的元数据作为资源属性合并到相关的 span、metrics 和 logs 中。它使用 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']
# ...

OpenTelemetry Collector 使用 Kubernetes Attributes Processor

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

4.3.8. Filter Processor
复制链接

Filter Processor 利用 OpenTelemetry Transformation Language 来建立丢弃遥测数据的条件。如果满足这些条件，遥测数据将被丢弃。您可以使用逻辑 OR 运算符对多个条件进行组合。这个处理器支持 trace、metrics 和 logs。

重要

Filter Processor 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

OpenTelemetry Collector 自定义资源带有启用的 Filter Processor

# ...
  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 属性的 span。
3
过滤具有 host.name == localhost 资源属性的 span。

4.3.9. Cumulative-to-Delta Processor
复制链接

Cumulative-to-Delta Processor 将 monotonic、cumulative-sum 和 histogram 指标转换为 monotonic delta 指标。

您可以使用 include: 或 exclude: 字段过滤指标，并指定 strict 或 regexp 进行名称匹配。

由于此处理器通过存储指标先前的值来计算 delta，所以您必须设置指标源，以将指标数据发送到单个有状态收集器实例，而不是部署多个 Collector。

这个处理器不会转换非单调和以及指数直方图。

重要

Cumulative-to-Delta Processor 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

带有启用了 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 作为 sidecar 运行，来向发送累积时序指标的应用程序运行。
2
可选：您可以通过在此片段中明确定义您要转换的指标来限制处理器转换的指标数据。如果省略此字段，处理器会转换所有指标，但 exclude 字段中列出的指标除外。
3
使用 strict 参数或正则表达式，定义您在 metrics 字段中提供的值作为完全匹配。
4
列出您要转换的指标的名称。处理器对正则表达式进行完全匹配或匹配。如果指标与 include 和 exclude 过滤都匹配，则 exclude 过滤具有更高的优先权。
5
可选：您可以通过在此处明确定义，从转换中排除某些指标。

4.3.10. Group-by-Attributes Processor
复制链接

Group-by-Attributes Processor 组所有 span、logging 记录和指标数据点，通过将其重新分配给与这些属性匹配的资源。

重要

Group-by-Attributes Processor 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

至少配置此处理器涉及指定要将 span、日志记录或指标数据点分组在一起的属性键数组，如下例所示：

使用 Group-by-Attributes Processor 时 OpenTelemetry Collector 自定义资源的示例

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

          - <key1>
2 

          - <key2>
# ...

1
指定要分组的属性键。
2
如果处理的范围、日志记录或指标数据点至少包含指定的属性键，则会将其重新分配给共享相同属性值的资源；如果没有这样的资源，则会创建一个新资源。如果处理的范围、日志记录或指标数据点中没有指定的属性键，则它与其当前资源关联。整合同一资源的多个实例。

4.3.11. Transform Processor
复制链接

Transform Processor 启用根据指定的规则修改遥测数据，并在 OpenTelemetry Transformation Language (OTTL) 中修改遥测数据。对于每个信号类型，处理器处理与特定 OTTL 上下文类型关联的一系列条件和语句，然后按照配置中指定的在传入遥测数据上执行它们。每个条件和语句都可以使用各种功能访问和修改遥测数据，允许条件指示是否要执行的函数。

所有语句都是在 OTTL 中编写的。您可以为不同的信号、跟踪、指标和日志配置多个上下文语句。context 类型的值指定在解释关联的语句时，处理器必须使用哪个 OTTL 上下文。

重要

Transform 处理器只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

配置概述

# ...
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
可选：请参阅下表 "Values for the optional 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
转换 trace 信号。
2
在资源中保留密钥。
3
使用星号替换 password 字段中的属性和字符串字符。
4
在 span 级别执行转换。
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 字段的值
value描述

ignore

忽略并记录声明返回的错误，然后继续到下一个语句。

silent

忽略并不记录声明返回的错误，然后继续到下一个语句。

propagate

返回错误管道并丢弃有效负载。隐式默认值。

4.3.12. tail Sampling Processor
复制链接

当所有 span 都完成后，Tail Sampling 处理器会根据用户定义的策略抽样 trace。通过基于尾部的抽样，您可以过滤感兴趣的追踪并降低数据生成和存储成本。

重要

Tail Sampling 处理器只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

此处理器将 span 组合成新的批处理，并剥离原始上下文。

提示
  • 在管道中，将依赖上下文的任何处理器下游放在管道中：例如，在 Kubernetes Attributes Processor 后。
  • 如果扩展 Collector，请确保一个 Collector 实例接收同一 trace 的所有范围，以便此处理器根据指定的抽样策略做出正确的抽样决策。您可以通过设置 Collector 的两层来实现此目的：使用 Load Balancing Exporter 的 Collector 的第一层，以及使用 Tail Sampling Processor 的 Collector 的第二个层。

使用 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
可选：在处理器对每个 trace 做出抽样决定前，决策延迟时间从第一个范围的时间段内计算。默认值为 30s。
3
可选：保存在内存中的追踪数量。默认值为 50000。
4
可选：预期每秒新 trace 数量，这有助于分配数据结构。默认为 0。
5
用于追踪评估的策略定义。处理器会根据所有指定的策略评估每个追踪，然后示例或丢弃 trace。

您可以从以下列表中选择和组合策略：

  • 以下策略示例所有 trace： 

    # ...
      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 值的所有延迟。

  • 以下策略示例根据数字值与 resource 和 record 属性匹配： 

    # ...
      policies:
        [
          {
            name: <numeric_attribute_policy>,
            type: numeric_attribute,
            numeric_attribute: {key: <key1>, min_value: 50, max_value: 100}
    1 
    
          },
        ]
# ...
    1
    提供的 50 和 100 值是示例。

  • 以下策略示例仅对 trace 的百分比进行抽样： 

    # ...
      policies:
        [
          {
            name: <probabilistic_policy>,
            type: probabilistic,
            probabilistic: {sampling_percentage: 10}
    1 
    
          },
        ]
# ...
    1
    提供的 10 值是一个示例。

  • 以下策略示例根据状态代码对 trace 进行抽样： OK、ERROR 或 UNSET ： 

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

  • 以下策略示例根据字符串值与 resource 和 record 属性匹配： 

    # ...
      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 值是一个示例。

  • 以下策略示例根据每秒 span 率进行追踪： 

    # ...
      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
    如果 trace 中的所有 span 的总和超出范围阈值，则 trace 不会被抽样。提供的 2 和 20 值是示例。

  • 以下通过 TraceState 值的 trace 匹配： 

    # ...
      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 条件为 span 或 span 事件进行追踪： 

    # ...
      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 策略，它基于多个策略的组合对 trace 进行抽样： 

    # ...
      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 策略，它根据多个策略的组合从抽样中丢弃 trace： 

    # ...
      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}
                }
              ]
            }
          },
        ]
# ...

  • 以下策略示例根据前面的抽样器的组合，以及每个 sampler 的排序和速率分配的组合对 trace 进行抽样： 

    # ...
      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
    根据应用策略的顺序分配 span 的百分比。例如，如果您在 max_total_spans_per_second 字段中设置了 100 值，您可以在 rate_allocation 部分中设置以下值：< composite_policy_1> 部分中的 50 percent 值每秒分配 50 个 span，policy: < composite_policy_2> 部分中的 25% 值分配给每秒 25 个 span。要填充剩余的容量，您可以在名称的 type 字段中设置 always_sample 值 ： <composite_policy_3> 部分。

4.3.13. probabilistic Sampling Processor
复制链接

如果您处理大量遥测数据并通过降低处理的数据来降低成本，您可以使用 Probabilistic Sampling Processor 作为 Tail Sampling Processor 的替代选择。

重要

probabilistic Sampling 处理器只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

处理器对指定百分比进行抽样，以无状态和每个请求记录。

处理器将有关已用有效抽样概率的信息添加到遥测数据中：

  • 在 trace span 中，处理器在 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
对于追踪管道，随机性的来源是 span 跟踪 ID 的散列值。
2
必需。接受 32 位浮点百分比值，在其中对 span 进行抽样。
3
可选。接受抽样逻辑模式支持的字符串值：默认的 hash_seed、proportional，或等于。hash_seed 模式将 Fowler-Noll-Vo (FNV)哈希功能应用到 trace ID，并将散列值用于抽样百分比值。您还可以使用 hash_seed 模式，以及 trace ID 以外的遥测单元。proportional 模式对总范围数量有严格的、基于概率的比例进行抽样，并基于 OpenTelemetry 和 World Wide Web Consortium 规格。相等 模式可用于将抽样概率降低到整个管道中的最小值，或者在 Collector 部署中应用统一的抽样可能性，其中 client SDK 具有混合抽样配置。
4
可选。接受 32 位未签名的整数，该整数用于计算哈希算法。如果没有配置此字段，则默认的 seed 值为 0。如果使用多个 Collector 实例层，您必须将同一层的所有收集器配置为相同的 seed 值。
5
可选。决定用于编码抽样阈值的十六进制数。接受整数值。支持的值有 1-14。如果阈值 4 包含超过 16 个重要位（这是使用 56 位 的比例 模式）时，默认值 4 会导致对阈值进行舍入。如果您选择 proportional 模式，请为前面的 samplers 应用保留精度的目的使用更大的值。
6
可选。拒绝 span，抽样错误。接受布尔值。默认值为 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 位浮点百分比值，在其中对 span 进行抽样。
2
可选。接受抽样逻辑模式支持的字符串值：默认的 hash_seed、等于 或 proportional。hash_seed 模式将 Fowler-Noll-Vo (FNV)哈希功能应用到 trace ID 或指定的日志记录属性，然后根据抽样百分比值来权衡散列值。您也可以将 hash_seed 模式与遥测 ID 的其他单元一起使用，例如，使用 service.instance.id 资源属性从 pod 中收集日志记录。相等 模式可用于将抽样概率降低到整个管道中的最小值，或者在 Collector 部署中应用统一的抽样可能性，其中 client SDK 具有混合抽样配置。proportional 模式对总范围数量有严格的、基于概率的比例进行抽样，并基于 OpenTelemetry 和 World Wide Web Consortium 规格。
3
可选。接受 32 位未签名的整数，该整数用于计算哈希算法。如果没有配置此字段，则默认的 seed 值为 0。如果使用多个 Collector 实例层，您必须将同一层的所有收集器配置为相同的 seed 值。
4
可选。决定用于编码抽样阈值的十六进制数。接受整数值。支持的值有 1-14。如果阈值 4 包含超过 16 个重要位（这是使用 56 位 的比例 模式）时，默认值 4 会导致对阈值进行舍入。如果您选择 proportional 模式，请为前面的 samplers 应用保留精度的目的使用更大的值。
5
可选。定义 from_attribute 中查找日志记录属性的位置。日志记录属性用作随机性的来源。接受默认的 traceID 值或 记录 值。
6
可选。用于计算抽样哈希的日志记录属性的名称，如唯一的日志记录 ID。接受字符串值。默认值为 ""。只有在需要在缺少 trace ID 或 trace ID 抽样被禁用或将 attribute_source 字段设置为记录值时，才需要指定日志记录属性作为随机性时才 使用这个选项。
7
可选。拒绝 span，抽样错误。接受布尔值。默认值为 true。
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat返回顶部