#配置 OpenTelemetry Collector

#功能概述

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

• 数据收集概念，用于了解适用于 OpenTelemetry Collector 的仓库。
• 安全指南。

#配置结构

任何 Collector 配置文件的结构都由四类与 telemetry 数据交互的管道组件组成：

• Receivers
• Processors
• Exporters
• Connectors

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

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

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

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

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 从一个或多个来源收集 telemetry 数据。它们可以是 pull-based 或 push-based，并且可能支持一个或多个 数据源。

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

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

注意： 配置 receiver 不会启用它。必须通过将其添加到 service 部分中的相应管道来启用 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 定义的规则或设置，这些规则或设置可能包括过滤、删除、重命名或重新计算 telemetry 数据。管道中 processors 的顺序决定了 Collector 对 signals 执行处理操作的顺序。

Processors 是可选的，但其中一些 建议使用。

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

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

下面是常见 processor 配置示例。

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

#Batch Processor

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

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 的内存使用情况，并在达到软内存限制时暂停数据处理，从而防止内存不足场景。此 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 的一个典型用例是丢弃与可观测性系统无关的 telemetry 数据，例如非关键日志或 spans，以减少数据噪声。

过滤支持 allow 和 deny 列表，可根据正则表达式和资源属性来包含或排除 telemetry。你也可以使用 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 共享部分功能，通常用于执行以下任务：

• 添加、重命名或删除标签键和值。
• 根据标签或标签值对 metrics 进行缩放和聚合。
• 该 processor 仅支持在单个 metric 批次内进行重命名和聚合，不执行跨批次聚合，因此不要将其用于聚合来自多个来源的 metrics，例如多个节点或客户端。

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

YAML 示例

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

Metrics Transform processor 还支持使用正则表达式，从而可以同时将转换规则应用于多个 metric 名称或 metric 标签。以下示例会将所有 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。
• 添加标签。例如，你可以为所有点添加一个值为 1 的新标签 identifier。
• 重命名标签键。例如，将标签 state 重命名为 cpu_state。
• 重命名标签值。例如，将 state 标签中的值 idle 重命名为 -。
• 删除 data points。例如，删除所有 state 标签值为 idle 的点。
• 切换数据类型。你可以将 int data points 更改为 double data points。
• 缩放值。例如，将值乘以 1000，以便从秒转换为毫秒。
• 按标签集合聚合。例如，仅保留 state 标签，并对该标签具有相同值的所有点求平均。
• 按标签值聚合。例如，将 state 标签中值为 user 或 system 的点求和为 used = user + system。

适用以下规则：

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

#Transform Processor

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

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

Transform processor 支持的上下文：

语句可以转换更高级上下文中的 telemetry 数据。例如，应用于 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，并且可能支持一个或多个 数据源。

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

注意：配置 exporter 不会启用它。必须通过将其添加到 service 部分中的相应管道来启用 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 会将 telemetry 数据输出到控制台，用于调试。

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 可以使用路由策略将 telemetry 数据同时发送到多个后端。你可以配置 routing_key，通过路由策略将 telemetry 数据分类到不同组，并将这些组映射到特定端点。

使用 Load Balancing Exporter，你还可以通过 collector 端点将数据发送到其他正在运行的 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 server 抓取这些数据。以下是 Prometheus Exporter 的配置和使用详情。

必需配置

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

可选配置

• const_labels：应用于每个已导出 metric 的键值对标签，默认未设置。
• namespace：如果设置，所有导出的 metrics 都将使用该命名空间，没有默认值。
• send_timestamps：是否在响应中发送 metric 样本的时间戳，默认值为 false。
• metric_expiration：定义 metrics 在多长时间内未更新后仍继续暴露，默认值为 5m。
• resource_to_telemetry_conversion：
  • enabled：默认值为 false。启用后，resource 属性会转换为 metric 标签。
• 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 名称和标签会进行标准化，以符合 Prometheus 命名约定。
2. 默认情况下，resource 属性会添加到 target_info metric 中。你可以使用 Prometheus 查询将这些属性作为 metric 标签进行选择和分组。
3. 为了简化查询和分组，建议使用 transform processor 将常用的 resource 属性直接转换为 metric 标签。

#Connectors

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

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

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

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

#ASM Service Graph Connector

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

注意： 此组件是社区组件 Service Graph Connector 的自定义版本，不能直接替换为社区原生组件。具体的参数差异如下所述。

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 的功能，适用于与 telemetry 数据处理无关的任务。例如，你可以添加用于健康检查、服务发现或数据转发的 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 之前，请确保其配置已在相应部分中定义。

   你可以在多个 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 中启用内部 telemetry。

#其他信息

#环境变量

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

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

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

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

#Proxy 支持

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

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

如果 Collector 启动时设置了这些变量，则无论协议如何，exporters 都会根据这些环境变量代理或绕过代理流量。

#认证

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

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

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

有关已知 authenticator 列表，请参阅 Registry。

要为 Collector 中的 receiver 添加服务端 authenticator，请按以下步骤操作：

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

以下示例在接收端使用 OIDC authenticator，适用于通过 OpenTelemetry Collector 作为 proxy 接收数据的远程 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

在 proxy 端，此示例配置 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 证书或 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 中，由 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 选项不支持设置包含点号（.）或等号（=）的键。