3. OpenTelemetry Collector 架构：Receiver、Processor、Exporter、Pipeline、部署模式

OpenTelemetry Collector 是 OTel 生态中的核心数据平面组件，负责接收、处理、导出遥测数据（Traces、Metrics、Logs）。理解其内部架构是构建自动化 Runbook 响应体系的基础——只有掌握数据流经 Collector 的每个环节，才能精准定位异常事件发生的阶段。

3.1 核心组件与数据流

Collector 采用管道（Pipeline）驱动架构，由三大核心组件构成：Receiver（接收器）、Processor（处理器）、Exporter（导出器）。数据从 Receiver 进入，经过 Processor 链处理，最终由 Exporter 发送到后端。

3.2 组件详解

3.2.1 Receiver（接收器）

Receiver 是数据进入 Collector 的入口。它监听网络端口或读取本地数据，将外部遥测数据转换为 Collector 内部统一的 pdata（Pipeline Data）格式。每个 Receiver 通常对应一种协议或数据源。

3.2.2 Processor（处理器）

Processor 是 Pipeline 中的数据处理中间件，可以串联多个形成处理链。Processor 的执行顺序决定了数据变换的最终结果。常见的 Processor 按功能分为以下几类：

• 数据增强： attributes（添加/修改属性）、resource（修改资源信息）、span（修改 Span 属性）
• 数据过滤： filter（基于条件丢弃数据）、tailsampling（尾部采样）
• 数据聚合： batch（批处理合并）、memory_limiter（内存限制与背压）
• 数据路由： routing（根据属性路由到不同 Exporter）
• 数据转换： transform（使用 OTTL 语法转换数据）

3.2.3 Exporter（导出器）

Exporter 负责将处理后的数据发送到指定的后端系统（如监控平台、存储、分析工具）。每个 Exporter 对应一种输出协议或目标系统。

3.3 Pipeline 定义与配置

Pipeline 是 Collector 配置的核心，它将 Receiver、Processor、Exporter 组合成一个完整的数据处理链路。一个 Collector 实例可以同时运行多个 Pipeline，每个 Pipeline 处理一种信号类型（Traces / Metrics / Logs）。

以下是一个典型的 Collector 配置示例，包含 Traces 和 Metrics 两个 Pipeline：

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: otel-backend.example.com:4317
    tls:
      insecure: false
  logging:
    loglevel: debug

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

3.4 部署模式

OpenTelemetry Collector 支持多种部署模式，以适应不同的基础设施规模和架构需求。选择合适的部署模式是保障遥测数据可靠性和可观测性的关键。

3.5 部署模式选择建议

在自动化 Runbook 响应异常事件的场景中，部署模式的选择直接影响异常检测的时效性和数据完整性：

• Agent 模式：适合边缘节点或小型集群，异常事件可在本地快速处理，减少网络依赖。但需注意 Agent 本身的资源限制可能导致数据丢失。
• Gateway 模式：适合需要集中数据治理的场景，可以在 Gateway 层实现全局采样、过滤和路由规则。但 Gateway 成为单点，需配置高可用（多副本 + 负载均衡）。
• 混合模式：生产环境推荐方案。Agent 负责本地采集和预处理（如批处理、内存限制），Gateway 负责跨集群聚合、数据脱敏、路由到多个后端。异常事件可以在 Agent 层快速响应，也可以在 Gateway 层进行全局分析。

3.6 高可用与扩展性

Collector 本身是无状态的，这为实现高可用提供了天然优势。以下是生产环境中的关键实践：