2. OpenTelemetry 概述：项目背景、核心组件与可观测性三大支柱
2.1 OTel 项目背景：从碎片化到统一标准
在 OpenTelemetry（简称 OTel）出现之前，可观测性领域面临严重的“碎片化”问题。不同的遥测信号（追踪、指标、日志）由不同的开源库和商业产品定义，导致以下痛点：
- 厂商锁定：应用代码直接耦合特定后端（如 Jaeger、Prometheus、Elasticsearch）的 SDK，切换成本极高。
- 信号割裂：追踪、指标、日志各自独立采集，缺乏关联上下文，难以实现真正的“事务级”可观测性。
- 重复造轮子：每个语言都需要独立的 instrumentation 库，社区力量分散。
OTel 由 OpenTracing 和 OpenCensus 两个项目合并而来，在 CNCF 孵化下成为事实上的可观测性标准。其核心目标只有一个：提供一套与厂商无关、跨语言、自动采集遥测数据的规范与工具。
关键里程碑：2019 年合并成立 → 2021 年发布 GA（通用可用）版本 → 2023 年成为 CNCF 毕业项目。目前支持超过 15 种主流编程语言，覆盖 200+ 集成库。
2.2 核心组件：API、SDK、Collector 三层架构
OTel 的架构设计遵循“规范-实现-处理”的分层原则，由三大核心组件构成：
| 组件 | 职责 | 关键特征 |
|---|---|---|
| API | 定义遥测数据生成的标准接口（Tracer、Meter、Logger） | 纯抽象，无实现；保证跨厂商兼容 |
| SDK | 实现 API 的具体逻辑（采样、上下文传播、导出） | 可配置、可扩展；支持多种后端导出器 |
| Collector | 独立服务，接收、处理、转发遥测数据 | 无侵入；支持过滤、聚合、批处理、重试 |
下图展示了 OTel 的三层架构及其数据流向：
2.3 OTel 与可观测性三大支柱
可观测性领域公认的“三大支柱”是 Traces（追踪）、Metrics（指标）、Logs（日志）。OTel 的设计从一开始就围绕这三者展开，并提供了统一的上下文传播机制。
2.3.1 三大支柱定义与 OTel 映射
| 支柱 | 定义 | OTel 信号类型 | 典型用例 |
|---|---|---|---|
| Traces | 记录请求在分布式系统中的完整调用链路 | Span（跨度） | 定位慢调用、错误传播分析 |
| Metrics | 聚合后的数值型数据，反映系统状态 | Counter、Histogram、Gauge | CPU 使用率、请求 QPS、延迟分布 |
| Logs | 带时间戳的结构化或非结构化事件记录 | LogRecord | 错误详情、审计日志、调试信息 |
2.3.2 三大支柱的关联：上下文是关键
传统做法中，三大支柱彼此孤立。OTel 通过 Context（上下文） 对象将三者关联起来：
- TraceId + SpanId 被注入到 Metrics 和 Logs 中，实现“指标可下钻到链路，日志可关联到请求”。
- Baggage 机制允许在跨服务传播时携带业务上下文（如用户 ID、订单 ID）。
实战要点：在 OTel 中，日志与追踪的关联通常通过
trace_id 和 span_id 字段实现。建议在日志框架中自动注入这两个字段，避免手动拼接。
下图展示了三大支柱如何在 OTel 的统一上下文中协同工作：
2.4 为什么 OTel 是事务边界的最佳载体
事务边界的本质是“跨服务、跨组件的请求生命周期”。OTel 的以下特性使其成为定义和追踪事务边界的天然选择：
- 分布式上下文传播：通过 W3C TraceContext 标准，自动将 TraceId 跨 HTTP/gRPC/消息队列传递。
- 统一信号模型：一个事务对应一个 Trace，Trace 内的每个 Span 代表一个边界节点（如数据库调用、外部 API 调用）。
- 灵活的采样策略：支持基于事务粒度的头部采样（Head Sampling）和尾部采样（Tail Sampling），精准控制数据量。
常见误区：不要将 OTel 等同于“链路追踪工具”。OTel 是一个可观测性框架，链路追踪只是其能力之一。事务边界实战中，需要同时利用 Traces、Metrics、Logs 三种信号才能完整还原事务状态。