OpenTelemetry
OpenTelemetry（OTel）是 CNCF 主导的可观测性（Observability）开放标准与工具包——它统一了指标（Metrics）、日志（Logs）、追踪（Traces）三大支柱（Three Pillars）的数据模型、API、SDK 与传输协议（OTLP），让应用只需埋点一次，就能把遥测数据发给任意后端（Prometheus、Jaeger、Tempo、ELK、Datadog、Honeycomb……），彻底终结「换一个监控后端就要重埋一次点」的厂商锁定。2026 年 5 月，OpenTelemetry 从 CNCF 毕业（Graduated）——继 Kubernetes、Prometheus、Envoy 之后，成为 CNCF 最高成熟度的项目，正式确立「可观测性事实标准」地位（过去 12 个月下载量超 26 亿次，采用率约 76%~79%）。
OpenTelemetry 的全部考点围绕统一标准与数据流展开：①三支柱统一（Metrics 时序指标、Logs 结构化日志、Traces 分布式追踪——同一套 API/SDK/数据模型）；②OTLP 协议（OpenTelemetry Protocol，三支柱统一的遥测数据传输协议，是后端无关的根基）；③Instrumentation 埋点（自动埋点——零代码改动接入框架；手动埋点——用 API 自定义业务 span/metric/log）；④Collector 采集器（接收-处理-导出的代理，解耦应用与后端，支持多后端 fan-out）；⑤生态关系（OpenTelemetry 是数据源/生产者，Prometheus/Jaeger/Grafana 是存储/可视化消费者——OTel 不存数据不画图）；⑥2026-05 CNCF 毕业（采用率 ~76%，从 OpenTracing + OpenCensus 合并而来）。本叶是可观测性章节的总览与地基，讲清 OTel 的三支柱、OTLP、埋点、Collector 与生态定位。
评价
优点
- 统一标准：一份埋点覆盖 Metrics/Logs/Traces 三支柱，一套 API/SDK/协议，终结标准碎片化
- 后端无关：OTLP + Collector 让数据可发任意后端，无厂商锁定，迁移只改导出配置
- 自动埋点：主流框架（HTTP/gRPC/DB/Kafka）零代码改动接入，接入成本极低
- CNCF 毕业项目（2026-05）：与 Kubernetes、Prometheus 同级，生态最广、采用率 ~76%
- W3C 标准对接：Trace Context（traceparent）是 W3C 推荐，跨服务跨语言传播追踪上下文
缺点
- 不做后端：OTel 只生产/传输数据，不存储不可视化——仍要 Prometheus/Jaeger/Tempo/Grafana 等消费
- 配置复杂：SDK 配置项繁多（采样率、导出器、资源属性、上下文传播），学习曲线陡
- Logs 信号成熟度落后：Metrics/Traces 已 GA，Logs 信号在多数语言 SDK 仍趋于稳定（2024-2025 陆续 GA）
- 性能开销：埋点有 CPU/内存/网络开销，高频埋点要配采样策略，否则影响应用性能
- 生态迁移中：从 Prometheus client / Jaeger client / 厂商 SDK 迁移到 OTel SDK 是渐进过程，存量系统改造工作量大
本叶地图
- 入门 —— OpenTelemetry 是什么、三支柱（Metrics/Logs/Traces）、OTLP、自动/手动埋点、Collector、CNCF 毕业
- 三支柱与 OTLP 详解 —— Metrics/Logs/Traces 数据模型、OTLP 协议、Instrumentation（自动/手动）、Resource/Context 传播
- Collector 与生态采用 —— Collector 架构（接收-处理-导出）、与 Prometheus/Jaeger/Tempo 关系、2026 CNCF 毕业、采用现状
- 参考 —— 三支柱速查、Collector 组件清单、API/SDK/Instrumentation 对比、易错点