3. OpenTelemetry 架构总览：Collector、Exporter、Instrumentation、SDK 与 API
OpenTelemetry（简称 OTel）是一个可观测性框架，用于生成、采集、处理和导出遥测数据（链路、指标、日志）。其架构采用分层设计，核心组件包括 API、SDK、Instrumentation、Collector 和 Exporter。理解这些组件的关系是构建生产级链路追踪系统的基础。
架构核心思想： API 定义标准接口，SDK 实现具体逻辑，Instrumentation 自动注入埋点，Collector 负责数据路由与处理，Exporter 将数据发送到后端。这种解耦设计使得 OTel 可以跨语言、跨后端无缝工作。
3.1 核心组件与职责
下表总结了 OTel 架构中五个核心组件的职责与典型实现：
| 组件 | 职责 | 典型实现/示例 |
|---|---|---|
| API | 定义 Tracer、Span、Meter、Counter 等抽象接口，不依赖具体实现 | opentelemetry-api (Python/Java/Go) |
| SDK | 实现 API 接口，提供采样、上下文传播、SpanProcessor 等核心逻辑 | opentelemetry-sdk + BatchSpanProcessor |
| Instrumentation | 自动或手动为框架/库（如 Flask、gRPC、Redis）注入埋点代码 | opentelemetry-instrumentation-flask |
| Collector | 接收、处理、转发遥测数据的独立服务，支持批处理、过滤、重试 | opentelemetry-collector (二进制/Docker) |
| Exporter | 将 Span/Metric/Log 数据序列化并发送到后端（Jaeger、Prometheus、OTLP） | OTLPSpanExporter、JaegerExporter |
3.2 数据流与组件协作
下图展示了从应用埋点到后端存储的完整数据流，以及各组件在其中的位置：
3.3 组件深度解析
3.3.1 API 与 SDK
API 是 OTel 的契约层，定义了 TracerProvider、Tracer、Span、SpanContext 等核心接口。SDK 是这些接口的默认实现，提供以下关键能力：
- Sampler：控制哪些 Span 被记录（如 AlwaysOn、TraceIdRatioBased、ParentBased）。
- SpanProcessor：在 Span 开始/结束时执行回调，典型实现是
BatchSpanProcessor（批量导出）和SimpleSpanProcessor（同步导出）。 - Context Propagation：通过 W3C TraceContext 或 B3 格式在服务间传递 Trace ID 和 Span ID。
生产建议： 使用
BatchSpanProcessor 而非 SimpleSpanProcessor，避免每次 Span 结束都触发网络请求。批量导出可显著降低应用延迟。
3.3.2 Instrumentation（埋点）
Instrumentation 是 OTel 生态中最具价值的部分，分为自动埋点和手动埋点：
| 类型 | 原理 | 适用场景 | 示例 |
|---|---|---|---|
| 自动埋点 | 通过 Monkey Patch 或字节码增强拦截框架调用 | HTTP 服务、gRPC、数据库客户端、消息队列 | opentelemetry-instrumentation-flask |
| 手动埋点 | 在业务代码中显式创建 Span 并添加属性/事件 | 自定义业务逻辑、异步任务、关键路径 | tracer.start_as_current_span("process_order") |
3.3.3 Collector（采集器）
Collector 是一个独立进程，作为遥测数据的。其架构采用 Pipeline 模式：
Receivers → Processors → ExportersCollector 的典型部署模式有两种：
- Agent 模式：与应用同主机部署（Sidecar 或 DaemonSet），负责本地采集和初步处理。
- Gateway 模式：作为集群级集中服务，接收多个 Agent 的数据，进行全局过滤、路由和重试。
避坑提示： Collector 默认使用内存缓冲，如果后端不可用且未配置持久化队列，数据可能丢失。生产环境建议启用
file_storage 扩展或使用 Kafka 作为缓冲层。
3.3.4 Exporter（导出器）
Exporter 负责将 Span/Metric/Log 序列化为特定协议并发送到后端。OTel 原生支持以下导出协议：
| 协议 | 传输方式 | 后端支持 | 推荐场景 |
|---|---|---|---|
| OTLP (gRPC) | Protobuf over gRPC | Jaeger、Grafana Tempo、SigNoz | 高性能、低延迟，生产首选 |
| OTLP (HTTP) | Protobuf/JSON over HTTP | 同上 | 无法使用 gRPC 的环境 |
| Jaeger Thrift | Thrift over HTTP/UDP | Jaeger | 遗留 Jaeger 部署 |
| Prometheus | HTTP Pull | Prometheus、VictoriaMetrics | 指标导出 |
3.4 架构部署模式对比
根据团队规模和基础设施复杂度，OTel 架构有三种常见部署模式：
| 模式 | 组件分布 | 优势 | 劣势 |
|---|---|---|---|
| 直接导出 | 应用 SDK → Exporter → 后端 | 部署简单，无额外组件 | 应用与后端耦合，无缓冲/重试 |
| Agent + Gateway | 应用 → Agent Collector → Gateway Collector → 后端 | 解耦、缓冲、过滤、多后端路由 | 运维复杂度增加 |
| Kubernetes DaemonSet | 每个 Node 一个 Agent Collector，集中 Gateway | 自动发现 Pod，资源隔离 | 需管理 DaemonSet 配置 |
值班机器人集成提示： 在本课程后续章节中，我们将使用 Agent + Gateway 模式。Agent Collector 部署在值班机器人所在节点，负责采集链路数据；Gateway Collector 负责将数据路由到 Jaeger 用于追踪，同时将告警事件发送到值班机器人 Webhook。
3.5 架构设计原则总结
OTel 架构设计遵循以下原则，这些原则也是 SRE 在接入值班机器人时需要理解的关键：
- 解耦：API 与 SDK 分离，Instrumentation 与 Exporter 分离，使得更换后端或升级 SDK 无需修改业务代码。
- 可扩展：通过 Collector Pipeline 可以插入自定义 Processor（如脱敏、采样、标签注入）。
- 标准化：OTLP 协议成为 CNCF 事实标准，避免厂商锁定。
- 轻量：SDK 设计为低开销，BatchSpanProcessor 默认 5 秒或 2048 条 Span 批量导出。