基于OpenTelemetry的制品供应链误差预算台账构建 - 第2节
2.1 OpenTelemetry 项目背景
OpenTelemetry（简称 OTel）是由 OpenTracing 与 OpenCensus 两大开源项目于 2019 年合并而成的云原生计算基金会（CNCF）孵化项目。其诞生背景源于可观测性领域长期存在的“碎片化”问题：
- OpenTracing（2016）：提供厂商中立的分布式追踪 API，但缺乏 Metrics 和 Logs 的统一规范。
- OpenCensus（2018）：由 Google 发起，同时支持 Traces 和 Metrics 的采集与导出，但 API 与 SDK 耦合较紧。
- 合并目标：统一 API 规范、解耦 SDK 实现、覆盖 Traces / Metrics / Logs 三大信号，成为可观测性数据采集的“标准层”。
核心定位：OpenTelemetry 不提供后端存储或可视化，而是专注于数据生成、关联、传输的标准规范与参考实现。它让应用和基础设施能够以统一格式输出遥测数据，再交由 Prometheus、Jaeger、Grafana、Datadog 等后端处理。
2.2 核心组件：API、SDK、Collector
OpenTelemetry 的架构分为三层，每一层职责清晰，支持渐进式接入：
| 组件 | 职责 | 关键特征 |
|---|---|---|
| API | 定义 Traces、Metrics、Logs 的数据模型与操作接口 | 语言无关的规范；应用代码仅依赖 API，不绑定具体实现 |
| SDK | 实现 API 接口，提供采样、处理、导出等运行时能力 | 可配置的 SpanProcessor、MetricReader、LogRecordProcessor；支持多 exporter |
| Collector | 独立代理/网关，接收、处理、转发遥测数据 | 无状态部署；支持 pipeline 编排；内置批处理、过滤、重试、压缩 |
实践建议：在制品供应链场景中，推荐 SDK 负责应用内采集，Collector 负责边缘聚合与路由。这样即使后端变更，应用代码也无需重新发布。
2.2.1 组件协作关系
下图展示了 API、SDK、Collector 三者之间的数据流与职责边界：
2.3 信号类型：Traces、Metrics、Logs
OpenTelemetry 将可观测性数据归纳为三种核心信号（Signals），它们从不同维度描述系统状态：
| 信号 | 描述 | 典型用途（制品供应链） |
|---|---|---|
| Traces | 记录请求在分布式系统中的完整路径，包含 Span 树状结构 | 追踪一次制品构建从代码提交→编译→测试→打包→部署的全链路耗时与状态 |
| Metrics | 聚合后的数值型数据，如计数、直方图、Gauge | 构建成功率、制品签名覆盖率、供应链环节延迟 P99、误差预算消耗速率 |
| Logs | 带时间戳的结构化或非结构化事件记录 | 构建失败原因、签名验证异常、策略违规详情、审计事件 |
关键原则：三种信号必须通过 Context Propagation 实现关联。例如，一条 Trace 的 Span ID 可以注入到 Metrics 的标签和 Logs 的记录中，从而在排查问题时实现“从指标异常→追踪链路→日志详情”的快速下钻。
2.3.1 信号关联关系
下图展示了 Traces、Metrics、Logs 在制品供应链场景中的关联方式：
2.4 本章小结
- 项目背景：OpenTelemetry 统一了 OpenTracing 与 OpenCensus，成为 CNCF 可观测性数据采集标准。
- 核心组件：API（接口规范）、SDK（运行时实现）、Collector（数据网关），三者分层解耦。
- 信号类型：Traces（链路追踪）、Metrics（聚合指标）、Logs（事件日志），通过 Context Propagation 实现关联。
- 供应链场景：Traces 追踪构建全链路，Metrics 量化误差预算消耗，Logs 记录异常详情，三者共同支撑制品供应链的可观测性。