3. OpenTelemetry 架构与组件：Collector、Exporter、Processor、SDK 与 API 的关系

在构建值班机器人的可观测性体系时，OpenTelemetry 的组件化架构是核心基础。本章将深入剖析 Collector、Exporter、Processor、SDK 与 API 这五大组件的职责、协作关系以及在生产环境中的部署模式。理解这些组件的边界与交互，是设计高可靠链路追踪与告警聚合系统的前提。

3.1 整体架构分层

OpenTelemetry 的架构可以抽象为三层：数据产生层（SDK/API）、数据管道层（Collector）和数据导出层（Exporter）。Processor 作为 Collector 内部的逻辑引擎，负责数据的过滤、采样与增强。

3.2 SDK 与 API：数据产生的起点

SDK 和 API 是嵌入在应用程序中的轻量级库，负责自动或手动采集遥测数据。API 定义接口规范，SDK 提供具体实现。

组件	职责	值班机器人场景示例
API	定义 Tracer、Meter、Logger 等接口，不依赖具体实现	在代码中调用 tracer.startSpan("handle_alert")
SDK	实现 API 接口，管理 SpanProcessor、MetricReader 等	配置 BatchSpanProcessor 将 Span 批量发送到 Collector
Instrumentation	自动埋点库，为常见框架（Flask、gRPC、Redis）生成遥测	使用 opentelemetry-instrumentation-flask 自动追踪 HTTP 请求

3.3 Collector：数据管道的中枢

Collector 是一个独立部署的进程，负责接收、处理和转发遥测数据。它支持三种部署模式：Agent（与应用程序同主机部署）、Gateway（独立集群部署）以及单实例（开发测试用）。

3.3.1 Collector 内部流水线

Collector 的数据处理遵循严格的流水线顺序：Receiver → Processor → Exporter。每个阶段都可以配置多个组件，形成复杂的处理拓扑。

3.4 Processor：数据加工的核心

Processor 是 Collector 中最具可编程性的组件。值班机器人场景中，Processor 承担以下关键职责：

• 批处理（Batch Processor）：将多个 Span/Metric 合并为一批，减少网络开销。建议设置 timeout=5s 和 send_batch_size=1024。
• 采样（Sampling Processor）：支持头部采样（Head Sampling）和尾部采样（Tail Sampling）。告警链路建议使用尾部采样，保留完整错误链路。
• 属性修改（Attributes Processor）：为 Span 注入环境标签、服务版本、告警级别等上下文信息。
• 过滤（Filter Processor）：丢弃健康检查、心跳等低价值遥测数据，降低存储成本。
• 内存限制（Memory Limiter Processor）：防止 Collector OOM，设置软硬限制。

3.5 Exporter：数据输出的桥梁

Exporter 将处理后的遥测数据发送到后端存储或分析系统。OpenTelemetry 支持多种 Exporter，值班机器人架构中常用的包括：

Exporter 类型	协议	适用后端	值班机器人用途
OTLP Exporter	gRPC / HTTP	Jaeger、Grafana Tempo、SigNoz	链路追踪数据主通道
Prometheus Exporter	HTTP Pull	Prometheus + Alertmanager	告警指标暴露
Loki Exporter	HTTP Push	Grafana Loki	告警日志聚合
Kafka Exporter	Kafka Producer	Kafka + 流处理平台	高吞吐告警事件缓冲

3.6 组件协作流程：一次告警链路的完整生命周期

以值班机器人收到一条告警为例，展示各组件如何协作：

1. SDK 埋点：告警处理函数中调用 tracer.startSpan("process_alert")，创建 Span。
2. SDK 导出：BatchSpanProcessor 将 Span 序列化为 OTLP 格式，通过 gRPC 发送到 Collector。
3. Collector 接收：OTLP Receiver 反序列化数据，放入内部管道。
4. Processor 处理：依次经过 memory_limiter → batch → attributes（注入告警级别标签）→ filter（丢弃 DEBUG 级别）→ tailsampling（保留 ERROR 级别完整链路）。
5. Exporter 输出：OTLP Exporter 将 Span 写入 Jaeger；Prometheus Exporter 暴露告警处理延迟指标。
6. 后端消费：Jaeger 存储链路，Prometheus 触发告警规则，Grafana 展示仪表盘。

3.7 部署模式对比

模式	部署位置	优势	劣势	值班机器人适用场景
Agent 模式	与业务容器同 Pod / 同主机	低延迟、数据不经过网络	资源占用、管理分散	高敏感告警链路，需实时处理
Gateway 模式	独立集群	集中管理、弹性伸缩、统一采样	增加一跳网络延迟	大规模告警聚合，多集群统一出口
混合模式	Agent + Gateway 级联	兼顾低延迟与集中管理	架构复杂、运维成本高	值班机器人多区域部署，需全局链路视图