监控分布式系统：处置是机械的，它就不该叫醒人

一句话

你以为监控（monitoring）这一章教你「多收集指标」，其实它整章都在做减法：Google 明确放弃了「能自动学阈值、自动推根因」的智能监控，转而要求监控系统简单、快、可预测；把用户可感知的四个黄金信号（four golden signals）——延迟、流量、错误、饱和度——立为最小充分集；并给页面告警（page，会把人立刻叫醒的那种通知）划下一条近乎苛刻的门槛：每一次寻呼都必须紧急、可行动、且需要人的判断；只要它的处置是机械的，就该交给机器，而不是叫醒一个人。

Glossary · 术语表

坐标

作者 Rob Ewaschuk，本章脱胎于他在 Google 内部流传甚广的一篇文章《我的告警哲学》（My Philosophy on Alerting）。这是全书 Part II「原则」的收尾章：第 3 章教你用错误预算给可靠性定价、第 4 章教你把目标写成 SLO、第 5 章教你把琐务砍掉——而这一章回答「那你到底该盯什么、什么时候该叫人」。它下启 Part III 的实践篇：第 11 章的 on-call 值班、第 12 章的有效排障，都建立在「告警是干净的」这个前提上。落到现实，它对应的就是今天每个团队的 Prometheus / Grafana 面板与 PagerDuty 值班表。

这章要解决什么

「多监控点总没坏处」是行业里最贵的一句错话。一套服务能导出的指标轻易上万条，每条都能配个阈值告警，每加一条团队都觉得更安全了一点。真实结果是：值班手机一夜响十几次，其中十二次不需要任何人做任何事。三个月后，值班的人练出了「看一眼、划掉、接着睡」的肌肉记忆——那条真的告警混在里面，也被划掉了。这一章要解决的正是这个：不是「怎么监控得更多」，而是「怎么让每一次叫醒都值得」。

它同时防另一头：只在用户投诉时才知道出事（监控不足）。但书里有句很硬的判断：过度监控比监控不足更难解决——因为前者要修的是人对系统的信任，那东西建起来慢、塌下去快。书里给的人力量级也说明这活不轻：一个十来人的 SRE 团队里，通常有一两个人的时间花在建设和维护监控上。

核心内容，讲透

一、先问「为什么监控」——五类用途，只有一类配叫醒人

本章开篇把监控的用途摊开：分析长期趋势、跨时间或跨实验组比较、告警、做面板、做临时的回溯分析。五类里只有「告警」会消耗人的睡眠——这个区分是整章的地基：面板铺得再花、指标留得再多、日志存得再久，都不打扰人；但一条规则一旦接到寻呼上，它就开始花钱了，花的是值班工程师的注意力。与之配套的是一条常被忽略的原则：监控系统不该要求人去「解读」它——解读由软件做完，人只在需要采取行动时被通知。一个要人盯着面板判断「这抖动算不算事」的系统，本身就是设计失败。

二、症状还是原因：告警报「什么坏了」，面板答「为什么坏」

本章把监控要回答的问题拆成两半：症状（symptom）——什么坏了；原因（cause）——为什么坏。书里的例子很直白：症状是「我在返回 HTTP 500 和 404」，原因可能是「数据库服务器拒绝连接」；症状甚至可以是「南极洲的用户收不到动图了」，而原因是内容分发网络（CDN）把某段客户端 IP 拉黑了。

结论是告警只该报症状：症状是用户真在受的苦，而原因有一百种、且经常猜错。原因去面板和白盒指标里找——等人被症状叫来以后，用它们把原因挖出来。还有个漂亮的观察：多层系统里，一个人的症状就是另一个人的原因。「数据库变慢」对 DBA 是症状，对调它的前端服务就是原因。所以症状 / 原因不是绝对标签，而是相对于你负责的那一层。

三、黑盒与白盒：一个用来叫人，一个用来查因

白盒监控看系统内部主动暴露的东西：HTTP 处理器导出的计数器、日志、运行时统计。它的独门本事是看见「被掩盖的问题」和「即将发生的问题」——请求靠重试成功了，用户没感觉，但重试率已经翻了十倍；磁盘还没满，但按当前增速四小时后会满。

黑盒监控从外部像用户一样发请求，是症状导向的：它报的一定是此刻真的在发生的问题，而不是「可能要出事」——所以它天生适合接寻呼，一响就说明现在真有人在受苦。

Google 的取舍因此很明确：页面告警重度依赖黑盒，加上少量症状导向的白盒规则；白盒的大头拿去做面板与调试。反过来说，若你的寻呼绝大部分接的是白盒内部指标（CPU 高了、队列长了、某进程重启了），那你多半正被叫醒去处理一堆用户根本没察觉的事。

四、四个黄金信号（本章的招牌）

本章最广为流传的部分：如果你只能量四个指标，量这四个——延迟、流量、错误、饱和度。书里的承诺相当直接：把这四个都量上，并在任一个出问题（饱和度是「快出问题」）时叫人，你的服务在监控上至少算过得去了。

延迟（latency）：处理一个请求要多久。这里藏着本章最反直觉的一条：必须把成功请求与失败请求的延迟分开统计。因为一个丢了数据库连接的服务，返回 HTTP 500 是飞快的——几毫秒就能说完「我不行」。混在一起算，故障最严重的那几分钟，面板上的平均延迟反而会变好看。书里还有一句常被引用的话：慢的错误比快的错误更糟，所以失败请求的延迟也得单独盯。

流量（traffic）：用「系统正承受多少需求」度量，单位要贴着业务。Web 服务通常是每秒 HTTP 请求数，还要按性质拆开（静态资源 vs 动态接口，成本差一个量级）；音频流媒体是网络 I/O 速率或并发会话数；键值存储是每秒事务数与检索数。

错误（errors）：失败请求的比率，三种形态——显式（返回 500）、隐式（返回 200，但内容是错的）、按策略（你承诺一秒内响应，那么 1.2 秒才成功的请求按定义也算错）。隐式错误最难抓，往往要端到端校验内容才发现——而它恰恰最伤用户信任。

饱和度（saturation）：系统「有多满」，重点盯最受限的那个资源。它是四个信号里唯一带预测性的，三条要点：① 很多系统在利用率到 100% 之前就开始退化，所以要设利用率目标，别等它满；② 延迟上升往往是饱和度的先行指标——用很短的窗口（比如一分钟）看 p99 延迟，常能在资源真告急前看见苗头；③ 它还要能回答「照这个速度，你的数据库四小时后写满磁盘」这类预测。

五、尾巴与分辨率：为什么要分桶，以及采多密才划算

本章专门拎出一节讲尾部：把「平均耗时 100 毫秒」和「99% 的请求 10 毫秒、1% 的请求卡 5 秒」混为一谈，是最常犯的统计错误——平均值可能一样，用户体验天差地别。平均值是双峰分布的谎言。

对策不是多算几个百分位，而是改变采集方式：别在服务端算一个平均数报上来，要按耗时把请求分桶计数——0–10ms、10–30ms、30–100ms、100–300ms……边界大致按指数增长。这样上报的是一个分布，任何百分位都能事后算出来，多台机器的桶还能直接相加。这就是今天 Prometheus 里 histogram 的由来。

分辨率是另一场权衡：采得越密信号越全，但采集、传输、存储、查询的成本全跟着涨。本章给了很具体的量级——一个目标为 99.9% 年可用性（全年累计不可用不超过 9 小时）的 Web 服务，用黑盒探测看返回码，每分钟一到两次通常就够；查磁盘占用率，一到两分钟一次也够。再密就是白花钱。

但反过来，CPU 这类指标一分钟一个点会漏掉真相：那些持续几秒、足以把尾延迟顶上去的尖峰，在一分钟的平均里根本看不见。书里的解法很巧：内部高频采样、就地聚合，再低频上报——每秒记一次 CPU 利用率，按 5% 粒度分桶累加，每分钟把整个桶的分布报出去一次。你拿到了每秒级的分辨率，只付了每分钟一次的传输与存储成本。

六、越简单越好：给监控做减法

本章最后落在一条价值观上：监控系统要尽可能简单，但不能再简单。压力来自四面八方——想抓越来越罕见的异常、想加更多信号源、想让它自己推断根因……堆着堆着，监控系统本身就成了一个要专人维护、出事没人敢碰的复杂系统。书里的三条减法判据非常好用：

• 最常抓到真实事故的那些规则，要尽可能简单、可预测、可靠——它们是主力，不能有花活。
• 一个季度都用不到一次的采集、聚合与告警配置，应当列入删除候选——它既没在帮你，还在悄悄腐坏（没人验证过它今天还灵不灵）。
• 采了却既不上任何面板、也不被任何告警使用的信号，同样是删除候选。

这也解释了 Google 那个看似「没出息」的选择：他们刻意避开试图自动学习阈值、自动推断因果的「魔法」监控系统。理由很实在——真出事的时候，你得先调试这个魔法系统自己的判断，而事故现场没有这个时间。他们的经验是：简单、快的监控 + 好用的事后分析工具，比一个聪明但难懂的系统管用得多。

关键权衡与选型

表 1 · 黑盒 vs 白盒：什么时候用哪个

表 2 · 四个黄金信号：怎么量、量在哪、坑在哪

表 3 · 一条规则该输出到哪一档

本章还给了一份「这条告警该不该存在」的自查清单，值得贴在每个团队的墙上：

• 它检测到的，是一个否则就发现不了、且紧急、可行动、用户已经或即将感知的状况吗？
• 我会不会在某些时候明知它良性而忽略它？能不能把这种情况从规则里排除掉？
• 它是否确定意味着用户正在受影响？有没有该被过滤的例外（流量已引走的机房、测试环境的部署）？
• 收到它我能做什么？必须现在做还是可以等到早上？这动作能不能安全地自动化？
• 同一个问题是不是已经寻呼了别人？如果是，其中至少有一次是多余的。

配套的态度也很鲜明：寻呼应当紧急、重要、可行动、且需要智力参与；每次寻呼最好指向一个新问题，而不是同一个老毛病第 40 次发作。宁可失手删掉一条吵闹的告警——过度监控比监控不足更难解决。

为什么重要 / 落到真实系统

这一章的影响力大概是整本 SRE 书里最外溢的：「四个黄金信号」已经成了监控领域的通用语言。今天你打开 Grafana 的服务模板面板、Kubernetes 的默认监控、Istio 之类服务网格自动生成的指标、或 Datadog / New Relic 的服务概览页，骨架基本都是这四个信号的变体；histogram 成为 Prometheus 的一等公民，也直接源于本章「别报平均值、要报分布」的主张。它还长出两个广为流传的「方言」：RED（Rate 请求率 / Errors 错误 / Duration 耗时）是四信号在请求驱动服务上的裁剪版，砍掉了饱和度；USE（Utilization 利用率 / Saturation 饱和度 / Errors 错误）是资源侧的对偶。业界常见搭配是RED 管服务、USE 管机器，合起来正好把四个黄金信号覆盖完整。

面试里，这一章是「监控 / 可观测性」题的标准答案来源：告警该基于症状还是原因？（症状，原因有一百种且经常猜错）为什么不能只看平均延迟？（平均值是双峰分布的谎言，要看分布与尾部）成功和失败的延迟为什么要分开算？（失败返回得飞快，混在一起会让故障看起来像性能改善）——这三问答得清楚，基本就说明你读懂了这一章。

易错点与争议

• 把「四个黄金信号」读成「只需要四个指标」：它是最小充分集，不是全集。四个信号负责叫人，排障仍然需要大量白盒指标。砍到只剩四个，出事时你会瞎。
• 只用黑盒：黑盒只报「此刻真的坏了」，看不见被重试掩盖的失败，也预测不了即将到来的问题——整整一类「快出事了」的信号会被漏掉。
• 延迟统计口径混乱：失败请求混进延迟统计，会在大故障时制造「延迟改善」的假象；同理别拿多台机器的 p99 再取平均——百分位不可加，正确做法是把各机器的分桶计数相加后再算百分位（这正是上报分布而非单值的直接好处）。
• 「机械响应交给机器」有其代价：自动化掉一个创可贴确实解放了值班的人，但也可能让根因永远排不进优先级——Gmail 的 Workqueue 之争正是这个。本章诚实地把它记成短期可用性与长期可用性之间的张力，没给唯一答案。
• 时代局限（最重要的一条）：本章成书于 2016 年 Borgmon 的年代，讲的多是预先聚合的指标 + 静态阈值告警。此后两件事改变格局：一是 Google 自己用 SLO 燃尽率告警取代了大部分静态阈值（见上）；二是可观测性（observability）一派——以分布式追踪（tracing）与高基数（high-cardinality）事件为核心、以 OpenTelemetry 为事实标准——提出了对本章最有力的反方观点：预聚合的指标只能回答你事先想到要问的问题，而现代微服务的故障多是「未知的未知」，需要能事后任意切分的原始事件。本章几乎没触及跨服务归因这一整块，那正是追踪填上的空缺。
• 但要公道地说：这一章的价值观并没有过时。「告警报症状不报原因」「每次寻呼都必须值得」「监控系统本身要简单到出事时敢信它」，在指标、日志、追踪三条路上一样成立——变的是工具，不是判据。

要点