可观测性:指标、日志与分布式追踪

06-工程实践与前沿 核心 约 20 分钟 #可观测性#分布式追踪#OpenTelemetry#SLO 更新 2026-10-02
当前状态:未学
本文基于模型知识整理(生成时未联网核对),关键结论建议对照经典文献复核。

一句话定义

可观测性用三类信号回答"系统现在怎么样、为什么这样":指标(聚合数值,回答 what)、日志(离散事件,回答 why)、分布式追踪(跨服务调用链,回答 where);TraceID 把三者关联起来,构成排障的完整证据链。

为什么重要

单机时代"登机器看日志"就能定位问题;几十个服务的调用链上,一次用户请求横跨数十个进程,没有追踪就无法回答"慢在哪"。可观测性是 kp-030 三板斧的触发依据、SLO 管理的数据底座,也是故障复盘的证据来源。

前置知识

kp-007(RPC 链路)、kp-002(分位数指标)。

核心概念

  • 指标(metrics):时间序列聚合(QPS、延迟分位数、错误率、饱和度),存取便宜、可告警——RED 方法(Rate/Errors/Duration)定义每个服务的三个黄金指标;USE 方法(Utilization/Saturation/Errors)定义每个资源的。
  • 日志(logs):结构化(JSON 字段)优于纯文本;带 TraceID 后可从指标下钻到具体请求日志。
  • 分布式追踪(traces):一次请求生成全局唯一 TraceID,每个服务内的工作单元为 Span(含父子关系与耗时),TraceID 随请求头透传(kp-007 的元数据通道)。
  • 采样:头部采样(入口决定,省资源但可能丢罕见路径)vs 尾部采样(按结果延迟/错误保留,全量收集后筛选,成本高)。
  • SLO 燃烧率告警:以"错误预算消耗速率"而非瞬时错误率告警,减少噪音并直接对应可用性承诺(kp-002 的 SLA 体系)。

原理与机制

追踪的工作机制:入口服务生成 TraceID 与根 Span,调用下游时把 (TraceID, 当前 SpanID, 采样标记) 注入 RPC 头;下游解包并创建子 Span。延迟分析即沿 Span 树找"最宽的子树"(时间大头)。跨消息队列(kp-008)同样以消息头携带追踪上下文,消费侧接续链路——异步链路不追踪等于盲区。

三信号的关系是"漏斗":告警靠指标(便宜、全局)→ 定位靠追踪(哪个服务哪条链路慢/错)→ 归因靠日志(该请求的具体错误堆栈与上下文)。三者的关联键(TraceID + 时间 + 服务标签)是可观测性真正的工程难点——没有关联,三套系统只是三个孤岛。

OpenTelemetry(OTel):CNCF 的统一标准(API/SDK/OTLP 协议/Collector),目标是"一次埋点、多后端导出"(Prometheus/Jaeger/商用 APM),已成为事实标准。选型上应避免与厂商私有 SDK 深度耦合。

图示

用户请求 (TraceID=T9)
  gateway(span 2ms) ──► order-svc(span 180ms) ──► pay-svc(span 150ms)
                                  └─► inventory-svc(span 20ms)
  根因: pay-svc 内 DB 查询 140ms → 指标告警 P99↑ → 追踪定位 → 日志看慢SQL

实例或案例

  • Prometheus + Grafana + Jaeger/Tempo + Loki:云原生开源观测栈(metrics/tracing/logs 对应三件)。
  • 大促排障 SOP:P99 告警触发 → 按追踪找慢 span → 聚合日志定位 SQL/依赖 → 决定扩容或降级(kp-030)。
  • OTel 落地:Java agent 无侵入埋点 + Collector 尾部采样,错误与慢请求全保留、正常请求 1% 采样。

常见误区

  • 误区一:"接了 APM 就有可观测性"。没有统一 TraceID 关联与 SLO 语义,三套数据无法互相下钻,只是买了三套可视化。
  • 误区二:"全量采样最好"。追踪开销随流量线性增长且尾部采样存储昂贵;无采样策略的系统常在故障时因存储压力丢最需要的数据。
  • 误区三:"指标用平均值"。均值掩盖长尾(kp-002),告警与容量决策必须基于分位数直方图。

与其他知识点的关系

  • kp-002/030:分位数指标是限流熔断的输入。
  • kp-007/008:追踪上下文沿 RPC 与 MQ 透传。
  • kp-033:混沌工程验证"可观测性能否在故障时真的回答问题"。

自测题

  1. RED 与 USE 方法分别度量什么对象?

答:RED 面向服务(请求率、错误率、耗时分布),USE 面向资源(利用率、饱和度、错误)——服务与资源两层互补。

  1. 头部采样与尾部采样的取舍?

答:头部采样入口即决、成本低但固定比例可能丢掉罕见慢/错请求;尾部采样全量收集后按结果筛选,保留价值数据但收集与存储成本高。

  1. 三信号如何形成排障漏斗?

答:指标告警发现异常(what/when)→ 追踪定位链路中的慢/错环节(where)→ 关联日志归因具体原因(why),关联键是 TraceID。

延伸阅读

  • Google SRE Book 第 6 章(监控告警)与 SRE Workbook 第 5 章(SLO 燃烧率)。
  • OpenTelemetry 官方文档(traces/metrics/logs 规范)。
  • Charity Majors 等《Observability Engineering》。