最小监控：四个信号、五条探针与三分钟发现

你不需要知道一切，只需要比用户早三分钟知道。

一、故障是用户先发现的

芮宁的产品有监控面板，十几个图表，颜色齐全。某个周三早上，数据库连接池打满，登录接口开始超时。

他发现这件事的时间是九点二十三分，因为一个用户在邮件里写：「你们的登录是不是坏了？」面板上是有的，只是没有人在八点到九点二十之间看它。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

面板不等于监控。 面板回答「现在怎么样」，监控回答「什么时候该叫你」；一个人缺的通常是后者。

覆盖关键路径，不必覆盖全部。 五条探针能守住登录、首页、支付、后台任务与公开接口；第六个页面慢一点，可以等用户说。

探针要覆盖失败模式，不只覆盖页面。 首页能打开但登录后白屏，是最常见的漏网情况；每条探针都要断言一个业务结果，而不只是 HTTP 200。

二、四个信号各回答什么

信号要少，少到每周都看得完。

四个信号之外都是下钻。 内存曲线、GC 次数、慢查询榜都有用，但它们回答的是「为什么」，不是「要不要叫你」。

四个信号要有共同的时间窗。 延迟用 5 分钟、错误用 5 分钟、流量用 1 小时、饱和度用 10 分钟；窗口不一致时，同一个故障在不同图上会像两件事。

基线比阈值重要。 你的正常延迟可能是 180 毫秒，也可能是 800 毫秒；先跑两周取基线，再定倍数。

基线要按星期几分。 周一上午与周六凌晨的正常值不同；只取一个总基线，会让每周一上午都误报。

错误要按路径分。 全站 1% 的错误率可能来自一个只在夜间运行的同步任务；不分路径，告警会永远响。

饱和度看最紧的那一个。 连接池 45%、CPU 62%、存储 18% 时，真正要盯的是连接池。

三、五条探针

探针是黑盒的：从外面请求一次，看能不能拿到预期结果。

测试账号要专用。 用真实用户账号做登录探针，会在日志里留下假会话；专用账号还能顺手清理。

探针账号的权限要最小。 只读、仅登录、不触发计费；测试账号一旦有写权限，一次误跑就可能改到真实数据。

支付回调探针要带签名。 不带签名只能测到路由存在，测不到验签逻辑；这正是最容易坏的一段。

心跳表比日志可靠。 后台任务的日志可能被采样掉，心跳表每次运行写一行，读最新时间就够了。

心跳间隔要小于告警阈值。 任务每 5 分钟跑一次，心跳超过 10 分钟才算停摆；两者反了，告警会一直响。

探针本身也会坏。 探针失败时先看探针所在区域，再看产品；否则一次网络抖动会让你误判为全站故障。

五条是下限也是上限。 每多一条，每月多约 8 分钟维护；十条探针的收益通常抵不过误报。

四、发现时间与成本

监控的价值可以算成一个时间差。

探针频率 1 分钟 × 连续 2 次失败 = 发现时间 2–3 分钟
用户报告路径（本例）：平均 47 分钟才收到第一封邮件
时间差 = 47 − 3 = 44 分钟
检查量 = 5 条 × 1440 次/天 = 7200 次/天 = 216000 次/月
维护成本 = 5 条 × 8 分钟/月 = 40 分钟/月，占 4 小时预算的 17%
近 90 天 4 次故障中，2 次由用户先发现 → 约 70 分钟本可缩短

44 分钟不是小数目。 按 138 分钟总停机计，若两次用户先发现的故障各缩短 20 分钟，可用性从 99.89% 抬到 99.92%。

缩短发现时间带来的收益要按事故算。 一年 4 次事故、每次提前 20 分钟，等于多出 80 分钟可用时间；这比多买一个 9 便宜得多。

探针费用几乎可以忽略。 216000 次请求对现有免费额度通常够用；真正的成本是每月 40 分钟的维护。

发现快不等于恢复快。 探针只把 MTTD 压到三分钟，MTTR 仍取决于你的止损手册。

要有一个「探针没响但用户在用」的兜底。 每周看一次真实请求量，掉到基线一半以下就人工确认。

五、行动清单与复算验收

先建五条探针，再谈仪表盘。

• 写下四个信号的基线，标注取值窗口。
• 列出五个关键路径，各配一条黑盒探针。
• 为登录建一个专用测试账号，并写进密钥清单。
• 给支付回调探针加签名，验证验签逻辑。
• 用心跳表记录后台任务，替代日志推断。
• 设定连续 2 次失败才告警，过滤单次抖动。
• 把探针结果接到同一个通知渠道，不分散。
• 每月花 40 分钟核对探针是否仍覆盖主路径。

验收标准：你能说出上一次故障是几分钟内被探针发现的、五条探针分别覆盖哪段路径；说不出，说明你的监控还在靠用户报告。

使用边界与实操验收

本文处理的是最小监控，不涉及指标平台与分布式追踪。

分布式追踪不归本文。 一次请求跨五个服务时，追踪是必要的；一人产品通常只有两个服务。

日志不归本文。 日志回答「为什么」，下一篇文章单独处理；本文只回答「要不要叫你」。

探针不是压测。 每分钟一次的请求测不出容量，也测不出并发问题。

探针不能进生产数据。 支付探针用测试模式，公开接口探针只读；否则一次探针会被计入真实统计。

别用探针替代真实用户监控。 探针走的是固定路径，真实用户的失败可能发生在别处；两者互补，不能互相替代。

阈值要能改。 定死的阈值会随版本漂移；每季度用最近两周数据重算一次。

通知渠道要稳定。 把告警发到一个可能欠费的邮箱，是最常见的失效方式。

关键参考与核验范围

核验日期：2026-10-25。以下链接用于核对监控信号与合成检查的一般做法，本文未逐条引用其内容。

• Google SRE：监控分布式系统 ：用于核对四个黄金信号的定义。
• Google SRE Workbook：告警与值班 ：用于核对以症状而非原因告警的原则。

引用口径。 本文只借用「四个信号 + 症状告警」这一一般结构；7200、216000、47 与 40 全部是教学假设，与上述材料无关。

口径一致。 五条探针、7200 次/天与 4 小时运维预算在《可用性是一份预算》与《告警降噪》里反复出现，三篇共用同一套假设。

核验范围。 核验的是「五条探针能否覆盖一人产品的主路径」，不是比对某家监控服务的功能与价格。

如何自行复核。 关掉一次后台任务，看心跳探针几分钟内告警；若超过五分钟，先检查探针频率与判定条件。

系列导航

• 上一篇：可用性是一份预算：四个 9、停机分钟与一个人的取舍
• 下一篇：告警降噪：从 40 条到 3 条
• 回到目录：一个人的运维：可用性、告警、事故与值班
• 相关阅读：崩溃上报与版本遥测：发布后 72 小时的止损阈值