#配置 OpenTelemetry Collector

#功能概述

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

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

#配置结构

任何 Collector 配置文件的结构由四种与遥测数据交互的管道组件组成：

• 接收器（Receivers）
• 处理器（Processors）
• 导出器（Exporters）
• 连接器（Connectors）

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

除了管道组件外，您还可以配置 扩展（Extensions），它们为 Collector 提供额外功能，例如诊断工具。扩展不需要直接访问遥测数据，通过 service 部分 启用。

下面是一个包含接收器、处理器、导出器和三个扩展的 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]

请注意，接收器、处理器、导出器和管道均使用 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 部分配置。默认情况下未配置任何接收器，您必须配置一个或多个接收器。许多接收器带有默认设置，因此只需指定接收器名称即可。如果需要自定义或修改默认配置，可以在此部分进行。您指定的任何设置将覆盖默认值（如果存在）。

注意： 配置接收器并不会启用它。接收器通过将其添加到相应管道的 service 部分 来启用。

以下是常见接收器配置示例。

提示： 有关更详细的接收器配置，请参阅接收器 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）

处理器在将接收器收集的数据发送给导出器之前，对数据进行修改或转换。数据处理基于为每个处理器定义的规则或设置，可能包括过滤、删除、重命名或重新计算遥测数据。管道中处理器的顺序决定了 Collector 应用处理操作的信号顺序。

处理器是可选的，但有些处理器是推荐的。

您可以在 Collector 配置文件的 processors 部分配置处理器。您指定的任何设置将覆盖默认值（如果存在）。

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

以下是常见处理器配置示例。

提示： 您可以通过结合 opentelemetry-collector-contrib 和 opentelemetry-collector 的处理器列表，获取完整的处理器列表。有关更详细的处理器配置，请参阅处理器 README。

#Batch 处理器

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

YAML 示例

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

batch 参数说明

#Memory Limiter 处理器

Memory Limiter 处理器定期检查 Collector 的内存使用情况，当达到软内存限制时暂停数据处理，防止出现内存溢出。该处理器支持 spans、metrics 和 logs。它通常是接收器之后的第一个组件，期望重试发送相同数据，并可能对传入数据施加背压。当内存使用超过硬限制时，Memory Limiter 处理器会强制执行垃圾回收。

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 处理器

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

过滤使用允许和拒绝列表，基于正则表达式和资源属性包含或排除遥测。您还可以使用 OpenTelemetry Transformation Language (OTTL) 更好地描述要过滤的信号。该处理器支持所有管道类型。

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 处理器

Metrics Transform 处理器与 Attributes 处理器共享部分功能，通常用于执行以下任务：

• 添加、重命名或删除标签键和值。
• 基于标签或标签值对指标进行缩放和聚合。
• 该处理器仅支持在单个指标批次内进行重命名和聚合，不支持跨批次聚合，因此不要用于聚合来自多个源（如多个节点或客户端）的指标。

完整支持的操作列表见可用操作。

YAML 示例

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

Metrics Transform 处理器还支持使用正则表达式，允许将转换规则同时应用于多个指标名称或指标标签。以下示例将所有指标中的 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

可用操作

该处理器可以执行以下操作：

• 重命名指标。例如，将 system.cpu.usage 重命名为 system.cpu.usage_time。
• 添加标签。例如，向所有点添加新标签 identifier，值为 1。
• 重命名标签键。例如，将标签 state 重命名为 cpu_state。
• 重命名标签值。例如，将 state 标签中的值 idle 重命名为 -。
• 删除数据点。例如，删除所有 state 标签值为 idle 的点。
• 切换数据类型。可以将 int 类型数据点转换为 double 类型数据点。
• 缩放数值。例如，将数值乘以 1000，将秒转换为毫秒。
• 跨标签集合聚合。例如，仅保留 state 标签，并对所有具有相同标签值的点求平均。
• 跨标签值聚合。例如，将 state 标签中值为 user 或 system 的点求和，作为 used = user + system。

以下规则适用：

• 只能对一个或多个指标应用 strict 或 regexp 过滤器的操作。
• 使用 action 属性，您可以：
  • 就地更新指标（update）。
  • 复制并更新复制的指标（insert）。
  • 通过合并匹配指标集合的所有数据点到新插入的指标，实现指标合并（combine）。原匹配指标也会被移除。
• 重命名指标时，regexp 过滤器中的捕获组会被展开。

#Transform 处理器

Transform 处理器通过语句修改匹配的 spans、metrics 或 logs。用例包括但不限于将指标转换为不同类型、替换或删除键、基于预定义条件设置字段。

语句是 OpenTelemetry Transformation Language (OTTL) 中的函数，按照列表中的顺序应用于遥测数据。Transform 处理器包含额外的函数用于转换指标类型。语句根据您定义的 OTTL 上下文（如 Span 或 DataPoint）转换数据。

Transform 处理器支持的上下文：

语句可以转换更高层级上下文的遥测数据。例如，应用于数据点的语句可以访问该数据点的指标和资源。不能访问更低层级上下文；例如，不能使用 span 语句转换单个 span 事件。通常，语句与您想转换的上下文相关联。

以下示例使用 transform 处理器设置 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 字段描述处理器在处理语句时如何响应错误：

• "error_mode: ignore" 表示忽略错误并继续执行。默认错误模式。
• "error_mode: propagate" 表示返回错误，导致 Collector 丢弃数据。

#高级功能

• 您还可以使用 transform 处理器基于 span 属性修改 span 名称，或从 span 名称提取 span 属性。示例见 transform 处理器的示例配置文件。
• transform 处理器 还提供高级属性转换功能。允许终端用户使用 OpenTelemetry Transformation Language (OTTL) 为指标、日志和 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）

导出器将数据发送到一个或多个后端或目标。导出器可以是拉取式或推送式，可能支持一个或多个数据源。

您可以在 Collector 配置文件的 exporters 部分配置导出器。大多数导出器至少需要目标和安全设置，如认证令牌或 TLS 证书。您指定的任何设置将覆盖默认值（如果存在）。

注意： 配置导出器并不会启用它。导出器需要通过将其添加到相应管道的 service 部分 来启用。默认情况下未启用任何导出器。

Collector 需要一个或多个导出器。以下是常见导出器配置示例：

提示： 某些导出器需要 x.509 证书以建立安全连接，详见配置证书。有关更详细的导出器配置，请参阅导出器 README。

#OTLP 导出器

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

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 时，管道数据将详细记录。

#Load Balancing 导出器

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

使用 Load Balancing 导出器，您还可以通过 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 导出器

Prometheus 导出器以 Prometheus 或 OpenMetrics 格式导出指标数据，允许 Prometheus 服务器抓取数据。以下是配置和使用 Prometheus 导出器的详细信息。

必需配置

• endpoint：指定用于暴露指标数据的地址，路径为 /metrics。必须配置，无默认值。

可选配置

• const_labels：应用于每个导出指标的键值对标签，默认未设置。
• namespace：若设置，所有导出指标将使用该命名空间，无默认值。
• send_timestamps：是否在响应中发送指标样本的时间戳，默认值为 false。
• metric_expiration：定义指标在无更新情况下暴露的时长，默认值为 5m。
• resource_to_telemetry_conversion：
  • enabled：默认值为 false。启用时，将资源属性转换为指标标签。
• enable_open_metrics：默认值为 false。启用时，使用 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 指标，并配置了 TLS 证书及其他参数。

使用建议

1. 在 OpenTelemetry 中，指标名称和标签已标准化以符合 Prometheus 命名规范。
2. 默认情况下，资源属性被添加到 target_info 指标。您可以使用 Prometheus 查询选择并将这些属性作为指标标签进行分组。
3. 为简化查询和分组，建议使用 transform processor 直接将常用资源属性转换为指标标签。

#连接器（Connectors）

连接器连接两个管道，既作为导出器又作为接收器。连接器作为一个管道末端的导出器消费数据，并作为另一个管道起始的接收器发送数据。消费和发送的数据可以是相同或不同类型。您可以使用连接器进行数据聚合、复制或路由。

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

注意： 配置连接器并不会启用它。连接器需要通过将其添加到相关管道的 service 部分 来启用。

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

#ASM Service Graph 连接器

ASM Service Graph 连接器构建表示系统中各服务关系的拓扑图。该连接器分析 spans 数据，生成描述服务间关系的指标。这些指标可被数据可视化应用（如 Grafana）用于绘制服务图。

注意： 该组件是社区组件 Service Graph 连接器的定制版本，不能直接替换为社区原生组件。具体参数差异如下说明。

服务拓扑在许多用例中非常有用：

• 推断分布式系统的拓扑。随着分布式系统规模增长，系统变得越来越复杂，服务图帮助理解系统结构。
• 提供系统健康的高层次概览。服务图显示错误率、延迟等相关数据。
• 提供系统拓扑的历史视图。分布式系统频繁变化，服务图提供查看系统演变的方式。

YAML 示例

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

asmservicegraph 参数说明

#扩展（Extensions）

扩展为 Collector 添加功能。例如，扩展可以自动为接收器和导出器添加认证功能。

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

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

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

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

#Service 部分

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

service 部分包含三个子部分：

1. Extensions：启用所需扩展的列表。例如：

   service:
     extensions: [health_check, pprof, zpages]

2. Pipelines：配置管道，类型包括：

   • traces：收集和处理 trace 数据。
   • metrics：收集和处理指标数据。
   • logs：收集和处理日志数据。

   管道由一组 receivers、processors 和 exporters 组成。在将 receiver、processor 或 exporter 包含到管道之前，确保其配置已在相应部分定义。

   您可以在多个管道中使用相同的 receiver、processor 或 exporter。当处理器被多个管道引用时，每个管道获得该处理器的独立实例。

   以下是管道配置示例。请注意，处理器的顺序决定数据的处理顺序：

   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 子部分。有关如何配置这些信号，请参阅在 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 包的导出器支持以下代理环境变量：

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

如果在 Collector 启动时设置了这些变量，导出器将根据这些环境变量代理或绕过代理流量，无论协议如何。

#认证

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

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

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

已知认证器列表见注册表。

在 Collector 中为 receiver 添加服务器认证器，步骤如下：

1. 在 .extensions 下添加认证扩展及其配置。
2. 在 .services.extensions 下添加认证器引用，使 Collector 加载它。
3. 在 .receivers.<your-receiver>.<http-or-grpc-config>.auth 下添加认证器引用。

以下示例在接收端使用 OIDC 认证器，适用于通过 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:
  # 注意：v0.86.0 之前使用 `logging` 替代 `debug`。
  debug:

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

在代理端，此示例配置 OTLP 导出器获取 OIDC 令牌，并将其添加到发送给远程 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" 的证书颁发机构（CA），存储在 ca.pem，对应密钥存储在 ca-key.pem。
2. 一个由 OpenTelemetry Example CA 签发的客户端证书，存储在 cert.pem，对应密钥存储在 cert-key.pem。

#覆盖设置

您可以使用 --set 选项覆盖 Collector 设置。通过此方式定义的设置将在所有 --config 源解析和合并后合并到最终配置中。

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

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

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