#配置 OpenTelemetry Collector

#功能概览

你可以配置 OpenTelemetry Collector 以满足你的可观测性需求。在深入了解 Collector 配置的工作方式之前，建议先熟悉以下内容：

• Data Collection Concepts，以了解适用于 OpenTelemetry Collector 的仓库。
• Security Guidelines。

#配置结构

任何 Collector 配置文件的结构都由四类与遥测数据交互的 pipeline 组件组成：

• Receivers
• Processors
• Exporters
• Connectors

配置好每个 pipeline 组件后，必须通过配置文件 service 部分 中定义的 pipeline 来启用它。

除了 pipeline 组件之外，你还可以配置 Extensions，它们提供可添加到 Collector 中的附加功能，例如诊断工具。Extensions 不需要直接访问遥测数据，并且通过 service 部分 启用。

下面是一个包含 receivers、processors、exporters 和三个 extensions 的 Collector 配置示例。

重要说明： 当所有客户端都在本地时，通常会将 endpoint 绑定到 localhost，但为了方便，我们的示例配置使用“未指定”地址 0.0.0.0。Collector 当前默认使用 localhost。有关这些 endpoint 配置值的详细信息，请参见 防止拒绝服务攻击的安全措施。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
processors:
  batch:

exporters:
  otlp:
    endpoint: otelcol:4317

extensions:
  health_check:
  pprof:
  zpages:

service:
  extensions: [health_check, pprof, zpages]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

请注意，receivers、processors、exporters 和 pipelines 都使用 type[/name] 格式的组件标识符进行定义，例如 otlp 或 otlp/2。只要标识符唯一，你就可以多次定义同一类型的组件。例如：

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  otlp/2:
    protocols:
      grpc:
        endpoint: 0.0.0.0:55690

processors:
  batch:
  batch/test:

exporters:
  otlp:
    endpoint: otelcol:4317
  otlp/2:
    endpoint: otelcol2:4317

extensions:
  health_check:
  pprof:
  zpages:

service:
  extensions: [health_check, pprof, zpages]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    traces/2:
      receivers: [otlp/2]
      processors: [batch/test]
      exporters: [otlp/2]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

配置还可以包含其他文件，从而允许 Collector 将它们合并为单个内存中的 YAML 配置：

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters: ${file:exporters.yaml}

service:
  extensions: []
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [otlp]

exporters.yaml 文件可能包含：

otlp:
  endpoint: otelcol.observability.svc.cluster.local:443

生成的内存配置将是：

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters:
  otlp:
    endpoint: otelcol.observability.svc.cluster.local:443

service:
  extensions: []
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [otlp]

#Receivers

Receivers 从一个或多个源收集遥测数据。它们可以是基于拉取或基于推送的，并且可能支持一个或多个 数据源。

通常，receiver 会以指定格式摄取数据，将其转换为内部格式，然后将其传递给适用 pipeline 中定义的 processors 和 exporters。

Receivers 在 receivers 部分中配置。默认情况下，不会配置任何 receiver。你必须配置一个或多个 receivers。许多 receiver 都带有默认设置，因此只指定 receiver 名称可能就足够了。如果你需要自定义或修改默认配置，可以在此部分进行。你指定的任何设置都会覆盖默认值（如果存在）。

注意： 配置 receiver 并不会启用它。必须通过将其添加到 service 部分 中相应的 pipeline 来启用 receiver。

下面是常见的 receiver 配置示例。

提示： 如需更详细的 receiver 配置，请参阅 receiver README。

#OTLP 接收器

OTLP 接收器使用 OpenTelemetry Protocol (OTLP) 摄取 traces、metrics 和 logs。

YAML 示例

  config: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
            tls:
              ca_file: ca.pem
              cert_file: cert.pem
              key_file: key.pem
              client_ca_file: client.pem
              reload_interval: 1h
          http:
            endpoint: 0.0.0.0:4318

    service:
      pipelines:
        traces:
          receivers: [otlp]
        metrics:
          receivers: [otlp]

protocols 参数说明

#Jaeger 接收器

Jaeger 接收器以 Jaeger 格式摄取 traces。

YAML 示例

  config: |
    receivers:
      jaeger:
        protocols:
          grpc:
            endpoint: 0.0.0.0:14250
          thrift_http:
            endpoint: 0.0.0.0:14268
          thrift_compact:
            endpoint: 0.0.0.0:6831
          thrift_binary:
            endpoint: 0.0.0.0:6832

    service:
      pipelines:
        traces:
          receivers: [jaeger]

protocols 参数说明

#Zipkin 接收器

Zipkin 接收器同时摄取 Zipkin v1 和 v2 格式的 traces。

YAML 示例

  config: |
    receivers:
      zipkin:
        endpoint: 0.0.0.0:9411

    service:
      pipelines:
        traces:
          receivers: [zipkin]

zipkin 参数说明

#Processors

Processors 在将数据发送到 exporters 之前，会修改或转换 receivers 收集的数据。数据处理基于为每个 processor 定义的规则或设置，这些规则或设置可能包括过滤、删除、重命名或重新计算遥测数据。pipeline 中 processors 的顺序决定了 Collector 对 signals 应用处理操作的顺序。

Processors 是可选的，但某些 processors 建议使用。

你可以在 Collector 配置文件的 processors 部分中配置 processors。你指定的任何设置都会覆盖默认值（如果存在）。

注意： 配置 processor 并不会启用它。必须通过将其添加到 service 部分 中相应的 pipeline 来启用 processor。默认情况下，不会启用任何 processor。

下面是常见 processor 配置的示例。

提示： 你可以通过合并 opentelemetry-collector-contrib 和 opentelemetry-collector 的列表，来获取完整的 processor 列表。有关更详细的 processor 配置，请参阅 processor README。

#Batch Processor

Batch Processor 会根据大小或时间对 spans、metrics 或 logs 进行批处理和压缩。批处理有助于减少 exporters 发出的提交请求数量，并帮助调节 pipeline 中来自多个或单个 receivers 的遥测数据流量。

YAML 示例

  config: |
    processor:
      batch:
        timeout: 5s
        send_batch_max_size: 10000
    service:
      pipelines:
        traces:
          processors: [batch]
        metrics:
          processors: [batch]

batch 参数说明

#Memory Limiter Processor

Memory Limiter Processor 会定期检查 Collector 的内存使用情况，并在达到软内存限制时暂停数据处理，从而避免内存不足（out-of-memory）场景。该 processor 支持 spans、metrics 和 logs。它通常是 receivers 之后的第一个组件，期望重试以发送相同的数据，并可能对传入数据施加反压。当内存使用超过硬限制时，Memory Limiter Processor 会强制执行垃圾回收。

YAML 示例

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

memory_limiter 参数说明

#Filter Processor

Filter Processor 根据你在其配置中定义的条件过滤 spans、metrics 或 logs。Filter Processor 的典型用例是丢弃与可观测性系统无关的遥测数据，例如非关键日志或 spans，以减少数据噪声。

过滤可通过允许列表和拒绝列表实现，这些列表会基于正则表达式和 resource attributes 包含或排除遥测数据。你也可以使用 OpenTelemetry Transformation Language (OTTL) 更好地描述你想要过滤的 signals。该 processor 支持所有 pipeline 类型。

YAML 示例

config: |
  processors:
    filter/ottl:
      error_mode: ignore
      traces:
        span:
          - 'attributes["container.name"] == "app_container_1"'
          - 'resource.attributes["host.name"] == "localhost"'

filter/ottl 参数说明

#Metrics Transform Processor

Metrics Transform Processor 与 Attributes Processor 具有部分相同的功能，通常用于执行以下任务：

• 添加、重命名或删除 label key 和 value。
• 基于 labels 或 label values 缩放和聚合 metrics。
• 该 processor 仅支持在单个 metrics 批次内进行重命名和聚合。它不会执行任何跨批次聚合，因此不要将其用于聚合来自多个来源的数据，例如多个节点或客户端。

有关支持操作的完整列表，请参见 可用操作。

YAML 示例

config: |
  processors:
    metricstransform/rename:
      transforms:
        include: system.cpu.usage
        action: update
        new_name: system.cpu.usage_time

Metrics Transform processor 还支持使用正则表达式，从而允许将转换规则同时应用于多个 metric 名称或 metric label。以下示例会将所有 metrics 中的 cluster_name 重命名为 cluster-name：

config: |
  processors:
    metricstransform/clustername:
      transforms:
        - include: ^.*$
          match_type: regexp
          action: update
          operations:
            - action: update_label
              label: cluster_name
              new_label: cluster-name

可用操作

该 processor 可以执行以下操作：

• 重命名 metrics。例如，将 system.cpu.usage 重命名为 system.cpu.usage_time。
• 添加 labels。例如，你可以向所有 points 添加一个值为 1 的新 label identifier。
• 重命名 label keys。例如，将 label state 重命名为 cpu_state。
• 重命名 label values。例如，将 state label 中的值 idle 重命名为 -。
• 删除 data points。例如，删除所有 state label 值为 idle 的 points。
• 切换 data types。你可以将 int data points 更改为 double data points。
• 缩放值。例如，将值乘以 1000，以从秒转换为毫秒。
• 按 label set 聚合。例如，仅保留 state label，并对具有相同 label 值的所有 points 求平均。
• 按 label value 聚合。例如，将 state label 中值为 user 或 system 的 points 求和为 used = user + system。

适用以下规则：

• 你只能使用 strict 或 regexp 过滤器对一个或多个 metrics 应用操作。
• 使用 action 属性，你可以：
  • 原地更新 metrics（update）。
  • 复制并更新复制后的 metrics（insert）。
  • 通过将一组匹配 metrics 中的所有 data points 合并为单个 metric，把 metrics 合并为一个新插入的 metric（combine）。原始匹配 metrics 也会被移除。
• 重命名 metrics 时，regexp 过滤器中的捕获组会被展开。

#Transform Processor

Transform Processor 通过语句修改匹配的 spans、metrics 或 logs。使用场景包括但不限于：将 metrics 转换为不同类型、替换或移除 key，以及基于预定义条件设置字段。

语句是 OpenTelemetry Transformation Language (OTTL) 中的函数，并按照列表中的顺序应用于遥测数据。transform processor 还包含用于转换 metric 类型的附加函数。语句会根据你定义的 OTTL context（例如 Span 或 DataPoint）转换数据。

Transform processor 支持的 contexts：

语句可以转换更高层 context 的遥测数据。例如，应用于 data point 的语句可以访问该 data point 的 metric 和 resource。无法访问更低层 context；例如，你不能使用 span 语句来转换单个 span event。通常，语句会与要转换的 context 关联。

以下示例展示了如何使用 transform processor 设置 span 的状态。当 http.request.status_code 属性为 400 时，下面的示例将 span 状态设置为 Ok：

YAML 示例

config: |
  transform:
    error_mode: ignore
    trace_statements:
      - context: span
        statements:
          - set(status.code, STATUS_CODE_OK) where attributes["http.request.status_code"] == 400

error_mode 字段描述了 processor 在处理语句时遇到错误的响应方式：

• "error_mode: ignore" 表示 processor 忽略错误并继续执行。这是默认错误模式。
• "error_mode: propagate" 表示 processor 返回错误。结果，collector 将丢弃数据。

#高级功能

• 你还可以使用 transform processor 根据 span attributes 修改 span 名称，或从 span 名称中提取 span attributes。有关示例，请参阅 transform processor 的示例 配置文件。
• transform processor 还提供高级属性转换能力。transform processor 允许最终用户使用 OpenTelemetry Transformation Language (OTTL) 为 metrics、logs 和 traces 指定转换。
• 有关 OTTL 函数和语法的更多信息，请参见：
  • OTTL Syntax: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/README.md
  • OTTL Functions: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/pkg/ottl/ottlfuncs
  • OTTL Contexts: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/pkg/ottl/contexts

#Exporters

Exporters 将数据发送到一个或多个后端或目标。Exporters 可以是基于拉取或基于推送的，并且可能支持一个或多个 数据源。

你可以在 Collector 配置文件的 exporters 部分中配置 exporters。大多数 exporter 至少需要一个目标以及诸如认证令牌或 TLS 证书之类的安全设置。你指定的任何设置都会覆盖默认值（如果存在）。

注意：配置 exporter 并不会启用它。必须通过将其添加到 service 部分 中相应的 pipeline 来启用 exporter。默认情况下，不会启用任何 exporter。

Collector 需要一个或多个 exporters。下面是常见的 exporter 配置示例：

提示：某些 exporter 需要 x.509 证书来建立安全连接，如 设置证书 中所述。有关更详细的 exporter 配置，请参阅 exporter README。

#OTLP 导出器

OTLP 导出器通过 gRPC 使用 OTLP 格式导出 metrics、traces 和 logs。支持的 pipeline 类型包括 spans、metrics 和 logs。默认情况下，此 exporter 需要 TLS，并提供队列重试功能。 若要通过 HTTP 发送 OTLP 数据，请使用 OTLP/HTTP exporter。有关说明请参见 OTLP/HTTP exporter。

YAML 示例

config: |
  exporters:
    otlp:
      endpoint: tempo-ingester:4317
      tls:
        ca_file: ca.pem
        cert_file: cert.pem
        key_file: key.pem
        insecure: false
        insecure_skip_verify: false
        reload_interval: 1h
        server_name_override: <name>
      headers:
        X-Scope-OrgID: "dev"
  service:
    pipelines:
      traces:
        exporters: [otlp]
      metrics:
        exporters: [otlp]

otlp 参数说明

#OTLP HTTP 导出器

OTLP HTTP 导出器使用 OpenTelemetry Protocol (OTLP) 导出 traces 和 metrics。

YAML 示例

  config: |
    exporters:
      otlphttp:
        endpoint: http://tempo-ingester:4318
        tls:
        headers:
          X-Scope-OrgID: "dev"
        disable_keep_alives: false

    service:
      pipelines:
        traces:
          exporters: [otlphttp]
        metrics:
          exporters: [otlphttp]

otlphttp 参数说明

#Debug 导出器

Debug 导出器会将遥测数据输出到控制台，以便调试。

YAML 示例

  config: |
    exporters:
      debug:
        verbosity: detailed
    service:
      pipelines:
        traces:
          exporters: [logging]
        metrics:
          exporters: [logging]

debug.verbosity 字段控制日志导出细节级别（detailed|normal|basic）。当设置为 detailed 时，pipeline 数据会被详细记录。

#Load Balancing 导出器

Load Balancing 导出器可以将 spans、metrics 和 logs 导出到多个后端。支持的 pipeline 类型包括 metrics、spans 和 logs。Load Balancing 导出器可以使用路由策略同时将遥测数据发送到多个后端。你可以配置 routing_key，使用路由策略将遥测数据分类到不同组，并将这些组映射到特定 endpoint。

使用 Load Balancing 导出器，你还可以通过 collector endpoint 将数据发送到其他正在运行的 OpenTelemetry Collector 实例。例如，你可以将所有 traces 发送到一个正在运行的 collector 实例，并将所有 logs 发送到另一个实例。这样你就可以在不同的 collector 环境中处理或操作数据。

YAML 示例

  config: |
    exporters:
      loadbalancing:
        routing_key: "service"
        protocol:
          otlp:
            timeout: 1s
        resolver:
          static:
            hostnames:
            - backend-1:4317
            - backend-2:4317
          dns:
            hostname: otelcol-headless.observability.svc.cluster.local
          k8s:
            service: lb-svc.kube-public
            ports:
              - 15317
              - 16317

loadbalancing 参数说明

#Prometheus 导出器

Prometheus 导出器以 Prometheus 或 OpenMetrics 格式导出 metric 数据，使 Prometheus servers 能够抓取这些数据。下面是配置和使用 Prometheus 导出器的详细说明。

必需配置

• endpoint：指定暴露 metric 数据的地址，路径为 /metrics。此项必须配置，没有默认值。

可选配置

• const_labels：应用于每个已导出 metric 的 key-value pair labels，默认未设置。
• namespace：如果设置，所有导出的 metrics 都会使用此命名空间，没有默认值。
• send_timestamps：是否在响应中为 metric samples 发送 timestamps，默认值为 false。
• metric_expiration：定义在多长时间内未更新的 metrics 仍保持暴露，默认值为 5m。
• resource_to_telemetry_conversion：
  • enabled：默认值为 false。启用后，会将 resource attributes 转换为 metric labels。
• enable_open_metrics：默认值为 false。启用后，metrics 将使用 OpenMetrics 格式导出。
• add_metric_suffixes：默认值为 true。是否添加类型和单位后缀。

TLS 配置

可以使用 ca_file、cert_file 和 key_file 设置 TLS 证书，以确保安全通信。

示例 YAML 配置

下面是 Prometheus 导出器的示例配置：

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
    tls:
      ca_file: "/path/to/ca.pem"
      cert_file: "/path/to/cert.pem"
      key_file: "/path/to/key.pem"
    namespace: "prefix"
    const_labels:
      label1: "value1"
    send_timestamps: true
    metric_expiration: "180m"
    enable_open_metrics: true
    add_metric_suffixes: false
    resource_to_telemetry_conversion:
      enabled: true

此配置会在 0.0.0.0:8889/metrics 暴露 Prometheus metrics，并配置 TLS 证书和其他参数。

使用建议

1. 在 OpenTelemetry 中，metric 名称和 label 会被标准化，以符合 Prometheus 命名约定。
2. 默认情况下，resource attributes 会添加到 target_info metric 中。你可以使用 Prometheus 查询将这些 attributes 作为 metric labels 进行选择和分组。
3. 为了简化查询和分组，建议使用 transform processor 将常用的 resource attributes 直接转换为 metric labels。

#Connectors

Connectors 连接两个 pipeline，同时充当 exporter 和 receiver。connector 作为一个 pipeline 末尾的 exporter 消费数据，并作为另一个 pipeline 开头的 receiver 发送数据。消费和发送的数据可以是相同类型，也可以是不同类型。你可以使用 connectors 来聚合、复制或路由数据。

你可以在 Collector 配置文件的 connectors 部分中配置一个或多个 connectors。默认情况下，不会配置任何 connector。每种 connector 都设计用于处理一种或多种数据类型的组合，并且只能用于连接相应的数据类型 pipeline。

注意：配置 connector 并不会启用它。必须通过将其添加到 service 部分 中相关的 pipeline 来启用 connectors。

提示：如需更详细的 connector 配置，请参阅 connector README。

#ASM Service Graph Connector

ASM Service Graph Connector 构建一个表示系统中各个服务之间关系的映射。该 connector 会分析 spans 数据并生成描述服务关系的 metrics。这些 metrics 可供数据可视化应用（例如 Grafana）用于绘制 service graph。

注意： 该组件是社区组件 Service Graph Connector 的自定义版本，不能直接替换为社区原生组件。下面会说明具体的参数差异。

服务拓扑在许多场景中都非常有用：

• 推断分布式系统的拓扑。随着分布式系统不断扩展，它们会变得越来越复杂。service graph 有助于你理解系统结构。
• 提供系统健康状况的高层概览。service graph 会显示错误率、延迟和其他相关数据。
• 提供系统拓扑的历史视图。分布式系统会频繁变化，而 service graph 提供了一种查看这些系统如何随时间演进的方法。

YAML 示例

  config: |
    connectors:
      asmservicegraph:
        dimensions: []
        extra_dimensions:
          mesh_id:
          cluster_name:
        store:
          ttl: 5s
          max_items: 500

asmservicegraph 参数说明

#Extensions

Extensions 为 Collector 添加能力。例如，extensions 可以自动为 receivers 和 exporters 添加认证功能。

Extensions 是用于扩展 Collector 功能的可选组件，适用于与处理遥测数据无关的任务。例如，你可以添加用于健康监控、服务发现或数据转发的 extensions。

你可以在 Collector 配置文件的 extensions 部分中配置 extensions。大多数 extension 都带有默认设置，因此你只需指定 extension 名称即可进行配置。你指定的任何设置都会覆盖默认值（如果存在）。

注意：配置 extension 并不会启用它。必须在 service 部分 中启用 extensions。默认情况下，不会配置任何 extension。

提示：如需更详细的 extension 配置，请参阅 extension README。

#Service 部分

service 部分用于根据 receivers、processors、exporters 和 extensions 部分中的配置启用 Collector 组件。如果某个组件已配置但未在 service 部分中定义，则不会启用它。

service 部分包含三个子部分：

1. Extensions：要启用的必需 extensions 列表。例如：

   service:
     extensions: [health_check, pprof, zpages]

2. Pipelines：配置 pipelines，类型如下：

   • traces：收集并处理 trace 数据。
   • metrics：收集并处理 metric 数据。
   • logs：收集并处理 log 数据。

   一个 pipeline 由一组 receivers、processors 和 exporters 组成。在将 receiver、processor 或 exporter 添加到 pipeline 之前，请确保其配置已在相应部分中定义。

   你可以在多个 pipelines 中使用相同的 receiver、processor 或 exporter。当一个 processor 被多个 pipelines 引用时，每个 pipeline 都会获得该 processor 的单独实例。

   以下是 pipeline 配置示例。请注意，processors 的顺序决定了数据的处理顺序：

   service:
     pipelines:
       metrics:
         receivers: [opencensus, prometheus]
         processors: [batch]
         exporters: [opencensus, prometheus]
       traces:
         receivers: [opencensus, jaeger]
         processors: [batch, memory_limiter]
         exporters: [opencensus, zipkin]

3. Telemetry：telemetry 配置部分用于设置 Collector 本身的可观测性。它由 logs 和 metrics 两个子部分组成。有关如何配置这些 signals 的信息，请参见 在 Collector 中启用内部 telemetry。

#附加信息

#环境变量

Collector 配置支持使用和扩展环境变量。例如，要使用存储在 DB_KEY 和 OPERATION 环境变量中的值，你可以这样写：

processors:
  attributes/example:
    actions:
      - key: ${env:DB_KEY}
        action: ${env:OPERATION}

使用 $$ 表示字面量 $。例如，要表示 $DataVisualization，你可以这样写：

exporters:
  prometheus:
    endpoint: prometheus:8889
    namespace: $$DataVisualization

#代理支持

使用 net/http 包的 exporters 支持以下代理环境变量：

• HTTP_PROXY：HTTP 代理地址。
• HTTPS_PROXY：HTTPS 代理地址。
• NO_PROXY：应绕过代理的地址。

如果 Collector 启动时设置了这些变量，exporters 将根据这些环境变量对流量进行代理或绕过代理，而不受 protocol 的影响。

#认证

大多数暴露 HTTP 或 gRPC 端口的 receivers 都可以使用 Collector 的认证机制进行保护。类似地，大多数使用 HTTP 或 gRPC 客户端的 exporters 可以为出站请求添加认证。

Collector 中的认证机制使用 extension 机制，因此可以将自定义 authenticator 集成到 Collector 分发版中。每个认证 extension 可以通过两种方式使用：

1. 作为 exporters 的客户端 authenticator，为出站请求添加认证数据。
2. 作为 receivers 的服务端 authenticator，对入站连接进行认证。

有关已知 authenticators 的列表，请参见 Registry。

要为 Collector 中的 receiver 添加服务端 authenticator，请执行以下步骤：

1. 在 .extensions 下添加 authenticator extension 及其配置。
2. 在 .services.extensions 下添加对 authenticator 的引用，以便 Collector 加载它。
3. 在 .receivers.<your-receiver>.<http-or-grpc-config>.auth 下添加对 authenticator 的引用。

下面的示例在接收端使用 OIDC authenticator，适用于通过 OpenTelemetry Collector 作为代理接收数据的远程 Collectors：

extensions:
  oidc:
    issuer_url: http://localhost:8080/auth/realms/opentelemetry
    audience: collector

receivers:
  otlp/auth:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        auth:
          authenticator: oidc

processors:

exporters:
  # Note: Use `logging` instead of `debug` before v0.86.0.
  debug:

service:
  extensions:
    - oidc
  pipelines:
    traces:
      receivers:
        - otlp/auth
      processors: []
      exporters:
        - debug

在代理端，此示例配置 OTLP exporter 以获取 OIDC token，并将其添加到发送给远程 Collector 的每个 RPC 中：

extensions:
  oauth2client:
    client_id: agent
    client_secret: some-secret
    token_url: http://localhost:8080/auth/realms/opentelemetry/protocol/openid-connect/token

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:

exporters:
  otlp/auth:
    endpoint: remote-collector:4317
    auth:
      authenticator: oauth2client



service:
  extensions:
    - oauth2client
  pipelines:
    traces:
      receivers:
        - otlp
      processors: []
      exporters:
        - otlp/auth

#配置证书

在生产环境中，为了安全通信，请使用 TLS 证书或 mTLS 进行双向认证。请按照以下步骤生成自签名证书，或者在生产环境中使用你当前的证书提供商提供的生产证书。

安装 cfssl 并创建以下 csr.json 文件：

{
  "hosts": ["localhost", "127.0.0.1"],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "O": "OpenTelemetry Example"
    }
  ]
}

然后运行以下命令：

cfssl genkey -initca csr.json | cfssljson -bare ca
cfssl gencert -ca ca.pem -ca-key ca-key.pem csr.json | cfssljson -bare cert

这将创建两个证书：

1. 一个名为 "OpenTelemetry Example" 的 certificate authority (CA)，存储在 ca.pem 中，其关联的 key 存储在 ca-key.pem 中。
2. 一个存储在 cert.pem 中的 client certificate，由 OpenTelemetry Example CA 签名，其关联的 key 存储在 cert-key.pem 中。

#覆盖设置

你可以使用 --set 选项覆盖 Collector 设置。以这种方式定义的设置会在所有 --config 来源解析并合并后，合并到最终配置中。

以下示例展示了如何覆盖嵌套部分中的设置：

otelcol --set "exporters::debug::verbosity=detailed"
otelcol --set "receivers::otlp::protocols::grpc={endpoint:localhost:4317, compression: gzip}"

重要说明：--set 选项不支持设置包含点号（.）或等号（=）的 key。