凌晨三点，一个电商网站的下单接口突然变慢。表面只是"慢了一点"，但背后这一次下单，可能穿过了几十个互相调用的微服务、几个数据库、一个消息队列和两个外部支付接口。问题出在哪一环？在单台服务器的年代，工程师登录机器看看日志就行。在今天这种分布式系统里，"看看日志"几乎等于在一座迷宫里找一根针。
可观测性（Observability），就是为了在这种迷宫里依然能搞清楚"系统现在到底发生了什么"而发展出的一整套思想和工具。
破除误解：可观测性不只是"监控的新名字"
很多人以为"可观测性"只是市场部门给"监控"换的时髦说法。两者确实相关，但侧重点不同。
一个常被引用的区分来自工程师 Charity Majors：监控回答你已经知道要问的问题，可观测性让你能问出你事先没想到要问的问题。 监控是预先设好一批指标和告警（CPU 超过 80% 就报警），它擅长发现"已知的故障模式"。但分布式系统的多数严重事故是"未知的未知"——一种你从没预想过的组合情形。可观测性追求的，是让系统的内部状态足够透明，以至于你能在事后、用当时没预设的角度去追问、去切片、去定位根因。
借用控制论的说法：可观测性衡量的是"能否仅凭系统的外部输出，推断出其内部状态"。系统埋下的数据越丰富、越结构化，它就越"可观测"。
三类信号：日志、指标、追踪
可观测性的数据通常被分成三类（业界常称"三大支柱"，但这个说法有争议，见后文）：
日志（Logs）：一条条带时间戳的离散事件记录——"在 12:03:07，用户 42 的支付请求返回了错误码 500"。日志信息最丰富、最具体，但量极大，且非结构化的纯文本日志很难大规模查询。现代做法是用"结构化日志"（每条日志是一个带字段的 JSON，而非一句话），以便机器检索。
指标（Metrics）：对某类事件随时间聚合后的数值——"过去一分钟，下单接口的 P99 延迟是 850 毫秒""当前每秒请求数是 1200"。指标占用空间小、便于绘制趋势图和设置告警，但它是聚合的，丢失了单次请求的细节：你知道"整体变慢了"，却不知道"是哪一类请求慢了"。
追踪（Traces）：这是分布式系统的关键武器。一次用户请求在穿过几十个服务时，每一跳都打上同一个"追踪 ID"，并记录各自的耗时与上下游关系。Google 2010 年的内部系统 Dapper 是大规模分布式追踪的开创者，奠定了这一领域的基本范式。Dapper 论文报告，生产集群每天产生超过 1 TB 的采样追踪数据，默认采样率约 1/1024——即便如此，数据量仍惊人，说明全量追踪在规模上的不可能性。
SLI、SLO 与 SLA：从数据到决策
Google SRE（Site Reliability Engineering）团队把可观测性数据组织成一套目标语言（Beyer et al., 2016）：
- SLI（Service Level Indicator，服务级别指标）：一个可测量的服务质量指标，如"请求延迟 < 200ms 的比例"。
- SLO（Service Level Objective，服务级别目标）：SLI 的目标值，如"99.9% 的请求在 200ms 内返回"。
- SLA（Service Level Agreement，服务级别协议）：SLO 的合同化版本，违约可能有赔偿。
这套框架的意义在于：可观测性不是"收集一切数据"，而是为已定义的目标收集证据。没有 SLO，仪表盘只是漂亮的噪声；有了 SLO，告警才有意义——"我们偏离了对用户承诺的目标"而非"CPU 高了 5%"。
eBPF：内核级可观测性
传统监控依赖在应用里埋点——改代码、发版、承担性能开销。eBPF（extended Berkeley Packet Filter，Linux 内核 4.x 起成熟）允许在内核中安全运行沙箱程序，无需修改应用代码即可采集网络、系统调用、函数延迟等数据。Cilium、Pixie、Parca 等工具用 eBPF 实现零侵入追踪，正在改变"可观测性必须侵入业务代码"的默认假设。这与 Charity Majors 强调的"高基数、任意切片"方向一致——内核级数据天然带有进程、容器、网络五元组等丰富维度。
为什么"三支柱"说法有人反对
把可观测性简单等于"日志 + 指标 + 追踪"听起来很整齐，但 Charity Majors 等实践者批评这种框架是误导：它把三类数据当成三个孤立的工具孤岛，而真正的可观测性需要的是能跨这三者自由钻取、按任意维度切片的高基数（high-cardinality）数据。
举个例子：如果你只能按"接口名称"聚合指标，你永远查不出"问题只发生在某个特定用户、用某个特定 App 版本、在某个特定地区时"。而真正有用的根因往往就藏在这种细粒度组合里。所以这些批评者更愿意把日志/指标/追踪称为可观测性的"信号（signals）"而非"支柱（pillars）"——"支柱"是营销词，"信号"才是技术词。这个争论本身反映了一个更深的分歧：可观测性的核心，究竟是"收集三种数据"，还是"具备任意提问的能力"？
OpenTelemetry：统一的标准
历史上，每家监控厂商都有自己的数据格式和埋点方式，换一个工具就要把代码里所有埋点重写一遍——这是巨大的锁定成本。2019 年，两个开源项目 OpenTracing 与 OpenCensus 合并为 OpenTelemetry（OTel），目标是提供一套厂商中立的标准：用统一的 API 在代码里产生指标、日志、追踪，再导出到任意后端。如今 OTel 已成为该领域事实上的标准，大幅降低了"想换分析工具就得重写埋点"的负担。
代价与争议
成本与采样：全量记录每一次请求的追踪数据，开销可能高得离谱（存储、网络、计算）。Dapper 论文估计，若对每次请求做全量追踪，存储与网络开销可能使集群成本增加 数个数量级。于是必须"采样"——只记录一部分请求。但采样带来两难：随机采样可能恰好漏掉那个出错的请求；而"尾部采样"（只保留出错或慢的请求）又需要先把全部数据缓存一段时间才能决定保留谁。如何在成本与覆盖之间取舍，没有标准答案。
可观测性不等于理解：海量的仪表盘和告警，可能制造一种"我们看得很清楚"的错觉，实则淹没在噪声里。著名的"告警疲劳"——值班工程师被太多无关紧要的告警轰炸，最终对真正重要的告警也麻木了——是运维领域反复出现的失败模式。Google SRE 手册建议：每个 on-call 轮值周期， actionable 告警应控制在每天个位数——超过此阈值，说明 SLO 定义或告警规则需要重新设计。数据多，不等于洞察多。
隐私与合规：日志和追踪里常常无意中记录了敏感信息（用户邮箱、令牌、身份证号）。可观测性系统因此成了数据泄露的高风险地带，需要专门的脱敏与访问控制。GDPR 与《个人信息保护法》对日志保留期限、跨境传输的限制，正迫使企业重新设计可观测性架构——"能记录一切"与"合法记录"之间的张力日益尖锐。
典型故障排查流程
一次真实的生产事故，可观测性数据如何串联？假设下单接口 P99 延迟从 200ms 飙到 3s：
- 指标告警触发——SLO 违反，on-call 工程师被唤醒。
- 查看 Dashboard，发现延迟集中在
payment-service，而非cart-service。 - 打开 Trace 查询，过滤
duration > 2s AND service=payment-service，找到慢请求的 trace ID。 - 沿 trace 查看 span 瀑布图，发现
call-external-gateway这一跳耗时 2.8s——根因是外部支付网关超时。 - 切换到 Logs，用 trace ID 关联，看到网关返回
503 Service Unavailable与上游超时日志。 - 确认根因后，触发熔断或切换备用网关——MTTR（Mean Time To Recovery）取决于上述链条有多顺畅。
没有追踪，步骤 3–4 不可能在分钟级完成——工程师只能逐台机器 grep 日志，在分布式系统中近乎大海捞针。
可观测性成熟度模型
Google SRE 与 CNCF 社区归纳出可观测性实践的成熟度阶梯：
| 阶段 | 特征 | 典型问题 |
|---|---|---|
| 0 — 监控 | 预设指标 + 阈值告警 | 告警风暴、未知故障模式 |
| 1 — 可观测 | 三信号统一 + 关联查询 | 数据孤岛、高基数受限 |
| 2 — 分析驱动 | SLO + 错误预算 + 事后复盘 | 缺乏业务上下文 |
| 3 — 预测性 | 异常检测 + 自动根因 | 模型误报、成本失控 |
大多数团队停在 0–1 之间——不是工具不够，而是组织流程（on-call 轮值、事后复盘 blameless postmortem、错误预算文化）未跟上。
与 DevOps / SRE 的关系
可观测性不是运维部门的私产。DevOps 强调"你构建，你运行"（You build it, you run it）——开发团队必须能读懂自己服务的 traces 和 metrics，否则把可观测性丢给运维就是制造瓶颈。SRE 则把可观测性作为可靠性工程的输入：SLO 定义目标，错误预算（error budget）决定"可以发布多快"——预算耗尽则冻结功能发布、专注稳定性。
主流工具生态
| 类型 | 代表工具 | 特点 |
|---|---|---|
| 指标 | Prometheus + Grafana | 拉模型、PromQL、开源标准 |
| 追踪 | Jaeger, Zipkin, Tempo | OpenTelemetry 兼容 |
| 日志 | Loki, ELK Stack | 标签索引 vs 全文搜索 |
| 统一 | Datadog, Honeycomb, New Relic | 商业 SaaS、高基数分析 |
Honeycomb 和 Lightstep（现 ServiceNow）代表 Charity Majors 路线——强调高基数查询（按任意字段切片），而非预聚合仪表盘。这与 Prometheus 的"先聚合再查询"哲学形成对照。
生产事故的文化维度
Google SRE 强调 blameless postmortem（无责复盘）：事故后追问"系统为何允许这发生"，而非"谁犯了错"。可观测性数据是复盘的证据基础——没有 trace ID 关联的日志，复盘会退化为互相指责。可观测性因此不仅是技术，更是组织学习的基础设施。
小结：从数据到洞察
可观测性的目标不是"监控一切"，而是在未知故障发生时仍能提问。日志给细节，指标给趋势，追踪给因果链——三者关联，才构成现代分布式系统的"神经系统"。OpenTelemetry 的统一、SLO 的目标语言、eBPF 的内核透视，都在降低"问出正确问题"的成本。但工具永远代替不了文化：无责复盘、错误预算、合理的 on-call 轮换，才是让数据变成洞察的最后一步。
跨域连接
- 控制论：能观性问的是能否由输出唯一确定内部状态。这给出一条可操作的判据：如果两种故障假设产生完全相同的外部输出，再多仪表盘也分辨不出它们。于是工程的第一步不是加指标，而是设计出能区分候选假设的输出——而采样与预聚合恰恰在削弱这种可分辨性，它们的代价必须按此衡量。
- 贝叶斯定理：告警疲劳有精确的解释。真故障的基础率很低，即使检测规则的误报率不高，告警中真故障所占比例仍然很低，值班者据此学到的最优反应就是忽略。推论与直觉相反：恢复信任最有效的手段是减少告警数量、提高每条的先验相关性，而不是继续提高检测灵敏度。
- 流行病学：尾部采样只保留出错或缓慢的请求，这在结构上就是病例对照抽样——抓罕见事件极其高效，但由此估计的总体比率必然有偏。推论是采样策略决定了哪些统计量还能被无偏还原，因此必须在建仪表盘之前定下来；事后想从只留了病例的样本里算出发生率，是无解的。
- 过程安全：化工的安全管理早已把追问从「谁按错了钮」改成「系统为何允许它发生」，并用近失事件报告维持前置指标。理由是硬的：事故稀少，只统计事故次数的组织会长期收不到信号。可观测性数据的价值同样在于提供比事故更密集的前置量，而无责复盘是让这些数据能被如实上报的制度前提。
- 分布式系统：跨服务的因果链只能靠显式传播的追踪上下文重建，因为分布式系统没有全局时钟，机器间的时钟偏差常常大于单跳耗时。推论直接可测：按日志时间戳排序会给出错误的先后关系，而且错得没有规律。谁调用了谁必须由链路上下文或逻辑时钟承载，任何断链都会让这段因果永久丢失。
OpenTelemetry 实践要点 用 OTel SDK 在代码中创建 span，propagate trace context（W3C traceparent header）跨服务边界。 Metrics 用 histogram 记录延迟分布，而非仅 average——P99 藏在 histogram 里。 Logs 必须结构化（JSON），并注入 trace_id 字段以便与 span 关联。
阅读建议 Google Dapper 论文 (2010)——分布式追踪的开山之作。 Majors et al. (2022) Observability Engineering——实践派系统阐述。 Google SRE Book 第 6 章——监控分布式系统。
成本治理 可观测性 SaaS 账单常随 log volume 线性增长——**采样**、**TTL 压缩**、**聚合降采样**是 FinOps 必备技能。 **Cardinality explosion**：高基数 label（如 user_id）使 Prometheus 存储爆炸——需 relabel 丢弃或 aggregate at ingest。
分布式追踪上下文传播 W3C Trace Context 标准定义 traceparent/tracestate headers——跨 HTTP/gRPC/message queue 必须一致 propagate。 Broken trace（链路断裂）通常因某服务未 forward header——是 onboarding 新服务的最 common 故障。
可观测性反模式
Dashboard 堆砌：数十个 panel 无人看——应围绕 SLO 组织，而非 metric 可得性。 Alert on every error：1% 错误率 on 1M QPS = 10k errors/min，若全告警则 fatigue。 Log everything forever：成本与 GDPR Retention 双重压力——需 tiered storage 与 sampling policy。
成本治理
SaaS 账单随 log volume 线性增长——采样、TTL、聚合降采样是 FinOps 必备。Cardinality explosion（如 user_id label）可使 Prometheus 存储爆炸，需 relabel 或 ingest 端 aggregate。
进一步思考
成熟度标志：未知故障时能否用 trace 串起因果链、用 SLO 量化 user impact、用 blameless postmortem 防复发——而非 dashboard 数量。
W3C Trace Context
traceparent header 必须跨 HTTP/gRPC/queue 一致 propagate——broken trace 是 onboarding 新服务最常见故障之一。
错误预算与发布节奏
Google SRE 的 error budget 把 SLO 违反额度量化为可消耗预算：若 30 天 SLO 为 99.9%，则约 43 分钟 downtime 或等价错误预算是"可接受"的。预算耗尽时，团队应冻结功能发布、专注稳定性——把可观测性数据直接接入组织决策，而非只供事后 grep。
Blameless postmortem 模板通常要求：时间线（用 trace ID 串联）、根因（系统允许什么发生）、行动项（防复发）。没有 trace-log 关联，复盘退化为"谁点了 deploy"——可观测性因此是 DevOps 文化的硬基础设施，而非运维私产。
Honeycomb 与 Lightstep 路线强调高基数查询——按 userid、appversion、region 任意切片，而非预聚合仪表盘；Prometheus 的"先聚合再查询"哲学在 cardinality 受限时更安全，但可能漏掉细粒度根因——工具选择即哲学选择。
参考文献
- Sigelman, B. H. et al. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Technical Report (2010).
- OpenTelemetry Authors. OpenTelemetry Specification. Cloud Native Computing Foundation (持续更新；opentelemetry.io）.
- Majors, C., Fong-Jones, L. & Miranda, G. Observability Engineering. O'Reilly (2022).
- Beyer, B. et al. (eds.) Site Reliability Engineering: How Google Runs Production Systems. O'Reilly (2016).
延伸阅读
- Beyer, B. et al. (eds.) Site Reliability Engineering: How Google Runs Production Systems. O'Reilly (2016).
- Majors, C. charity.wtf（关于"可观测性 vs. 监控"的系列博客，观点鲜明）.