illegalCreed

中文

English

中文

English

Appearance

入门：OpenTelemetry 与可观测性三支柱 ​

基于 OpenTelemetry 1.x（2026-05 CNCF 毕业） · 核于 2026-08

速查 ​

  • OpenTelemetry（OTel）定义：CNCF 主导的可观测性开放标准与工具包——统一 Metrics/Logs/Traces 三支柱的数据模型、API、SDK、传输协议（OTLP），让应用埋点一次，发任意后端，终结厂商锁定。它本身不是后端——不存储数据、不画图，只负责生产与传输遥测数据。
  • 可观测性（Observability）：从系统外部输出（遥测数据）推断内部状态的能力。三支柱：①Metrics 指标——时序数值（CPU/请求量/延迟），聚合后看趋势；②Logs 日志——离散事件的结构化文本，看具体发生了什么；③Traces 追踪——请求在分布式系统中的完整路径（span 树），看请求流经哪些服务、每段耗时。
  • 三支柱统一的价值：以前 Metrics 用 Prometheus client、Logs 用 Logstash、Traces 用 Jaeger client——三套 SDK 三套协议，换后端要重埋点。OTel 用**一套 API/SDK/协议（OTLP）**统一三者，埋点一次，数据可发任意后端（Prometheus/Jaeger/Tempo/ELK/Datadog……）。
  • OTLP（OpenTelemetry Protocol）：OTel 定义的遥测数据传输协议，是三支柱统一的传输根基。定义了数据「长什么样」（Metrics/Logs/Traces 的统一数据模型）和「怎么传」（gRPC 或 HTTP）。后端只要支持 OTLP 接收，就能消费 OTel 数据——这是后端无关的关键。
  • Instrumentation（埋点）：让代码产生遥测数据的过程。两种：①自动埋点——零代码改动，加载 instrumentation library 自动接入主流框架（HTTP/gRPC/Express/Kafka/DB 驱动）；②手动埋点——用 OTel API 在业务代码里自定义 span/metric/log（如「下单业务逻辑」的 span、业务计数器）。
  • Collector（采集器）：OTel 提供的数据代理——接收应用的遥测数据（receivers）→ 处理（processors，如采样、批处理、重标记）→ 导出（exporters）到一个或多个后端。解耦应用与后端：应用只发 OTLP 给 Collector，Collector 负责扇出到多后端、做采样/聚合。
  • Resource（资源）：描述遥测数据来源的属性（如 host.name、service.name、service.version、deployment.environment），附加在所有数据上，标识「这是哪个服务哪个版本产生的」。
  • Context Propagation（上下文传播）：追踪上下文（trace_id/span_id）跨服务跨进程传递——W3C Trace Context（traceparent header）是标准。A 调 B 时把 trace_id 传给 B，B 的 span 才能挂到 A 的 trace 树上，形成完整链路。
  • 2026-05 CNCF 毕业：继 Kubernetes、Prometheus、Envoy 之后，OTel 成为 CNCF 最高成熟度项目。过去 12 个月下载量超 26 亿次，采用率约 76%~79%（Grafana 2025 调查），确立「可观测性事实标准」地位。
  • 历史：OTel 由 OpenTracing（CNCF，追踪 API）和 OpenCensus（Google，追踪+指标）于 2019 年合并而来——结束两套标准的分裂，统一为 OpenTelemetry。
  • 进阶顺序：三支柱与 OTLP 详解 → Collector 与生态采用 → 参考。

一、为什么需要 OpenTelemetry：可观测性的三支柱难题 ​

分布式/微服务系统的可观测性比单体难得多——一个请求要经过多个服务，出了问题怎么定位？传统做法是堆工具：Metrics 用 Prometheus、Logs 用 ELK、Traces 用 Jaeger，每个后端有自己的 client SDK。这带来三个痛点：

  1. 标准碎片化：Metrics/Logs/Traces 三套 SDK、三套协议、三套数据模型。开发者要学三套，运维要部署三套。
  2. 厂商锁定：埋点代码绑死某个后端的 client（如 Datadog client），换后端要重埋一遍——迁移成本巨大。
  3. 上下文不统一：追踪的 trace_id 没法和 logs/metrics 关联——看 trace 时点不进对应日志，看 metric 异常时跳不到 trace。

OpenTelemetry 的解法：一套标准统一三支柱——统一的 API、统一的 SDK、统一的数据模型、统一的传输协议（OTLP）。应用只埋点一次，数据通过 OTLP 发给 Collector，Collector 再扇出到任意后端：

应用代码（OTel SDK 埋点）
   │
   │ OTLP（统一协议，三支柱一起传）
   ▼
Collector（接收 → 处理 → 导出）
   │
   ├─→ Prometheus（Metrics 存储）
   ├─→ Jaeger / Tempo（Traces 存储）
   ├─→ Loki / ELK（Logs 存储）
   └─→ Datadog / Honeycomb / New Relic（商业 SaaS）

核心价值：埋点一次，后端随便换——这是「你拥有自己的数据」（You own your data）的体现。

二、三支柱：Metrics、Logs、Traces ​

支柱数据形态回答什么典型场景OTel 成熟度
Metrics（指标）时序数值（带时间戳的数字）系统整体表现如何？（趋势/聚合）CPU 使用率、QPS、P99 延迟、错误率稳定（GA）
Logs（日志）结构化事件记录具体发生了什么？（离散事件）错误堆栈、用户行为、调试信息趋于稳定（2024-2025 各语言陆续 GA）
Traces（追踪）span 树（请求路径）请求流经了哪里？每段耗时？分布式调用链、性能瓶颈定位稳定（GA）
  • Metrics：聚合数据，回答「好不好」（如错误率 5%、「P99 200ms」）。擅长告警与趋势，但不告诉「为什么」。
  • Logs：详细事件，回答「发生了什么」（如「用户 123 下单失败，原因库存不足」）。信息量大但量也大，要检索。
  • Traces：请求路径，回答「卡在哪」（如「请求在 DB 查询耗时 800ms」）。串联多个服务的完整链路。
  • 三支柱联动：OTel 的精髓是三者共享 trace_id——从 metric 异常跳到对应 trace，从 trace 的 span 跳到对应 log，形成完整排障链路。

三、OTLP：统一传输协议 ​

OTLP（OpenTelemetry Protocol）是 OTel 定义的遥测数据传输协议，是三支柱统一的根基：

  • 统一数据模型：Metrics/Logs/Traces 有规范的 protobuf 数据结构（如 Span 有 trace_id/span_id/parent_span_id/name/start_time/end_time/attributes）。
  • 传输方式：默认 gRPC（OTLP/gRPC），也支持 HTTP（OTLP/HTTP，POST protobuf 或 JSON）。后端只要实现 OTLP 接收端，就能消费 OTel 数据。
  • 后端无关：应用只发 OTLP，不关心后端是 Prometheus 还是 Jaeger——Collector 负责转成各后端的格式（如 Prometheus 的 exposition format、Jaeger 的 thrift）。

四、埋点：自动 vs 手动 ​

让代码产生遥测数据叫「埋点（Instrumentation）」，OTel 提供两种方式：

  • 自动埋点（Automatic Instrumentation）：加载 instrumentation library（如 @opentelemetry/instrumentation-express），自动拦截主流框架的调用，零代码改动产生 span/metric。适合快速接入、覆盖通用调用（HTTP/gRPC/DB/Kafka）。
  • 手动埋点（Manual Instrumentation）：用 OTel API 在业务代码里显式创建 span、记录 metric、写 log。适合埋业务语义（如「处理支付」span、「订单数」counter）——这些自动埋点覆盖不到。
javascript
// 手动埋点示例（Node.js）
const tracer = trace.getTracer('my-app');
const meter = metrics.getMeter('my-app');
const orderCounter = meter.createCounter('orders.total');

// 业务 span（自动埋点覆盖不到的业务逻辑）
const span = tracer.startSpan('process_payment');
try {
  await processPayment(order);
  span.setAttribute('payment.amount', order.amount);
  orderCounter.add(1, { status: 'success' });
} catch (e) {
  span.recordException(e);
  span.setStatus({ code: 2 });  // ERROR
  orderCounter.add(1, { status: 'failed' });
} finally {
  span.end();
}

五、Collector：数据代理 ​

Collector 是 OTel 的数据中转站，解耦应用与后端：

  • Receivers（接收）：从应用收数据（OTLP 是主要的，也兼容 Jaeger/Prometheus/Zipkin 格式）。
  • Processors（处理）：批处理、采样、重标记、过滤、 обогащение（加 Resource 属性）。
  • Exporters（导出）：发到一个或多个后端（Prometheus/Jaeger/Tempo/Loki/Datadog……）。

应用只需配一个 OTLP 导出器指向 Collector，Collector 负责扇出——这样换后端只改 Collector 配置，应用不动。

六、CNCF 毕业与采用现状 ​

OpenTelemetry 于 2026 年 5 月正式从 CNCF 毕业（Graduated）——继 Kubernetes（2018）、Prometheus（2018）、Envoy（2018）之后，成为 CNCF 最高成熟度的项目。

  • 毕业意义：确认项目「广泛采用、治理成熟、社区活跃、生态完整」——正式确立「可观测性事实标准」。
  • 采用数据：过去 12 个月下载量超 26 亿次；Grafana 2025 可观测性调查显示 79% 组织使用 OpenTelemetry（采用率约 76%~79%）；71% 同时用 Prometheus + OTel。
  • 历史脉络：2019 年 OpenTracing + OpenCensus 合并成立 OTel → 2021 年进入孵化 → 2026 年毕业。

下一步 ​

理解了 OTel 的三支柱与基础后，下一步深入三支柱与 OTLP 详解（数据模型、OTLP 协议细节、埋点机制、Context 传播），以及Collector 与生态采用（Collector 架构、与 Prometheus/Jaeger 关系、毕业与采用）。