2. OpenTelemetry 概述：项目背景、核心组件与数据模型
OpenTelemetry（简称 OTel）是 CNCF 的毕业级可观测性标准，旨在统一指标、链路与日志三大信号的采集、处理与导出。本章从项目起源、核心组件到数据模型，建立对 OTel 的全局认知。
2.1 项目背景与演进
在 OTel 出现之前，可观测性领域存在两大痛点：
- 厂商锁定：每个 APM 厂商（Datadog、New Relic、Jaeger、Prometheus）都有自己的 SDK 和协议，切换成本极高。
- 信号割裂：链路追踪用 OpenTracing，指标用 OpenMetrics，日志用标准库，三者无法关联。
OTel 合并了 OpenTracing 与 OpenCensus 两大项目，于 2019 年正式进入 CNCF 孵化，2023 年成为毕业项目。其核心承诺是：一次埋点，任意后端。
关键里程碑：OTel 目前是 CNCF 中仅次于 Kubernetes 的第二活跃项目，已被 AWS、Azure、Google Cloud、Datadog、Grafana 等主流厂商原生支持。
2.2 核心组件架构
OTel 由三大核心组件构成，形成“采集 → 处理 → 导出”的管道：
2.3 组件职责详解
| 组件 | 职责 | 部署形态 | 典型场景 |
|---|---|---|---|
| Instrumentation | 在应用中插入埋点代码，自动或手动生成 Span/Metric/Log | 库/Agent/代码注入 | Java Agent 自动拦截 Servlet 请求 |
| SDK | 提供 API 实现、采样、上下文传播、导出 | 应用内依赖 | 配置基于概率的头采样 |
| Collector | 接收多源信号，执行处理管道，导出到后端 | 独立进程/sidecar | 边缘节点做 tail-based 采样 |
最佳实践：生产环境推荐 SDK 直连 Collector，由 Collector 统一做采样、过滤和重试，避免应用直接暴露后端地址。
2.4 数据模型：三大信号
OTel 定义了三种核心信号类型，每种都有独立但可关联的数据模型：
2.4.1 Traces（链路）
- Span：最小工作单元，包含名称、开始/结束时间、属性、事件、状态。
- Trace：由多个 Span 组成的树形结构，通过 TraceId 关联。
- SpanContext：包含 TraceId、SpanId、TraceFlags、TraceState，用于跨进程传播。
2.4.2 Metrics（指标）
- Counter：单调递增计数器（如请求总数）。
- Histogram：分布统计（如延迟分位数）。
- Gauge：可增可减的瞬时值（如内存使用率）。
- UpDownCounter：可增可减的计数器（如活跃连接数）。
2.4.3 Logs（日志）
- OTel 不重新定义日志格式，而是定义 LogRecord 结构，支持将已有日志（如 JSON 格式）桥接到 OTel 管道。
- 日志可通过
TraceId/SpanId字段与链路关联。
2.5 数据模型关联：信号关联机制
三大信号通过以下字段实现关联：
2.6 OTLP 协议
OTel 原生使用 OTLP（OpenTelemetry Protocol） 进行信号传输，支持 gRPC 和 HTTP/JSON 两种传输方式：
| 特性 | gRPC | HTTP/JSON |
|---|---|---|
| 性能 | 高（Protobuf 编码） | 中（JSON 编码） |
| 流式支持 | 原生双向流 | 需轮询或长连接 |
| 调试友好 | 低（二进制） | 高（可读） |
| 推荐场景 | 生产环境 Collector 间通信 | 开发调试 / 浏览器端 |
注意：OTLP 是 OTel 的推荐协议，但 Collector 也支持接收 Jaeger、Zipkin、Prometheus 等非 OTLP 格式，实现向后兼容。
2.7 本章小结
OTel 通过 Instrumentation → SDK → Collector 的三层架构，实现了可观测性信号的标准化采集与处理。其数据模型以 Trace、Metric、Log 三大信号为核心，通过 Resource 和 TraceId 实现跨信号关联。理解这些基础概念，是后续学习采样策略和 Runbook 门禁的前提。