📚 课程目录第3章 OTel Collector架构

3. OTel Collector 架构：Receiver/Processor/Exporter Pipeline、Batch Processor、Memory Limiter

OpenTelemetry Collector 是整个可观测性体系的核心数据枢纽。在值班机器人场景中，它负责接收来自微服务、基础设施和自定义探针的遥测数据，执行过滤、采样、聚合等处理，最终将事件路由到告警引擎和存储后端。理解 Collector 的 Pipeline 架构，是设计可靠事件接入链路的前提。

3.1 Pipeline 三要素：Receiver、Processor、Exporter

Collector 采用模块化管道（Pipeline）设计，每个 Pipeline 由三种组件串联而成：

组件	职责	值班机器人典型选型
Receiver	数据接入端点，支持 gRPC/HTTP、拉取 Prometheus 指标、接收 Jaeger/Zipkin 链路等	`otlp`（主接入）、`prometheus`（拉取指标）、`filelog`（采集容器日志）
Processor	数据加工与路由，可串联多个 Processor 形成处理链	`batch`、`memory_limiter`、`filter`、`attributes`、`k8sattributes`
Exporter	数据输出目标，支持写入后端、转发到另一个 Collector 或直接触发告警	`otlp`（转发）、`prometheusremotewrite`、`loki`、`kafka`

  设计原则：每个 Pipeline 必须包含至少一个 Receiver 和一个 Exporter；Processor 是可选的，但生产环境强烈建议至少配置 batch 和 memory_limiter。

3.2 Batch Processor：吞吐与延迟的平衡器

在值班机器人场景中，微服务每秒可能产生数千个 Span 和 Metric 数据点。如果每个数据点都立即发送给 Exporter，会导致：

Exporter 连接频繁建立/销毁，增加 CPU 和网络开销
后端写入压力陡增，容易触发限流或 OOM
告警评估窗口内数据碎片化，影响聚合准确性

Batch Processor 通过将多个数据单元合并为一个批次，显著提升吞吐效率。其核心参数如下：

参数	默认值	值班机器人推荐值	说明
`timeout`	200ms	1s	最大等待时间，超时后即使未满也发送
`send_batch_size`	8192	4096	批次最大数据单元数，达到即发送
`send_batch_max_size`	0（无限制）	8192	硬上限，防止单批次过大导致 OOM

调优建议：如果告警事件对延迟敏感（如 P1 故障），可将 timeout 缩短至 500ms，同时降低 send_batch_size 至 1024，以牺牲部分吞吐换取更快的告警触发。

3.3 Memory Limiter：防止 Collector 内存泄漏与 OOM

Collector 作为常驻进程，必须对内存使用有硬性约束。Memory Limiter Processor 在 Pipeline 中充当“安全阀”：当进程内存占用超过阈值时，主动拒绝新数据并触发背压（Backpressure），避免进程被 OOM Killer 杀死。

关键配置项：

配置项	作用	推荐值
`check_interval`	内存检查周期	1s
`limit_mib`	硬内存上限（MiB），达到后拒绝新数据	总内存的 60%
`spike_limit_mib`	突发容忍量，防止频繁触发限流	limit_mib 的 20%

重要：Memory Limiter 必须放置在 Pipeline 中所有 Processor 的最前面（紧接 Receiver 之后），以确保在数据进入任何可能消耗内存的处理逻辑之前，先进行内存检查。错误放置顺序会导致内存保护失效。

3.4 完整 Pipeline 配置示例

以下是一个面向值班机器人场景的 Collector 配置片段，展示了 Receiver、Processor（含 Batch 和 Memory Limiter）、Exporter 的串联关系：

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

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 2048          # 总内存 4GB 时，限制 2GB
    spike_limit_mib: 400     # 突发容忍 400MB
  batch:
    timeout: 1s
    send_batch_size: 4096
    send_batch_max_size: 8192
  filter:
    error_mode: ignore
    traces:
      span:
        - 'attributes["http.status_code"] == 200'  # 过滤正常请求

exporters:
  otlp/alert:
    endpoint: alert-collector:4317
    tls:
      insecure: true
  prometheusremotewrite:
    endpoint: http://victoria-metrics:8428/api/v1/write

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch, filter]
      exporters: [otlp/alert]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [prometheusremotewrite]

  关键设计点：
  memory_limiter 始终位于 Processor 列表首位，确保内存保护优先
batch 紧随其后，合并数据后再进入 filter 等有状态 Processor
Traces 和 Metrics 使用独立的 Pipeline，便于独立扩缩容和故障隔离
告警相关数据通过 otlp/alert Exporter 转发到专门的告警 Collector，与存储链路分离

3.5 生产环境最佳实践

Pipeline 隔离：Traces、Metrics、Logs 使用独立 Pipeline，避免互相阻塞。告警事件建议走单独的 Pipeline 和 Exporter。
Memory Limiter 阈值：设置为容器/进程内存限制的 60%~70%，预留空间给 GC 和突发流量。
Batch 超时与大小：根据告警延迟要求调整。延迟敏感场景用 500ms/1024，吞吐优先场景用 2s/8192。
背压可观测：开启 Collector 自身的 Prometheus 指标（otelcol_processor_refused_spans、otelcol_processor_batch_size），监控背压触发频率和批次大小。
多 Collector 分层：在每台宿主机部署 Agent Collector（轻量，仅做接入和转发），中心化 Gateway Collector（做聚合、过滤、告警路由），实现职责分离。