1. OpenTelemetry 概述
1.1 什么是 OpenTelemetry
OpenTelemetry（简称 OTel）是一个开源的可观测性框架，旨在为分布式系统提供统一的数据采集、处理和导出标准。它由 OpenTracing 和 OpenCensus 两个项目合并而成，现已成为 CNCF（云原生计算基金会）的毕业项目，也是云原生可观测性领域的事实标准。
OTel 的核心价值在于：一次埋点，随处导出。开发者只需接入 OTel SDK，即可将指标（Metrics）、日志（Logs）和链路（Traces）三大信号数据发送到任意后端系统（如 Prometheus、Jaeger、Grafana、Datadog 等），无需为每个后端重复实现采集逻辑。
关键概念：OpenTelemetry 不提供后端存储或可视化能力，它专注于数据的 生成、采集、处理与导出 环节。后端分析平台需要单独部署或选用 SaaS 服务。
1.2 核心组件：API、SDK、Collector
OpenTelemetry 的架构由三个核心层组成，每一层承担不同的职责：
| 组件 | 职责 | 使用场景 |
|---|---|---|
| API | 定义数据模型与接口规范（Span、Metric、LogRecord 等） | 应用代码直接调用，产生观测信号 |
| SDK | 实现 API 的具体逻辑：采样、上下文传播、批处理、导出 | 集成到应用中，负责数据采集与预处理 |
| Collector | 独立服务，接收、处理、转发遥测数据 | 边缘或中心节点，做数据聚合、过滤、重路由 |
架构要点：API 与 SDK 分离的设计，使得应用代码只依赖抽象接口，底层实现可随时替换（例如从 OTLP 导出改为 Jaeger 导出），无需修改业务逻辑。
1.3 可观测性三大支柱：指标、日志、链路
可观测性领域通常将数据分为三大信号类型，OpenTelemetry 对三者均提供原生支持：
- 指标（Metrics）：聚合型数值数据，描述系统在某一时刻或时间段内的状态。例如 CPU 使用率、请求 QPS、错误率、延迟分位数。OTel 支持 Counter、Histogram、Gauge 等指标类型。
- 日志（Logs）：带时间戳的离散事件记录，通常包含严重级别、消息体和结构化属性。OTel 定义了 LogRecord 模型，支持与 Trace 关联（通过 TraceId / SpanId）。
- 链路（Traces）：记录一次请求在分布式系统中的完整调用路径，由多个 Span 组成。每个 Span 包含操作名称、开始/结束时间、父 Span ID 和属性。链路是分布式问题定位的核心手段。
常见误区：三大支柱并非相互独立。在实际排障中，往往需要 链路驱动——先通过 Trace 找到异常请求，再关联该请求的 Metrics 和 Logs 进行根因分析。OTel 通过 TraceId 实现了三者之间的关联。
1.4 三大支柱对比
| 维度 | 指标 Metrics | 日志 Logs | 链路 Traces |
|---|---|---|---|
| 数据形态 | 聚合数值（时间序列） | 离散事件（文本/JSON） | 调用树（Span 列表） |
| 典型用途 | 监控告警、容量规划 | 排障审计、业务分析 | 分布式性能分析、依赖梳理 |
| 数据量 | 低（聚合后恒定） | 高（每条请求都可能产生） | 中（取决于采样率） |
| 存储成本 | 低 | 高 | 中 |
| OTel 支持 | Meter API / Metric SDK | Logger API / Log SDK | Tracer API / Trace SDK |
最佳实践：在生产环境中，建议对链路数据做 头部采样（Head Sampling）或 尾部采样（Tail Sampling）以控制存储成本；指标数据应提前设计好聚合维度，避免高基数（High Cardinality）导致性能问题；日志应使用结构化格式（如 JSON）并关联 TraceId，便于后续检索与关联分析。