📚 课程目录第2章 OpenTelemetry Collector架构

2. OpenTelemetry Collector 架构：Receiver、Processor、Exporter、Pipeline 的核心组件与数据流

OpenTelemetry Collector 是一个与厂商无关的、可扩展的数据采集与处理代理。理解其内部架构是分析 Collector 配置如何影响 SLI 口径数据采集的基础。Collector 的核心设计围绕四个基本组件展开：Receiver、Processor、Exporter，以及将它们串联起来的 Pipeline。

2.1 核心组件概述

下表总结了四个核心组件的职责、典型类型及其在 SLI 数据采集中的关键作用。

组件	职责	典型类型	对 SLI 采集的影响
Receiver	接收来自各种源（应用、基础设施、其他 Collector）的遥测数据。	`otlp`, `prometheus`, `jaeger`, `kafka`	决定了 SLI 数据的入口格式和协议，直接影响数据源的兼容性。
Processor	在 Receiver 和 Exporter 之间对数据进行过滤、转换、丰富、采样和聚合。	`batch`, `filter`, `attributes`, `memory_limiter`, `span`	直接修改 SLI 口径，例如过滤掉非关键路径、聚合延迟数据、添加 SLI 标签。
Exporter	将处理后的数据发送到一个或多个后端系统（存储、分析、可视化）。	`otlp`, `prometheus`, `logging`, `elasticsearch`	决定了 SLI 数据的输出格式和目的地，影响数据能否被 SLI 计算系统正确消费。
Pipeline	定义数据流路径：指定哪些 Receivers、Processors、Exporters 按顺序组合。	YAML 配置中的 `pipelines` 部分	定义了 SLI 数据的处理拓扑，错误的 Pipeline 配置会导致数据丢失或口径不一致。

2.2 数据流与 Pipeline 机制

Pipeline 是 Collector 的“神经系统”。一个典型的 Pipeline 配置如下所示，它定义了从接收数据到最终导出的完整路径。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  batch:
    timeout: 1s
    send_batch_size: 1024
  memory_limiter:
    check_interval: 1s
    limit_mib: 512

exporters:
  otlp:
    endpoint: "backend.example.com:4317"
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp]

在这个配置中，数据流是单向的：otlp Receiver → memory_limiter Processor → batch Processor → otlp Exporter。Processor 的顺序至关重要，例如，memory_limiter 必须在 batch 之前，以防止在批处理过程中内存溢出。

  关键点： 每个 Pipeline 只能处理一种信号类型（traces, metrics, logs）。如果要同时采集 Trace 和 Metric 类型的 SLI 数据，需要定义两个独立的 Pipeline。

2.3 组件交互与数据流架构图

下图展示了 Collector 内部组件如何通过 Pipeline 协同工作，形成完整的数据流。

2.4 Processor 链：SLI 口径控制的核心

Processor 是影响 SLI 数据口径最关键的组件。它们以链式方式执行，每个 Processor 都可以对数据进行修改。常见的 Processor 及其对 SLI 的影响如下：

memory_limiter：防止 Collector OOM。如果配置不当，可能导致数据被丢弃，造成 SLI 数据缺失。
batch：将数据分批发送，提高吞吐量。批处理大小和时间间隔会影响 SLI 数据的实时性。
filter：根据条件（如 Span 属性、Metric 名称）丢弃数据。可用于排除健康检查、探活等非业务流量，确保 SLI 只反映真实用户请求。
attributes：添加、删除或修改数据的属性。可用于为 SLI 数据注入环境标签（如 env=production、service=payment），便于后续按维度聚合。
span：专门处理 Span 数据，例如提取 Span 的延迟信息，生成新的 Metric（如 http.server.duration），这是构建延迟类 SLI 的关键步骤。
transform：提供强大的数据转换能力，允许用户编写 OTTL（OpenTelemetry Transformation Language）表达式，对数据进行复杂的聚合、重命名和计算，是实现自定义 SLI 口径的终极工具。

最佳实践： 在配置 Processor 链时，始终将 memory_limiter 放在最前面，将 batch 放在最后面（紧挨 Exporter）。这样可以确保内存安全，并最大化导出效率。

2.5 多 Pipeline 与数据隔离

在生产环境中，通常需要为不同的信号类型或不同的数据源配置独立的 Pipeline。例如，一个 Pipeline 处理来自生产环境的 Trace 数据，另一个 Pipeline 处理来自预发布环境的 Metric 数据。这种隔离可以防止数据相互干扰，并允许为不同的 SLI 口径应用不同的处理策略。

service:
  pipelines:
    traces/production:
      receivers: [otlp]
      processors: [memory_limiter, filter/production_only, batch]
      exporters: [otlp/production_backend]
    metrics/staging:
      receivers: [prometheus]
      processors: [memory_limiter, batch]
      exporters: [prometheus/staging_backend]

通过这种方式，Collector 架构提供了极大的灵活性，使得 SRE 团队可以精确控制每一条 SLI 数据的采集、处理和路由路径，从而确保 SLI 口径的一致性和准确性。