3. OpenTelemetry 管线概述

OpenTelemetry Collector 是 OTel 生态中的核心组件，负责接收、处理并导出遥测数据（Traces、Metrics、Logs）。理解 Collector 的架构与 Pipeline 组成，是构建可靠可观测性基础设施的第一步。本章将深入剖析 Collector 的内部结构、Pipeline 的三大核心组件以及数据流模型。

3.1 OTel Collector 架构

Collector 采用模块化、可插拔的架构设计，核心思想是通过 Pipeline 将数据采集与处理逻辑解耦。一个 Collector 实例可以运行多个 Pipeline，每个 Pipeline 独立处理一种或多种信号类型。

架构核心原则： 单一职责、可组合、无状态（推荐）。每个组件只做一件事，通过配置文件组合成完整的数据处理链路。

下图展示了 OTel Collector 的宏观架构，包含多个 Pipeline 及其与外部系统的交互关系：

OpenTelemetry Collector 架构概览 OTel Collector 架构概览 应用 / SDK Prometheus Fluentd / Syslog Receiver 层 OTLP Receiver Prometheus Receiver Filelog Receiver Jaeger Receiver Kafka Receiver ... 更多 Receiver Pipeline 实例 Pipeline 1: Traces batch → attributes → span Pipeline 2: Metrics batch → filter → transform Pipeline 3: Logs batch → filter → k8sattributes Exporter 层 OTLP Exporter Prometheus Exporter Loki Exporter Splunk HEC Exporter 后端存储 / 分析 Jaeger / Grafana 架构要点 • 数据源通过 Receiver 进入 Collector • Pipeline 串联 Processor 进行数据处理 • Exporter 将数据发送到后端系统 • 一个 Collector 可运行多个 Pipeline

3.2 Pipeline 组成：Receiver / Processor / Exporter

每个 Pipeline 由三个核心组件串联而成，形成一条完整的数据处理链路。三者职责清晰，通过配置文件声明式组合。

组件 职责 常见实现 可靠性关注点
Receiver 接收来自不同来源的遥测数据，将其转换为内部格式（pdata） OTLP Receiver、Prometheus Receiver、Filelog Receiver、Kafka Receiver、Jaeger Receiver 连接稳定性、背压处理、认证与授权
Processor 对数据进行过滤、转换、丰富、批处理、采样等操作 batch、attributes、filter、transform、span、k8sattributes、memory_limiter 内存泄漏、处理延迟、数据丢失、幂等性
Exporter 将处理后的数据发送到指定的后端系统或存储 OTLP Exporter、Prometheus Exporter、Loki Exporter、Splunk HEC Exporter、Logging Exporter 网络故障、重试策略、队列积压、数据完整性
最佳实践： 每个 Pipeline 至少包含一个 batch Processor 和一个 memory_limiter Processor。前者提升吞吐量，后者防止 OOM，是生产环境可靠性基线。

3.3 数据流模型

数据在 Pipeline 中的流动遵循严格的顺序模型：Receiver → Processor(s) → Exporter。Processor 可以串联多个，形成处理链。数据流模型的核心特征包括：

  • 单向流动： 数据从 Receiver 进入，经过 Processor 链，最终由 Exporter 输出，不支持反向流动。
  • 扇入与扇出： 多个 Receiver 可以输入到同一个 Pipeline；一个 Pipeline 可以配置多个 Exporter 实现数据复制。
  • 背压传播： 当下游 Exporter 处理缓慢时，背压会向上游传播，最终影响 Receiver 的数据接收速率。
  • 信号隔离： 不同信号类型（Traces、Metrics、Logs）建议使用独立的 Pipeline，避免相互干扰。

下图展示了单个 Pipeline 内部的数据流模型，以及背压传播路径：

Pipeline 内部数据流模型 Pipeline 内部数据流模型 Receiver OTLP / Prometheus 数据流 Processor batch Processor attributes Exporter OTLP / Prometheus 背压传播路径 数据流特征： • 数据单向流动：Receiver → Processor 链 → Exporter • 背压反向传播：Exporter 慢 → Processor 链 → Receiver

3.4 Pipeline 配置示例

以下是一个生产级 Pipeline 配置片段，展示了 Receiver、Processor、Exporter 的声明式组合：

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

processors:
  batch:
    timeout: 1s
    send_batch_size: 1024
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
    spike_limit_mib: 128
  attributes:
    actions:
      - key: environment
        value: production
        action: upsert

exporters:
  otlp:
    endpoint: "backend.example.com:4317"
    tls:
      insecure: false
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s
      max_elapsed_time: 300s

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch, attributes]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp]
可靠性陷阱： Processor 的顺序至关重要。例如，memory_limiter 应放在 Processor 链的最前面，以便在内存超限时尽早拒绝数据，避免后续 Processor 浪费计算资源。将 batch 放在 memory_limiter 之前可能导致批处理后的数据量突增，触发内存限制。

3.5 关键设计决策

在构建 OTel Collector Pipeline 时，以下设计决策直接影响可靠性：

决策项 推荐方案 不推荐方案 原因
信号隔离 Traces / Metrics / Logs 使用独立 Pipeline 所有信号混合在同一个 Pipeline 避免信号类型相互干扰，便于独立扩缩容和故障隔离
内存管理 始终配置 memory_limiter Processor 依赖系统 OOM Killer 主动背压比被动杀死进程更可控，减少数据丢失
批处理策略 使用 batch Processor，设置合理的超时和批次大小 逐条发送数据 批处理显著提升吞吐量，降低后端压力
重试与队列 Exporter 启用 retry_on_failure 和 sending_queue 无重试、无队列 临时故障时保证数据不丢失，队列提供缓冲能力
可靠性基线检查清单：
  • 每个 Pipeline 是否包含 memory_limiter？
  • 是否配置了 batch Processor？
  • Exporter 是否启用了重试和队列？
  • 不同信号类型是否使用独立 Pipeline？
  • Processor 顺序是否合理（memory_limiter 在前）？
← 上一章 📖 返回目录 下一章 →