本篇要回答的问题：监控与报警是 SRE 最难工程化的事务——什么才是好的监控系统？怎样区分现象与根因、用最少监控项做最全覆盖（4 个黄金指标）、并在接警后正确地"先消除、再归因"？
承接上一讲的发布与升级。本讲指出：发布相对好工程化（只和服务调用关系有关，与业务特性弱相关），而监控与报警真正难，难在与业务高度耦合——它像私人医生，需因人而异、因地制宜。
好的监控不是"报警很多"
关键洞见：要做好监控，一定要分清"现象（Symptom）“与"原因（Root Cause）”——某监控项不正常只是现象；为什么出问题才是原因，且常只是中间原因。
监控核心解决两个问题：① 什么东西出故障了；② 为什么出故障、根因在哪。一个好监控系统的三条标准：
| 标准 | 关注点 | 含义 |
|---|---|---|
| 信噪比高 | 误报率 | 不能"看起来有点问题"就报警；否则陷入"狼来了"效应 |
| 有故障就报警 | 覆盖率 | 靠客户报障才发现，算一次监控事故 |
| 有报警就直指根因 | 有效性/排障效率 | 一个故障喷出一堆杂乱报警=无效 |
在复杂系统中，一个服务的现象可能是另一个服务的原因（数据库读慢=DB 视角的现象，却是前端"网站慢"的原因；而 DB 慢本身又只是中间原因）。
日志：监控与报警的基础
关键判断：凡是时序相关、持续产生的数据都是"日志"——不止程序日志，更多是各种系统指标采集。结构化后的日志存储本质上就是一个时序数据库。
链路：收集 → （非结构化则）文本解析结构化 → 清洗 → 分析/检索 → 数据结果 / 报表 / 触发报警。
| 用时序库做监控的好处 |
|---|
| 不依赖特定脚本判断是否正常，而用标准数据分析模型报警 |
| 批量、大规模、低成本的数据收集成为可能 |
| 历史数据都可作为报警规则的计算因素（报警规则常是简单数学表达式） |
监控指标不一定为报警，还可用于：分析长期趋势（如 DAU 增长）、跨时间/AB 比较（加节点后缓存命中率是否上升）、临时回溯分析（在线调试：延迟刚刚飙升，还有什么同时发生）。
添加监控项：4 个黄金指标
关键判断：如果只允许监控一个系统的 4 个指标，就监控这 4 个——延迟、流量、错误、饱和度。
| 黄金指标 | 含义 | 要点 |
|---|---|---|
| 延迟 | 处理请求所需时间 | 必须区分成功/失败请求；"慢"错误比"快"错误更糟，要单独监控错误回复延迟 |
| 流量 | 系统负载的度量 | Web=每秒 HTTP 请求；流媒体=网络 I/O / 并发会话；KV=每秒交易/读操作 |
| 错误 | 请求失败的数量 | 含显式（HTTP 500）、隐式（200 但内容报错）、策略性（超 1s 算失败） |
| 饱和度 | 服务容量有多"满" | 度量最受限资源；很多系统未到 100% 就性能骤降；最需要预测（如"5 小时内填满硬盘"） |
延迟增加是饱和度的前导现象——故 99% 请求延迟（小时间窗内）可作饱和度的早期预警指标。
三个进阶要点
| 要点 | 核心 |
|---|---|
| 长尾问题 | 别只看平均值；用直方图按延迟分组（边界指数型增长），区分"平均慢"与"长尾慢" |
| 合适精度 | 高精度收集成本高，可用采样+汇总（如按 5% 粒度分组、每分钟汇总）降本 |
| 加监控项最难 | 它极依赖架构能力，不是堆指标——“少就是指数级的多”，要像重构代码一样重构监控指标 |
新增报警规则前的自问清单
新增规则前应在心中回答：是否检测到目前检测不到的、紧急的、有操作性的、用户可见故障？能否被忽略/是否还有别人会收到？是否确实显示用户受影响（维护态报警是否该过滤）？收到后是否需操作、是否需立即、能否安全自动化？效果长期还是短期？背后理念：
- 每个紧急报警都应需要立即操作，每天只能进几次紧急态（否则狼来了）。
- 每个紧急报警都应可具体操作、需智力分析（只需机械动作的就该自动化）、关于新问题不彼此重叠。
接警：故障响应
关键洞见：接警第一哲学是尽快消除故障，找根因不是第一位；原因未知时尽量保留现场，方便事后做根因分析。
- 每个报警尽量代表一个清晰的故障场景→直指根因、消除更快；有清晰场景的报警都应有故障恢复预案。
- 原因不清时，消除故障最简方法是基于流量调度——把请求从故障域切走，同时保留现场。
- 根因分析两法：① 看同时间段还有哪些异常同时发生（监控够全则快速锁定"怀疑对象"）；② 分析故障请求的调用链（用 Request ID 把前后端调用串起来，抽样检索定位根源）。
七牛云的日志系统 Pandora 提供监控、报警、根因分析模块，并探索基于 AI 的智能化能力。
总结
监控与报警之难不在业务流程复杂，而在与业务高度耦合：软件重构则负载特性与性能目标随之变化，监控必须跟着演变。好监控 = 信噪比高 + 有故障就报警 + 有报警就直指根因；好 SRE 不是不停加监控项，而是不断重构指标用最少项做最全覆盖。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 现象 vs 根因 | 监控项异常是现象，"为什么"才是（中间/根本）原因 |
| 信噪比 / 狼来了 | 误报多→报警被忽略，甚至漏掉真故障 |
| 日志 | 一切时序、持续产生的数据；结构化后即时序数据库 |
| 4 个黄金指标 | 延迟、流量、错误、饱和度 |
| 饱和度 | 服务容量有多满，最需要预测；延迟是其前导现象 |
| Request ID | 串起整条调用链，做根因分析的关键 |
一句话速记
好监控不是报警多，而是"信噪比高、有故障就报、有报警就直指根因"；记不住别的就记 4 个黄金指标（延迟/流量/错误/饱和度），接警先消除故障再找根因。
几条值得记住的判断
- "慢"错误比"快"错误更糟，必须单独监控错误回复延迟。
- 延迟增加是饱和度的前导现象，可作早期预警。
- 加监控项是最难的事，极依赖架构能力——“少就是指数级的多”。
- 接警先消除、后归因，原因未知时优先用流量调度切走故障域。
思考题
照着文中"新增报警规则前的自问清单"，盘点你系统里现有的报警：有多少条其实是"看起来有点问题"型的噪声？哪些只需一个固定机械动作、本该被自动化掉？删掉它们，你的信噪比会高多少？
