2. OpenTelemetry 简介：起源、核心组件与架构
OpenTelemetry（简称 OTel）是云原生计算基金会（CNCF）旗下的可观测性标准，旨在统一指标（Metrics）、日志（Logs）和链路追踪（Traces）三大信号的采集、处理与导出规范。本章从起源、核心组件和整体架构三个维度，帮助您建立对 OTel 的系统认知。
2.1 起源：从 OpenTracing 与 OpenCensus 到统一标准
在 OTel 出现之前，可观测性领域存在两大主流开源项目：
| 项目 | 发起方 | 主要贡献 | 局限性 |
|---|---|---|---|
| OpenTracing | CNCF（2016） | 定义了跨语言的追踪 API 标准 | 仅覆盖链路追踪，无指标/日志规范 |
| OpenCensus | Google（2017） | 提供指标与追踪的 SDK 及导出能力 | 与特定后端绑定较紧，社区分裂 |
关键转折：2019 年，OpenTracing 与 OpenCensus 合并，共同成立 OpenTelemetry 项目。合并后保留了 OpenTracing 的 API 设计哲学和 OpenCensus 的 SDK 实现经验，形成“一个标准、多种实现”的格局。
2.2 核心组件：API、SDK、Collector
OTel 由三个核心层构成，每一层职责清晰、可独立替换：
- API（应用编程接口）：定义 Traces、Metrics、Logs 的数据模型与操作接口，与具体实现解耦。开发者只需依赖 API 包，不绑定任何 SDK。
- SDK（软件开发工具包）：实现 API 的具体逻辑，包括采样、上下文传播、批处理、导出等。SDK 可配置，支持插件化扩展。
- Collector（收集器）：独立的代理服务，负责接收、处理、导出遥测数据。支持多种接收器（Receiver）、处理器（Processor）和导出器（Exporter）。
最佳实践：生产环境中建议将 SDK 配置为仅发送数据到本地 Collector，由 Collector 统一进行过滤、采样、重试和路由，避免 SDK 直接与后端耦合。
2.3 架构总览：数据流与组件协作
下图展示了 OTel 的典型数据流：从应用埋点到后端存储，API/SDK 负责生成数据，Collector 负责中转与加工。
2.4 核心组件对比：API vs SDK vs Collector
| 维度 | API | SDK | Collector |
|---|---|---|---|
| 职责 | 定义数据模型与接口 | 实现数据采集与处理逻辑 | 数据路由、过滤、聚合、导出 |
| 部署位置 | 应用进程内（库引用） | 应用进程内（库引用） | 独立进程或 sidecar |
| 可替换性 | 标准接口，多语言通用 | 可切换不同 SDK 实现 | 可替换为其他 Collector |
| 典型配置 | 无配置，纯接口 | 采样率、导出地址、资源属性 | 接收器、处理器管道、导出器 |
| 性能影响 | 极低（仅接口调用） | 中等（序列化、批处理） | 独立资源，不影响应用 |
2.5 信号模型与协议
OTel 定义了三种核心信号（Signal），每种信号有独立的数据模型：
- Traces（链路追踪）：由 Span 组成，记录请求在分布式系统中的完整路径，包含 TraceId、SpanId、ParentSpanId、时间戳、属性等。
- Metrics（指标）：聚合型数值数据，如计数器（Counter）、直方图（Histogram）、仪表盘（Gauge），支持维度标签。
- Logs（日志）：带时间戳的结构化文本记录，支持与 Trace 关联（通过 TraceId 注入）。
所有信号默认通过 OTLP（OpenTelemetry Protocol） 协议传输，支持 gRPC 和 HTTP/Protobuf 两种方式。OTLP 是 OTel 的原生协议，也是 Collector 与 SDK 之间的首选通信方式。
注意：虽然 OTel 支持通过 Collector 导出到非 OTLP 后端（如 Prometheus、Jaeger、Loki），但 SDK 到 Collector 之间强烈建议使用 OTLP，以保留完整的上下文信息和元数据。
2.6 架构设计原则
OTel 架构遵循以下关键原则，这也是本课程后续 Mock 隔离设计的基础：
- 接口与实现分离：API 只定义契约，SDK 和 Collector 可独立演进。
- 管道化处理：Collector 内部采用 Receiver → Processor → Exporter 的管道模型，每个阶段可插拔。
- 无厂商锁定：通过 Exporter 抽象，同一份数据可同时写入多个后端。
- 上下文传播标准化：W3C TraceContext 和 Baggage 作为默认传播格式，保证跨服务链路完整性。