简体中文

配置 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 参数说明

参数	说明
`grpc.endpoint`	OTLP gRPC 端点。若省略，默认为 0.0.0.0:4317 。
`grpc.tls`	服务器端 TLS 配置。定义 TLS 证书路径。若省略，则禁用 TLS。
`grpc.tls.client_ca_file`	服务器用于验证客户端证书的 TLS 证书路径。在 TLSConfig 中设置 `ClientCAs` 和 `ClientAuth` 为 `RequireAndVerifyClientCert`。详情见 Golang TLS 包配置。
`grpc.tls.reload_interval`	指定证书重新加载的间隔。若未设置，证书永不重新加载。`reload_interval` 字段接受带有有效时间单位（如 ns、us（或 µs）、ms、s、m、h）的字符串。
`http.endpoint`	OTLP HTTP 端点。默认为 0.0.0.0:4318 。
`http.tls`	服务器端 TLS 配置。配置方式与 `grpc.tls` 类似。

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 参数说明

参数	说明
`grpc.endpoint`	Jaeger gRPC 端点。若省略，默认为 0.0.0.0:14250 。
`thrift_http.endpoint`	Jaeger Thrift HTTP 端点。若省略，默认为 0.0.0.0:14268 。
`thrift_compact.endpoint`	Jaeger Thrift Compact 端点。若省略，默认为 0.0.0.0:6831 。
`thrift_binary.endpoint`	Jaeger Thrift Binary 端点。若省略，默认为 0.0.0.0:6832 。
`tls`	服务器端 TLS 配置。详情请参阅 OTLP 接收器的 `protocols.grpc.tls` 配置。

Zipkin 接收器

Zipkin 接收器支持 Zipkin v1 和 v2 格式的 traces。

YAML 示例

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

    service:
      pipelines:
        traces:
          receivers: [zipkin]

zipkin 参数说明

参数	说明
`endpoint`	Zipkin HTTP 端点。若省略，默认为 0.0.0.0:9411 。
`tls`	服务器端 TLS 配置。详情请参阅 OTLP 接收器的 `protocols.grpc.tls` 配置。

处理器（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 参数说明

参数	说明
`timeout`	在特定时间段后发送批次，无论批次大小如何。
`send_batch_size`	在达到指定的 spans 或 metrics 数量后发送批次。
`send_batch_max_size`	批次允许的最大大小。必须大于或等于 `send_batch_size`。
`metadata_keys`	启用时，为客户端 Metadata 中每组唯一值创建一个批次实例。
`metadata_cardinality_limit`	当 `metadata_keys` 被填充时，限制处理期间不同元数据键值对组合的数量。

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 参数说明

参数	说明
`check_interval`	内存使用测量的时间间隔。最佳值为 1 秒。对于高度波动的流量模式，可以减少 `check_interval` 或增加 `spike_limit_mib`。
`limit_mib`	硬限制，即堆上分配的最大内存量（以 MiB 为单位）。通常，OpenTelemetry Collector 的总内存使用量比此值高约 50 MiB。
`spike_limit_mib`	峰值限制，即内存使用峰值的预期最大值（以 MiB 为单位）。最佳值约为 `limit_mib` 的 20%。软限制通过从 `limit_mib` 中减去 `spike_limit_mib` 计算得出。
`limit_percentage`	与 `limit_mib` 相同，但以总可用内存的百分比表示。`limit_mib` 设置优先。
`spike_limit_percentage`	与 `spike_limit_mib` 相同，但以总可用内存的百分比表示。通常与 `limit_percentage` 一起使用。

Filter 处理器

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

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

信号	条件和匹配类型
Spans	OTTL 条件、span 名称（严格或正则）和资源属性（严格或正则）。span 事件过滤仅支持 OTTL 条件。
Metrics	OTTL 条件、metric 名称（严格或正则）和 metric 属性（表达式）。数据点过滤仅支持 OTTL 条件。
Logs	OTTL 条件、资源属性（严格或正则）。

YAML 示例

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

filter/ottl 参数说明

参数	说明
`error_mode`	定义错误模式。设置为 ignore 时，忽略条件返回的错误。设置为 propagate 时，将错误返回到管道上层，导致 Collector 丢弃负载。
`span[0]`	过滤属性为 `container.name == app_container_1` 的 spans。
`span[1]`	过滤资源属性为 `host.name == localhost` 的 spans。

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 处理器支持的上下文：

信号	支持的上下文
Traces	resource → scope → span → spanevent
Metrics	resource → scope → metric → datapoint
Logs	resource → scope → logs

语句可以转换更高层级上下文的遥测数据。例如，应用于数据点的语句可以访问该数据点的指标和资源。不能访问更低层级上下文；例如，不能使用 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 函数和语法的更多信息，请参阅：

导出器（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 参数说明

参数	说明
`endpoint`	OTLP gRPC 端点。若使用 `https://` 协议，将启用客户端传输安全，覆盖 `tls` 中的不安全设置。
`tls`	客户端 TLS 配置。定义 TLS 证书路径。
`tls.insecure`	设置为 `true` 时，禁用客户端传输安全。默认值为 `false`。
`tls.insecure_skip_verify`	设置为 `true` 时，跳过证书验证。默认值为 `false`。
`tls.reload_interval`	指定证书重新加载的间隔。若未设置，证书永不重新加载。接受带有效时间单位（如 ns、us（或 µs）、ms、s、m、h）的字符串。
`tls.server_name_override`	覆盖权威虚拟主机名，如请求中的 `authority` 头字段。可用于测试。
`headers`	在建立连接的每个请求中发送的头信息。

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 参数说明

参数	说明
`endpoint`	OTLP HTTP 端点。若使用 `https://` 协议，将启用客户端传输安全，覆盖 `tls` 中的任何不安全设置。
`tls`	客户端 TLS 配置。定义 TLS 证书路径。
`headers`	每个 HTTP 请求中发送的头信息。
`disable_keep_alives`	设置为 `true` 时，禁用 HTTP keep-alives。每个连接只发送单个 HTTP 请求。

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 参数说明

参数	说明
`routing_key`	`"routing_key: service"` 将相同服务名的 spans 导出到同一 Collector 实例以实现准确聚合。`"routing_key: traceID"` 基于 TraceID 导出 spans。隐式默认基于 TraceID 路由。
`protocol.otlp`	OTLP 是唯一支持的负载均衡协议。支持 OTLP 导出器的所有选项。
`resolver`	只能配置一个解析器。
`resolver.static`	静态解析器在列出的端点间分配负载。
`resolver.dns`	DNS 解析器仅适用于 Kubernetes Headless 服务。
`resolver.k8s`	推荐使用 Kubernetes 解析器。

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 证书及其他参数。

使用建议

在 OpenTelemetry 中，指标名称和标签已标准化以符合 Prometheus 命名规范。
默认情况下，资源属性被添加到 target_info 指标。您可以使用 Prometheus 查询选择并将这些属性作为指标标签进行分组。
为简化查询和分组，建议使用 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 参数说明

参数	说明
`dimensions`	从资源和 span 属性中提取的指标附加的额外维度（标签）。
`extra_dimensions`	ASM 平台添加的属性。
`extra_dimensions.mesh_id`	Mesh ID。ASM 平台部署了 Istio 服务网格，mesh_id 反映 Istio 网格的 ID。
`extra_dimensions.cluster_name`	集群名称。OTel Collector 所在 ASM 平台中的集群名称。
`store.ttl`	内存存储中临时数据的存活时间。
`store.max_items`	内存中临时存储的 span 数据条目最大数量。

扩展（Extensions）

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

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

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

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

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

Service 部分

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

service 部分包含三个子部分：

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

service:
  extensions: [health_check, pprof, zpages]

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]
```
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 发行版中。每个认证扩展可以用于两种方式：

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

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

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

在 .extensions 下添加认证扩展及其配置。
在 .services.extensions 下添加认证器引用，使 Collector 加载它。
在 .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

这将创建两个证书：

一个名为 "OpenTelemetry Example" 的证书颁发机构（CA），存储在 ca.pem，对应密钥存储在 ca-key.pem。
一个由 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 选项不支持设置包含点号（.）或等号（=）的键。

操作指南

故障排除

操作指南

操作指南

操作指南

操作指南

操作指南

asm.alauda.io

networking.istio.io

operator.alauda.io

security.istio.io

#配置 OpenTelemetry Collector

#目录

#功能概述

#配置结构

#接收器（Receivers）

#OTLP 接收器

#Jaeger 接收器

#Zipkin 接收器

#处理器（Processors）

#Batch 处理器

#Memory Limiter 处理器

#Filter 处理器

#Metrics Transform 处理器

#Transform 处理器

#高级功能

#导出器（Exporters）

#OTLP 导出器

#OTLP HTTP 导出器

#Debug 导出器

#Load Balancing 导出器

#Prometheus 导出器

#连接器（Connectors）

#ASM Service Graph 连接器

#扩展（Extensions）

#Service 部分

#其他信息

#环境变量

#代理支持

#认证

#配置证书

#覆盖设置

配置 OpenTelemetry Collector

目录

功能概述

配置结构

接收器（Receivers）

OTLP 接收器

Jaeger 接收器

Zipkin 接收器

处理器（Processors）

Batch 处理器

Memory Limiter 处理器

Filter 处理器

Metrics Transform 处理器

Transform 处理器

高级功能

导出器（Exporters）

OTLP 导出器

OTLP HTTP 导出器

Debug 导出器

Load Balancing 导出器

Prometheus 导出器

连接器（Connectors）

ASM Service Graph 连接器

扩展（Extensions）

Service 部分

其他信息

环境变量

代理支持

认证

配置证书

覆盖设置