# 为什么需要可观测性 · 从「监控」到「自证」

> 可观测性和监控不是同义词。这一章讲清两者的分野——监控回答「你预先想到要问的问题」，可观测性回答「你没想到的问题」，以及为什么分布式系统把后者从奢侈品变成了必需品。

- 作者：David（道雾轩）
- 专栏：指标采集与观测（https://daiw.org/manual/observability.md）
- 最后更新：2026-07-15
- 原文：https://daiw.org/manual/observability/why-observability
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# 为什么需要可观测性 · 从「监控」到「自证」

“可观测性”（Observability）这个词这几年被用滥了，很多人把它当成“监控”的时髦说法。但两者有**真实且重要**的区别——搞清楚这个区别，是理解后面所有技术选择的前提。

## 监控 vs 可观测性：已知的未知 vs 未知的未知

<Callout type="info">
  **监控（Monitoring）回答的是“**你预先想到要问的问题**”；可观测性（Observability）回答的是“**你没想到的问题**”。**

  - **监控** —— 你**事先知道**要盯什么：CPU 超过 80% 告警、磁盘满了告警、错误率超阈值告警。你列出一张“可能出问题的清单”，挨个装上探针。这对付的是**已知的未知**（known unknowns）——你知道 CPU 可能会高，只是不知道何时。
  - **可观测性** —— 系统吐出**足够丰富**的数据，让你能在事后**提出当初没想到的问题**并得到回答：“为什么**只有**华东区、**只有**安卓端、**只有**下单接口、**只在**昨晚 8 点那一刻变慢？”这对付的是**未知的未知**（unknown unknowns）——你事先根本不可能把这个组合列进清单。

  一句话：**监控是“检查清单”，可观测性是“提问能力”**。监控告诉你“出事了”，可观测性告诉你“为什么出事”。
</Callout>

这个区别不是文字游戏。它决定了你**采集什么数据**：监控思维下，你只存“CPU 使用率”这一个数；可观测性思维下，你存的是**带维度的数据**（哪台机器、哪个服务、哪个版本、哪个区域），因为你不知道未来会想按哪个维度切。这就是为什么 [Prometheus 的数据模型](https://daiw.org/manual/observability/data-journey)是“**指标名 + 一堆标签**”而不是一个孤零零的数字——**标签就是你未来提问的自由度**。

## 为什么现在才成为必需品

单体应用时代，出问题就上机器 `tail -f` 日志、`gdb` 挂上去，基本够用。分布式系统把这套彻底废掉了：

<Callout type="warn">
  **分布式系统让传统调试手段集体失效——这才是可观测性从“奢侈品”变成“必需品”的根本原因。**

  - **没有“那台机器”** —— 一个请求穿过网关、鉴权、订单、库存、支付十几个服务，分布在几百个容器上，容器还随时被调度走。你 `tail` 哪一台？
  - **问题不可复现** —— 故障常源于**特定的时序、特定的并发、特定的数据组合**。“昨晚 8 点那 3 秒” 不会以同样方式重来，断点调试无从下手。
  - **故障是涌现的** —— 每个服务的指标都“正常”，但组合起来系统就是慢。根因可能是某个服务的重试放大了下游压力——**没有任何单点数据能显示这一点**，只有把数据关联起来才看得见。

  于是唯一的出路是：**让系统在运行时主动吐出足够的数据**，事后无需复现就能重建现场。这不是给系统“加个功能”，而是把“可被理解”当成系统的**一等设计目标**。
</Callout>

读过本站 [WebRTC 专栏第 11 部分](https://daiw.org/manual/webrtc/observability-overview)的话，你会发现这个逻辑一模一样：WebRTC 的 bug [在别人的网络里、无法复现、跨十几个子系统](https://daiw.org/manual/webrtc/observability-overview)，所以它必须内建 [getStats 和 RtcEventLog](https://daiw.org/manual/webrtc/rtc-event-log)。**任何跑在你控制不了的环境里的复杂系统，最终都会长出自己的可观测性体系**——只是形态不同。

## 一个具体的例子

抽象说不清，来个具体的。假设你的下单接口 P99 延迟从 200ms 涨到 2s：

```mermaid
flowchart TD
    ALERT["告警:下单 P99 = 2s"] --> Q1{"监控能答的"}
    Q1 --> A1["确实变慢了<br/>(仅此而已)"]
    ALERT --> Q2{"可观测性能答的"}
    Q2 --> B1["按服务切:哪一跳慢?<br/>→ 库存服务"]
    B1 --> B2["按实例切:全部还是个别?<br/>→ 只有 3 个 pod"]
    B2 --> B3["这 3 个有何不同?<br/>→ 都在 node-7"]
    B3 --> B4["node-7 怎么了?<br/>→ 磁盘 IO 饱和"]
    style A1 fill:#ef4444,color:#fff
    style B4 fill:#22c55e,color:#fff
```

监控只能告诉你**第一格**：“慢了”。而可观测性让你能一路**按任意维度追问下去**，直到找到“node-7 磁盘 IO 饱和”这个根因。注意这条追问链上的每一步，**都是你事先没写进任何告警规则的问题**——你不可能预先想到“如果 node-7 的磁盘满了，下单会慢”。**这就是可观测性的价值：保留提问的自由度。**

## 代价不是免费的

必须说清另一面：可观测性**不便宜**。

- **性能代价** —— 埋点要占 CPU、内存、网络。高频路径上加一个指标，可能就影响吞吐。
- **存储代价** —— 维度越多，数据量**指数级**膨胀。这就是[第 8 部分要专门讲的“基数爆炸”](https://daiw.org/manual/observability/why-observability)——可观测性的头号杀手，很多团队的监控账单比业务服务器还贵。
- **认知代价** —— 数据太多、面板太杂，反而没人看得懂，告警多到全员免疫。

所以整个可观测性工程，本质是在**“看得见” vs “付得起”** 之间反复权衡。你在后面会一次次看到这个矛盾：[采样](https://daiw.org/manual/observability/three-pillars)为什么存在、[直方图](https://daiw.org/manual/observability/three-pillars)为什么只存桶而不存每个值、[Prometheus 为什么不存原始日志](https://daiw.org/manual/observability/three-pillars)——答案都指向这条轴。

## 小结与下一章

**监控**回答[你预先想到的问题](https://daiw.org/manual/observability/why-observability)（已知的未知），**可观测性**回答[你没想到的问题](https://daiw.org/manual/observability/why-observability)（未知的未知）——前者是检查清单，后者是提问能力。这个区别决定了要采集**带维度的数据**（[标签 = 未来提问的自由度](https://daiw.org/manual/observability/data-journey)）。它从奢侈品变成必需品，是因为[分布式系统废掉了传统调试](https://daiw.org/manual/observability/why-observability)（没有“那台机器”、不可复现、故障是涌现的），只能让系统**自证**。但它有[性能 / 存储 / 认知三重代价](https://daiw.org/manual/observability/why-observability)，整个工程都在“看得见 vs 付得起”间权衡。

那么，系统到底该吐出**什么样**的数据？业界的答案是“三大支柱”。下一章看它们各自回答什么问题。👉 [三大支柱：Metrics、Logs、Traces](https://daiw.org/manual/observability/three-pillars)。

## 参考资料

- [1] Charity Majors 等《Observability Engineering》（可观测性 vs 监控的经典论述）。
- [2] Google《SRE Book》第 6 章 Monitoring Distributed Systems。
- [3] 关联[本站 WebRTC 专栏的可观测性部分](https://daiw.org/manual/webrtc/observability-overview)（同一逻辑的另一个领域样本）。