1. OTel 概述：什么是 OpenTelemetry、OTel 的诞生背景与目标、OTel 在可观测性领域的定位
1.1 什么是 OpenTelemetry
OpenTelemetry（简称 OTel）是一个开源、厂商中立的可观测性框架，用于生成、采集、处理和导出遥测数据（Traces、Metrics、Logs）。它由 Cloud Native Computing Foundation（CNCF）孵化，是云原生生态中事实上的可观测性标准层。
OTel 的核心价值在于：一次埋点，随处分析。开发者只需接入 OTel SDK，即可将遥测数据发送到任意兼容的后端（如 Prometheus、Jaeger、Grafana、Datadog、AWS X-Ray 等），无需为每个厂商重写采集逻辑。
关键定义： OpenTelemetry 不是可观测性后端，也不是可视化工具，而是数据采集与标准化管道——它解决的是“数据怎么来、怎么传、怎么统一格式”的问题。
1.2 OTel 的诞生背景
在 OTel 出现之前，可观测性领域面临严重的碎片化问题：
| 维度 | 问题描述 | 典型代表 |
|---|---|---|
| Trace 标准 | 多个不兼容的分布式追踪协议 | OpenTracing、Zipkin、Jaeger 原生格式 |
| Metrics 标准 | 采集与暴露方式各异 | Prometheus、StatsD、Graphite |
| Logs 标准 | 日志格式、上下文关联缺失 | Log4j、Logback、Fluentd |
| 厂商锁定 | 一旦选择某个 APM 厂商，迁移成本极高 | Datadog、New Relic、Dynatrace |
2019 年，CNCF 社区决定合并两个最活跃的追踪标准项目——OpenTracing 和 OpenCensus，创建统一的 OpenTelemetry。这一合并解决了以下痛点：
- API 统一： 不再需要同时维护两套 Trace API。
- 采集器统一： OpenCensus Agent 与 OpenTracing 的 Collector 合并为 OTel Collector。
- 信号统一： 从仅关注 Trace 扩展到 Trace + Metrics + Logs 三大信号。
- 厂商中立： 数据导出层采用插件化架构，后端可随时切换。
1.3 OTel 的目标
OpenTelemetry 项目设定了三个核心目标：
- 标准化数据采集： 为 Trace、Metrics、Logs 提供统一的 API、SDK 和语义约定（Semantic Conventions），使不同语言、不同框架的遥测数据格式一致。
- 消除厂商锁定： 通过插件化 Exporter 架构，用户可随时切换后端，无需修改业务代码。
- 降低接入门槛： 提供自动埋点（Auto-instrumentation）机制，开发者只需几行配置即可完成基础可观测性接入。
实践提示： OTel 的自动埋点支持 Java、Python、Node.js、Go、.NET 等主流语言，通过字节码增强或钩子机制自动捕获 HTTP 请求、数据库调用、消息队列等常见操作的 Trace 和 Metrics。
1.4 OTel 在可观测性领域的定位
在完整的可观测性技术栈中，OTel 处于数据采集与标准化层，位于应用与后端存储/分析之间。其定位可以用以下分层模型清晰表达：
具体来说，OTel 在可观测性生态中扮演以下角色：
| 角色 | 说明 | 不属于 OTel 的职责 |
|---|---|---|
| 数据生产者 | 通过 SDK 在应用中生成 Trace、Metrics、Logs | 业务逻辑处理、应用性能优化 |
| 数据管道 | OTel Collector 负责接收、处理、过滤、路由、导出 | 数据持久化存储、长期归档 |
| 格式标准化 | 定义统一的语义约定（HTTP、DB、Messaging 等） | 自定义业务指标的语义定义 |
| 厂商适配层 | 通过 Exporter 将数据发送到任意后端 | 后端的数据查询语言、告警规则、仪表盘 |
常见误区： OTel 不是 APM（应用性能管理）系统，也不是可观测性平台。它不提供仪表盘、不触发告警、不存储历史数据。这些功能由后端系统（如 Grafana、Datadog、SigNoz）完成。OTel 的边界止于数据导出。
1.5 为什么 OTel 是“领域边界”的关键
理解 OTel 的定位，本质上是在划定可观测性工程中的职责边界：
- 向上： 应用开发者只需关注 OTel API，无需关心后端实现。
- 向下： 后端厂商只需实现 OTel 协议（OTLP），即可接入所有 OTel 数据源。
- 横向： OTel 不替代 Prometheus、Jaeger、Loki 等工具，而是让它们能消费统一格式的数据。
这种边界划分使得可观测性架构变得可插拔、可演进、可替换，是云原生时代基础设施标准化的关键一步。