2. OpenTelemetry 架构：OTel Collector 架构、SDK 与 API、Exporters 与 Processors
OpenTelemetry（OTel）的架构设计遵循“数据产生 → 数据处理 → 数据导出”的管道模式。整个体系由 API、SDK、Collector 三大核心组件构成，并通过 Exporters 和 Processors 实现灵活的数据路由与变换。理解这一架构是进行 Mock 隔离测试的基础。
2.1 核心组件：API、SDK 与 Collector
OTel 将可观测性数据的生成与处理职责分离，形成清晰的层次结构：
| 组件 | 职责 | Mock 隔离关注点 |
|---|---|---|
| API | 定义 Traces、Metrics、Logs 的数据模型与操作接口（如 Tracer、Meter）。 | Mock 时需模拟 API 接口行为，不依赖真实 SDK 实现。 |
| SDK | 实现 API 接口，负责采样、上下文传播、Span 生命周期管理。 | Mock 测试中可替换 SDK 的 Sampler、SpanProcessor 等组件。 |
| Collector | 独立进程，接收、处理、导出遥测数据，支持多种协议（gRPC/HTTP）。 | Mock 测试中可模拟 Collector 的接收端与导出端，验证管道行为。 |
Mock 隔离要点： 在单元测试中，优先 Mock API 层；在集成测试中，Mock Collector 的接收端点；在端到端测试中，使用 Mock Exporter 验证数据完整性。
2.2 OTel Collector 架构详解
OTel Collector 是一个可插拔的管道引擎，其内部架构分为三个主要阶段：Receivers → Processors → Exporters。数据流通过 Pipelines 串联，支持多信号类型（traces、metrics、logs）的独立配置。
2.3 SDK 与 API 的协作机制
SDK 是 API 的具体实现，负责将应用中的遥测信号转换为 OTel 标准格式。其内部关键组件包括：
- TracerProvider / MeterProvider：管理 Tracer 和 Meter 实例，是 SDK 的入口点。
- SpanProcessor：在 Span 开始/结束时触发回调，用于批处理、导出或 Mock 拦截。
- Sampler：决定哪些 Span 被采样，Mock 时可替换为“全部采样”或“全部丢弃”。
- Exporter：将数据发送到 Collector 或后端，Mock 时替换为 MemoryExporter 或 NoopExporter。
Mock 实践： 在测试中，通过
SpanProcessor 的 Mock 实现，可以捕获所有 Span 数据并断言其属性，而无需启动 Collector 或后端服务。
2.4 Exporters 与 Processors 详解
Exporters 负责将处理后的数据发送到目标后端（如 Jaeger、Prometheus、云服务）。Processors 在数据导出前执行变换、过滤、批处理等操作。两者共同决定了数据的最终形态与流向。
| 组件 | 常见类型 | Mock 测试策略 |
|---|---|---|
| Exporter | OTLP Exporter、Console Exporter、Prometheus Exporter、Logging Exporter | 使用 InMemoryExporter 或 Mock Exporter 验证数据格式与内容。 |
| Processor | Batch Processor、Attributes Processor、Filter Processor、Span Processor | Mock Processor 可模拟数据变换逻辑，验证管道行为是否符合预期。 |
2.5 架构总结与 Mock 切入点
OTel 架构的层次化设计为 Mock 隔离测试提供了清晰的切入点：
- API 层 Mock：适用于单元测试，模拟 Tracer/Meter 接口，不加载 SDK。
- SDK 层 Mock：适用于集成测试，替换 SpanProcessor 或 Exporter，验证数据生成逻辑。
- Collector 层 Mock：适用于端到端测试，模拟 Receiver 或 Exporter，验证管道配置与数据处理流程。
注意： 在 Mock 测试中，务必确保 Mock 组件的行为与真实组件在关键路径上一致（如数据格式、错误处理），否则 Mock 测试可能掩盖生产环境中的真实问题。