3. OpenTelemetry Collector 架构：Receiver、Processor、Exporter、Pipeline 配置

OpenTelemetry Collector 是值班机器人可观测性体系中的核心数据枢纽。它负责接收来自各类服务、基础设施和自定义探针的遥测数据（Trace、Metric、Log），并通过可插拔的组件对数据进行处理、过滤、增强，最终路由到一个或多个后端系统（如 Prometheus、Jaeger、Elasticsearch 或值班机器人自身的诊断存储）。

理解 Collector 的架构，是配置事件触发规则和自动化诊断链路的基础。Collector 内部采用 Pipeline（管道） 模式，由三种核心组件构成：Receiver（接收器）、Processor（处理器）和 Exporter（导出器）。

3.1 核心组件与职责

3.2 Pipeline 配置与数据流

Pipeline 是连接 Receiver、Processor 和 Exporter 的配置抽象。一个 Pipeline 定义了一条完整的数据处理路径。Collector 支持同时运行多个 Pipeline，每个 Pipeline 可以处理不同的信号类型（traces、metrics、logs）。

以下是一个典型的 Pipeline 配置示例，它接收 OTLP 数据，进行采样和属性增强，然后同时导出到 Jaeger 和值班机器人诊断系统：

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
  attributes:
    actions:
      - key: environment
        value: "production"
        action: upsert
  filter:
    error_mode: ignore
    traces:
      span:
        - 'attributes["http.status_code"] == 500 or attributes["http.status_code"] == 503'

exporters:
  jaeger:
    endpoint: jaeger-collector:14250
    tls:
      insecure: true
  otlphttp/oncall:
    endpoint: http://oncall-diagnosis:4318
    headers:
      "X-Source": "collector-pipeline"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [filter, attributes, batch]
      exporters: [jaeger, otlphttp/oncall]

3.3 组件交互架构图

下图展示了 Collector 内部一个 Pipeline 的完整数据流，以及组件之间的协作关系：

3.4 常用 Processor 详解

Processor 是 Pipeline 中实现数据治理和诊断增强的关键环节。值班机器人场景下，以下 Processor 最为常用：

• batch 处理器： 将多个 Span/Metric/Log 合并成一批发送，显著降低网络开销和下游存储压力。建议始终启用。
• filter 处理器： 基于属性或资源信息过滤数据。可用于只保留错误 Trace（如 status_code >= 500），减少无效数据量。
• attributes 处理器： 插入、更新或删除 Span/Metric/Log 的属性。常用于添加环境标签、服务版本、值班机器人路由标识。
• tail_sampling 处理器： 基于策略（如错误率、延迟、特定属性）对 Trace 进行采样。值班机器人可配置为“保留所有错误 Trace + 按比例采样正常 Trace”。
• memory_limiter 处理器： 防止 Collector 内存溢出。当内存使用超过阈值时，主动丢弃数据，保护进程稳定。

3.5 多 Pipeline 与信号隔离

在实际部署中，通常为 traces、metrics、logs 分别定义独立的 Pipeline。这样做的好处是：

• 隔离性： 某个信号类型的处理逻辑变更不会影响其他信号。
• 差异化配置： Trace 可能需要采样，Metric 可能需要聚合，Log 可能需要解析，各 Pipeline 可以独立配置 Processor。
• 资源控制： 可以为不同 Pipeline 分配不同的内存限制和并发度。

以下是一个多 Pipeline 配置片段：

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, tail_sampling, batch]
      exporters: [jaeger, otlphttp/oncall]
    metrics:
      receivers: [otlp, prometheus]
      processors: [memory_limiter, batch]
      exporters: [prometheusremotewrite]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, attributes, batch]
      exporters: [elasticsearch]

3.6 组件交互与数据流（第二张 SVG）

下图展示了多 Pipeline 场景下，不同信号类型如何通过各自的 Receiver、Processor 和 Exporter 独立流转，最终汇聚到值班机器人诊断中心：

3.7 配置最佳实践

• 始终启用 memory_limiter： 在生产环境中，memory_limiter 是防止 Collector OOM 的第一道防线。建议设置在总内存的 70%-80%。
• 合理使用 batch： batch 处理器能大幅提升吞吐量，但 timeout 不宜过长（建议 1s-5s），避免数据延迟过高。
• Pipeline 命名规范： 使用信号类型作为 Pipeline 名称（traces、metrics、logs），便于运维和排障。
• 避免循环依赖： 不要将同一个 Exporter 同时配置为另一个 Pipeline 的 Receiver，这会导致数据循环。
• 监控 Collector 自身： 通过 Collector 内置的 Prometheus 指标暴露端口，监控其内存、CPU、数据丢弃率等关键指标。