#配置 OpenTelemetry Collector

#功能概述

您可以配置 OpenTelemetry Collector 以满足您的可观察性需求。在深入了解 Collector 配置的工作原理之前，熟悉以下内容是很重要的：

• 数据收集概念，以了解适用于 OpenTelemetry Collector 的存储库。
• 安全指导原则。

#配置结构

任何 Collector 配置文件的结构由四种类型的管道组件组成，它们与遥测数据进行交互：

• 接收器
• 处理器
• 导出器
• 连接器

在配置每个管道组件后，您必须通过在配置文件的 服务部分 中定义的管道来启用它。

除了管道组件之外，您还可以配置 扩展，提供可以添加到 Collector 的附加功能，例如诊断工具。扩展不需要直接访问遥测数据，并且通过 服务部分 启用。

下面是一个包含接收器、处理器、导出器和三个扩展的 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 部分进行配置。默认情况下，没有配置接收器。您必须配置一个或多个接收器。许多接收器带有默认设置，所以指定接收器名称可能是足够的。如果您需要自定义或修改默认配置，可以在此部分进行。您指定的任何设置将覆盖默认设置（如果存在）。

注意： 配置接收器并不会启用它。通过将其添加到 服务部分 中的适当管道来启用接收器。

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

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

#OTLP 接收器

OTLP 接收器使用 OpenTelemetry 协议 (OTLP) 获取跟踪、度量和日志。

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 格式获取跟踪。

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 格式获取跟踪。

YAML 示例

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

    service:
      pipelines:
        traces:
          receivers: [zipkin]

zipkin 参数描述

#处理器

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

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

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

注意： 配置处理器并不会启用它。必须通过将其添加到 服务部分 中的适当管道来启用处理器。默认情况下，没有启用处理器。

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

提示： 您可以通过将 opentelemetry-collector-contrib 和 opentelemetry-collector 中的列表组合在一起，找到完整的处理器列表。有关更详细的处理器配置，请参阅 处理器 README。

#批处理处理器

批处理处理器根据大小或时间对跨度、度量或日志进行批处理和压缩。批处理可以帮助减少导出器发送的提交请求数量，并帮助调节来自多个或单个接收器在管道中流动的遥测。

YAML 示例

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

batch 参数描述

#内存限制处理器

内存限制处理器定期检查 Collector 的内存使用情况，并在达到软内存限制时暂停数据处理，以防止内存不足的情况发生。此处理器支持跨度、度量和日志。它通常是接收器之后的第一个组件，期望重试以发送相同数据，并可能对传入数据施加背压。当内存使用超过硬限制时，内存限制处理器会强制进行垃圾回收。

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 参数描述

#过滤器处理器

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

过滤操作使用允许和拒绝列表，根据正则表达式和资源属性包含或排除遥测数据。您还可以使用 OpenTelemetry 转换语言 (OTTL) 更清晰地描述要过滤的信号。该处理器支持所有类型的管道。

YAML 示例

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

filter/ottl 参数描述

#度量转换处理器

度量转换处理器与属性处理器共享某些功能，通常用于执行以下任务：

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

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

YAML 示例

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

度量转换处理器还支持使用正则表达式，允许变换规则同时应用于多个度量名称或度量标签。以下示例将 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 过滤器中的捕获组将被展开。

#转换处理器

转换处理器通过语句修改匹配的跨度、度量或日志。用例包括但不限于将度量转换为不同类型、替换或删除键，以及根据预定义条件设置字段。

语句是 OpenTelemetry 转换语言 (OTTL) 中的函数，根据它们在列表中的顺序应用于遥测数据。转换处理器包括额外的函数，用于转换度量类型。语句根据您定义的 OTTL 上下文转换数据，例如跨度或数据点。

支持的转换处理器上下文：

语句可以转换较高级上下文的遥测数据。例如，应用于数据点的语句可以访问该数据点的度量和资源。不能访问较低上下文；例如，您不能使用跨度语句来转换单个跨度事件。通常，语句与您要转换的上下文相关联。

以下示例使用转换处理器设置跨度的状态。当 http.request.status_code 属性为 400 时，以下示例将跨度状态设置为 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 将丢弃数据。

#高级功能

• 您还可以使用转换处理器根据跨度属性修改跨度名称或从跨度名称提取跨度属性。有关示例，请参见转换处理器的示例 配置文件。
• 转换处理器 还提供高级属性转换功能。转换处理器允许最终用户使用 OpenTelemetry 转换语言 (OTTL) 为度量、日志和跟踪指定转换。
• 有关 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

#导出器

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

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

注意：配置导出器并不会启用它。需要通过将其添加到 服务部分 中的适当管道来启用导出器。默认情况下，没有启用导出器。

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

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

#OTLP 导出器

OTLP 导出器使用 OTLP 格式通过 gRPC 发送度量、跟踪和日志。支持的管道类型包括跨度、度量和日志。默认情况下，此导出器需要 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 导出器使用打开遥测协议 (OTLP) 导出跟踪和度量。

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 参数描述

#调试导出器

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

YAML 示例

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

debug.verbosity 字段控制日志导出详细级别（detailed|normal|basic）。设置为 detailed 时，管道数据将详细记录。

#负载均衡导出器

负载均衡导出器可以将跨度、度量和日志导出到多个后端。支持的管道类型包括度量、跨度和日志。负载均衡导出器可以使用路由策略将遥测数据同时发送到多个后端。您可以配置 routing_key 来使用路由策略将遥测数据分类到组，并将这些组映射到特定端点。

使用负载均衡导出器，您也可以通过收集器端点将数据发送到其他正在运行的 OpenTelemetry Collector 实例。例如，您可以将所有跟踪发送到一个正在运行的收集器实例，所有日志发送到另一个实例。这允许您在不同的 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 将常用的资源属性直接转换为度量标签。

#连接器

连接器连接两个管道，同时作为导出器和接收器。连接器在一个管道的末尾以导出器的身份消耗数据，然后在另一个管道的开头以接收器的身份发送数据。消耗和发送的数据可以是相同或不同类型的。您可以使用连接器来聚合、复制或路由数据。

您可以在 Collector 配置文件的 connectors 部分配置一个或多个连接器。默认情况下，没有配置连接器。每种类型的连接器旨在处理一种或多种数据类型的组合，并且只能用于连接相应数据类型的管道。

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

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

#ASM 服务图连接器

ASM 服务图连接器构建一个表示系统中各种服务之间关系的图。该连接器分析跨度数据并生成描述服务之间关系的度量。这些度量可以被数据可视化应用程序（如 Grafana）用来绘制服务图。

注意： 该组件是社区组件服务图连接器的自定义版本，不能直接替换为社区原生组件。下面将解释特定参数的差异。

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

• 推断分布式系统的拓扑。随着分布式系统的增长，它们变得越来越复杂。服务图帮助您理解系统的结构。
• 提供系统健康的高层次概览。服务图显示错误率、延迟和其他相关数据。
• 提供系统拓扑的历史视图。分布式系统经常变化，服务图提供了一种查看这些系统随时间演变的方式。

YAML 示例

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

asmservicegraph 参数描述

#扩展

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

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

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

注意：配置扩展并不会启用它。扩展必须在 服务部分 中启用。默认情况下，无扩展被配置。

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

#服务部分

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

service 部分包括三个子部分：

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

   service:
     extensions: [health_check, pprof, zpages]
   

2. 管道：配置管道，管道可以是以下类型：

   • traces：收集和处理跟踪数据。
   • 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 配置部分用于设置 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. 存储在 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 选项不支持设置包含点（.）或等号（=）的键。