2. OpenTelemetry 概述:项目背景、核心组件与演进关系

OpenTelemetry(简称 OTel)是 CNCF(Cloud Native Computing Foundation)旗下的可观测性标准与工具集,旨在为分布式系统提供统一的遥测数据采集、处理与导出规范。本章从项目诞生背景、核心架构组件以及它与 OpenTracing、OpenCensus 的历史关系三个维度展开,帮助学员建立对 OTel 的整体认知。

2.1 项目背景:为什么需要 OpenTelemetry?

在微服务与云原生架构普及之前,应用监控通常依赖厂商绑定的 Agent 或私有 SDK。随着服务网格、Serverless、多语言异构系统成为常态,可观测性领域面临三大痛点:

  • 标准分裂:OpenTracing 仅定义链路追踪 API,OpenCensus 提供链路与指标但缺少日志,两者互不兼容。
  • 厂商锁定:每个后端(Jaeger、Zipkin、Prometheus、Datadog)都需要独立的 SDK 和 exporter,切换成本高。
  • 信号割裂:Trace、Metrics、Logs 三套信号由不同库采集,缺乏关联上下文。

2019 年,OpenTracing 与 OpenCensus 两大社区合并,启动 OpenTelemetry 项目,目标是从底层统一 API 规范、SDK 实现与数据导出协议,成为云原生可观测性的“事实标准”。

关键里程碑:2021 年 OTel 发布 GA 版本,2023 年成为 CNCF 毕业项目,目前已被 AWS、Google、Microsoft、Datadog、Honeycomb 等主流厂商原生支持。

2.2 核心组件:API、SDK、Collector

OpenTelemetry 采用分层架构设计,从上到下分为 API、SDK、Collector 三层,每层职责清晰、可独立替换。

组件 职责 典型实现 用户接触面
API 定义 Tracer、Meter、Logger 等接口与数据模型 opentelemetry-api (Java/Python/Go) 应用代码直接调用
SDK 实现 API 接口,提供采样、处理、导出等能力 opentelemetry-sdk + 各语言扩展 启动时配置,运行时透明
Collector 接收、处理、转发遥测数据的独立服务 opentelemetry-collector (Go) 运维部署,与后端对接

下图展示了 OTel 三层组件在典型微服务架构中的协作关系:

OpenTelemetry 三层核心组件协作图 应用代码 (Java / Python / Go) OTel API Tracer / Meter / Logger OTel SDK 采样 / 处理 / 导出 OTel Collector 接收 / 处理 / 转发 Jaeger Prometheus Datadog 应用通过 API 埋点,SDK 处理数据,Collector 统一转发到任意后端,实现厂商无关的可观测性

2.3 与 OpenTracing / OpenCensus 的关系

OTel 并非从零构建,而是继承了前两个项目的设计精华并做了统一升级。下表从多个维度对比三者:

维度 OpenTracing OpenCensus OpenTelemetry
发起方 CNCF / Uber Google / 社区 CNCF(合并后)
信号类型 仅 Trace Trace + Metrics Trace + Metrics + Logs
API 规范 仅接口定义 接口 + 部分实现 完整 API + SDK + Collector
数据导出 需第三方适配 内置多种 exporter OTLP 原生协议 + 丰富 exporter
当前状态 停止演进,建议迁移 停止演进,建议迁移 活跃开发,CNCF 毕业项目
迁移建议:如果你的项目仍在使用 OpenTracing 或 OpenCensus,官方提供了兼容桥接层(opentelemetry-extension-trace-propagators 等),可以逐步替换而不需要一次性重写所有埋点代码。

2.4 演进路线图

从 OpenTracing / OpenCensus 到 OpenTelemetry 的演进并非简单的版本升级,而是架构层面的重构:

  1. API 统一:将 Trace 和 Metrics 的 API 合并到同一命名空间,消除两套接口的割裂。
  2. SDK 可插拔:引入 Processor、Exporter、Sampler 等 SPI 机制,允许用户按需组装。
  3. 协议标准化:定义 OTLP(OpenTelemetry Protocol),支持 gRPC 和 HTTP 两种传输方式,成为 CNCF 可观测性数据交换标准。
  4. 日志集成:在 1.0 之后逐步将 Logs 信号纳入核心规范,实现三大信号的全覆盖。

下图展示了从 OpenTracing / OpenCensus 到 OpenTelemetry 的演进路径与核心变化:

从 OpenTracing / OpenCensus 到 OpenTelemetry 的演进 OpenTracing 仅 Trace API 2016 年 · CNCF OpenCensus Trace + Metrics 2018 年 · Google OpenTelemetry Trace + Metrics + Logs 2019 年 · CNCF 核心变化 1. 统一 API:不再区分 Trace 和 Metrics 两套接口 2. 完整 SDK:提供采样、处理、导出等生产级能力 3. 标准协议 OTLP:gRPC/HTTP 双通道,厂商无关 4. 日志集成:三大信号统一上下文关联

2.5 本章小结