3. OTel 架构总览：Collector、Exporter、Processor、Receiver、Pipeline

OpenTelemetry（OTel）的架构设计遵循“数据采集 → 处理 → 导出”的管道模式。核心组件包括 Receiver、Processor、Exporter，它们通过 Pipeline 串联，并由 Collector 统一管理。理解这五个概念是设计 Mock 隔离接口契约的前提。

3.1 核心组件与职责

下表列出了 OTel Collector 内部各组件的基本职责与典型用途：

组件 职责 典型实现
Receiver 接收来自应用、SDK 或其他数据源的遥测数据（Trace、Metric、Log）。 OTLP Receiver、Jaeger Receiver、Prometheus Receiver
Processor 对接收到的数据进行过滤、增强、批处理、采样或重命名等中间处理。 Batch Processor、Attributes Processor、Sampling Processor
Exporter 将处理后的数据发送到一个或多个后端系统（如 Jaeger、Prometheus、云服务）。 OTLP Exporter、Prometheus Exporter、Debug Exporter
Pipeline 定义数据流路径：指定 Receiver → Processor(s) → Exporter 的串联顺序。 traces pipeline、metrics pipeline、logs pipeline
Collector 作为运行时容器，加载配置、管理 Pipeline 生命周期、协调组件间通信。 otelcol、otelcol-contrib
设计要点：在 Mock 隔离接口契约中，Receiver 和 Exporter 是外部依赖的边界点，Processor 是内部逻辑的隔离单元。Pipeline 的配置决定了数据流的拓扑结构。

3.2 OTel Collector 内部数据流

下图展示了单个 Pipeline 内 Receiver、Processor、Exporter 之间的数据流动关系：

OTel Collector 内部 Pipeline 数据流 Receiver OTLP / Jaeger / Prom Processor 1 Batch Processor 2 Attributes Processor 3 Sampling Exporter OTLP / Prometheus Pipeline 定义：Receiver → Processor 链 → Exporter，数据按顺序流经每个阶段

3.3 Pipeline 配置与多信号隔离

OTel 支持三种信号（Traces、Metrics、Logs）各自独立配置 Pipeline。每个 Pipeline 可以拥有不同的 Receiver、Processor 链和 Exporter，实现信号级别的隔离。

配置示例（YAML）： 
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  batch:
    timeout: 1s
    send_batch_size: 1024
  attributes:
    actions:
      - key: environment
        value: "staging"
        action: upsert

exporters:
  otlp:
    endpoint: "backend:4317"
    tls:
      insecure: true
  debug:
    verbosity: detailed

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, attributes]
      exporters: [otlp, debug]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

3.4 组件间的接口契约

在 Mock 隔离测试中，需要明确各组件之间的数据接口。下表总结了关键接口契约：

接口方向 数据格式 传输协议 Mock 关注点
Receiver → Processor plog.Logs / pmetric.Metrics / ptrace.Traces 内部 Go 接口（gRPC 或 Channel） 数据结构的完整性与类型正确性
Processor → Processor 同上（不可变或可变引用） 内部函数调用 数据是否被错误修改或丢失
Processor → Exporter 同上 内部函数调用 导出前的最终数据状态
Exporter → 后端 OTLP Protobuf / JSON / 自定义 gRPC / HTTP 序列化与网络传输的正确性

3.5 多 Pipeline 架构示意

下图展示了 Collector 同时运行 Traces、Metrics、Logs 三个独立 Pipeline 的场景：

多信号 Pipeline 隔离架构 Traces Receiver Traces Processor Traces Exporter Metrics Receiver Metrics Processor Metrics Exporter Logs Receiver Logs Processor Logs Exporter 每个 Pipeline 独立配置 Receiver、Processor 链和 Exporter，互不干扰 Mock 测试时，可单独模拟某个 Pipeline 的输入/输出，验证隔离性

3.6 架构设计对 Mock 隔离的影响

  • Receiver 是入口边界：Mock 时需要模拟外部数据源，构造符合 OTLP 格式的请求。
  • Processor 是逻辑隔离单元：每个 Processor 可以独立 Mock 其输入输出，验证处理逻辑是否正确。
  • Exporter 是出口边界：Mock 后端服务，验证 Exporter 是否按预期发送数据。
  • Pipeline 是测试范围：可以针对单个 Pipeline 进行端到端 Mock，也可以跨 Pipeline 验证数据隔离性。
常见误区：不要将 Processor 与 Exporter 的 Mock 混为一谈。Processor 的 Mock 关注数据变换逻辑，Exporter 的 Mock 关注网络协议与序列化。两者应分别设计独立的 Mock 接口契约。
← 上一章 📖 返回目录 下一章 →