#配置 OpenTelemetry Collector

#功能概述

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

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

#配置结构

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

• Receivers
• Processors
• Exporters
• Connectors

在配置好每个流水线组件后，你必须通过配置文件中 service section 定义的流水线来启用它。

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

下面是一个包含 receivers、processors、exporters 和三个 extension 的 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 从一个或多个来源收集遥测数据。它们可以是 pull-based 或 push-based，并且可能支持一个或多个 data sources。

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

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

说明： 配置 receiver 并不会启用它。必须通过将其添加到 service section 中的相应流水线来启用 receiver。

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

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

#OTLP Receiver

OTLP receiver 使用 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 Receiver

Jaeger receiver 以 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 Receiver

Zipkin receiver 同时接收 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 定义的规则或设置，这些规则或设置可能包括过滤、删除、重命名或重新计算遥测数据。流水线中 processors 的顺序决定了 Collector 对 signals 应用处理操作的顺序。

Processors 是可选的，但某些 processors 是 recommended。

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

说明： 配置 processor 并不会启用它。必须通过将其添加到 service section 中的相应流水线来启用 processor。默认情况下不会启用任何 processor。

下面是常见 processor 配置示例。

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

#Batch Processor

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

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 的典型用例是丢弃与可观测性系统无关的遥测数据，例如非关键日志或 span，以减少数据噪声。

过滤通过允许列表和拒绝列表实现，它们可基于正则表达式和资源属性对遥测数据进行包含或排除。你也可以使用 OpenTelemetry Transformation Language (OTTL) 更好地描述要过滤的 signals。该 processor 支持所有流水线类型。

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 键和值。
• 根据 label 或 label 值对 metrics 进行缩放和聚合。
• 该 processor 仅支持在单个 metric 批次内进行重命名和聚合。它不执行跨批次聚合，因此不要将其用于聚合来自多个源（例如多个节点或客户端）的 metrics。

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

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。
• 添加 label。例如，你可以为所有点添加一个值为 1 的新 label identifier。
• 重命名 label 键。例如，将 label state 重命名为 cpu_state。
• 重命名 label 值。例如，在 state label 中将值 idle 重命名为 -。
• 删除 data point。例如，移除所有 state label 值为 idle 的点。
• 切换数据类型。你可以将 int data point 更改为 double data point。
• 缩放数值。例如，将数值乘以 1000，以从秒转换为毫秒。
• 按 label 集合聚合。例如，仅保留 state label，并对该 label 具有相同值的所有点求平均。
• 按 label 值聚合。例如，将 state label 中值为 user 或 system 的点求和为 used = user + system。

适用以下规则：

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

#Transform Processor

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

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

transform processor 支持的上下文：

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

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

#Exporters

Exporters 将数据发送到一个或多个后端或目的地。Exporters 可以是 pull-based 或 push-based，并且可能支持一个或多个 data sources。

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

说明：配置 exporter 并不会启用它。必须通过将其添加到 service section 中的相应流水线来启用 exporter。默认情况下不会启用任何 exporter。

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

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

#OTLP Exporter

OTLP exporter 通过 gRPC 使用 OTLP 格式发送 metrics、traces 和 logs。支持的流水线类型包括 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 Exporter

OTLP HTTP Exporter 使用 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 Exporter

Debug Exporter 会将遥测数据输出到控制台，便于调试。

YAML 示例

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

debug.verbosity 字段控制记录的导出详细级别（detailed|normal|basic）。当设置为 detailed 时，会详细记录流水线数据。

#Load Balancing Exporter

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

使用 Load Balancing Exporter，你还可以通过 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 Exporter

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

必需配置

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

可选配置

• const_labels：应用于每个导出的 metric 的键值对 label，默认未设置。
• namespace：如果设置，所有导出的 metrics 都将使用此 namespace，没有默认值。
• send_timestamps：是否在响应中为 metric sample 发送时间戳，默认值为 false。
• metric_expiration：定义 metrics 在没有更新时的暴露时长，默认值为 5m。
• resource_to_telemetry_conversion：
  • enabled：默认值为 false。启用后，资源属性会转换为 metric label。
• enable_open_metrics：默认值为 false。启用后，metrics 将使用 OpenMetrics 格式导出。
• add_metric_suffixes：默认值为 true。是否添加类型和单位后缀。

TLS 配置

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

示例 YAML 配置

以下是 Prometheus Exporter 的示例配置：

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. 默认情况下，资源属性会添加到 target_info metric 中。你可以使用 Prometheus 查询将这些属性作为 metric label 进行选择和分组。
3. 为了简化查询和分组，建议使用 transform processor 直接将常用资源属性转换为 metric label。

#Connectors

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

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

说明：配置 connector 并不会启用它。必须通过将其添加到 service section 中的相关流水线来启用 connector。

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

#ASM Service Graph Connector

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

说明： 此组件是 Community 组件 Service Graph Connector 的自定义版本，不能直接用 Community 原生组件替换。具体参数差异如下所述。

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

• 推断分布式系统的拓扑结构。随着分布式系统不断扩展，其复杂度也会不断提高。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 的功能，且不用于处理遥测数据。例如，你可以添加用于健康监控、服务发现或数据转发的 extension。

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

说明：配置 extension 并不会启用它。必须在 service section 中启用 extension。默认情况下不会配置任何 extension。

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

#Service Section

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

service 部分包含三个子部分：

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

   service:
     extensions: [health_check, pprof, zpages]

2. Pipelines：配置 pipelines，类型包括以下几种：

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

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

   你可以在多个 pipeline 中使用同一个 receiver、processor 或 exporter。当某个 processor 被多个 pipeline 引用时，每个 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 中启用内部遥测。

#附加信息

#环境变量

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 会根据这些环境变量对流量进行代理或绕过代理，而不受协议影响。

#身份验证

大多数暴露 HTTP 或 gRPC 端口的 receivers 都可以使用 Collector 的身份验证机制进行保护。同样，大多数使用 HTTP 或 gRPC 客户端的 exporters 也可以为出站请求添加身份验证。

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

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

有关已知 authenticator 列表，请参阅 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 作为代理接收数据的远程 Collector：

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 tokens 并将其添加到发送给远程 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 certificates 或 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 中，相关密钥存储在 ca-key.pem 中。
2. 一个存储在 cert.pem 中的 client certificate，由 OpenTelemetry Example CA 签名，相关密钥存储在 cert-key.pem 中。

#覆盖设置

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

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

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

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