5xx > 5% 持续 1m / P95 > 700ms 持续 1m → page；附版本、requestId、runbook告警盯用户能感觉的症状（错误率、延迟），用短窗 + 长窗过滤掉单次抖动；告警带版本 v1.4.2 和 requestId，接到 page 的人沿日志 30 秒定位到这次部署引入的 bug，5 分钟回滚。CPU 尖峰、磁盘 81% 只上仪表盘、不 page，半夜不会被吵。
监控仪表盘观察台：注入错误洪峰，亲手触发症状告警
监控把系统健康变成指标 + 阈值 + 告警。在这里点注入，看四个黄金信号怎么动、症状告警怎么触发、告警里的日志入口怎么连到根因——以及为什么 CPU 一次尖峰不该告警。
现实里 Prometheus 采指标、Grafana 画仪表盘、Alertmanager 发告警——这套是第 0 步。这里点注入看监控怎么把系统健康变成指标 + 阈值 + 告警：主操作「注入错误洪峰」让 5xx 跳过阈值触发告警；点告警里的「查看日志」看指标为什么动了。
错误率（Errors）0.4%告警阈值 > 5%正常
P95 延迟（Latency）220ms告警阈值 > 700ms正常
流量（Traffic）320 rps无告警阈值参考趋势
饱和度（Saturation）64%持续 > 85% 告警正常
告警卡片（FIRING / RESOLVED 保留历史）当前 FIRING：0
还没有告警。点「注入错误洪峰」或「注入延迟尖峰」看症状告警怎么触发；点「3am CPU 一次尖峰」看它为什么不告警。
最近请求（流量信号证据，按注入倒序，最多 6 条）
- 还没有样本。点任意注入按钮推进一轮采样。
原因：四个黄金信号都在带内（错误率 0.4% / P95 220ms / 饱和度 64%），没有告警。下一步：点主操作「注入错误洪峰」看症状告警怎么来；或点「3am CPU 一次尖峰」看为什么它不告警。对照：仪表盘看趋势（指标一直在动），告警负责推行动——不是每个数字动了都要 page 人。
提示：Tab 在各按钮间移动，Enter / 空格触发。重点试三组对照：点「注入错误洪峰」→ 告警 FIRING + 查看日志看根因；点「3am CPU 一次尖峰」→ 饱和瞬时 91% 但不告警（症状告警 vs 内部原因）；点「标记已恢复」→ 告警 RESOLVED 保留历史。
观察台暴露的监控规则
面板把告警的来龙去脉演给你看了，这里命名清楚，并补无法直接操作的部分。
- 盯四个黄金信号：延迟（P95）、流量（rps）、错误（5xx 率）、饱和度（CPU / 内存 / 队列长）——任何服务都先盯这四个；面板里四个仪表就是它们的具象。
- 告警盯症状，不盯原因：用户直接感受到的"错误率升 / 延迟高"才 page 人；CPU 一次尖峰、磁盘 81% 是内部原因，用户无感，只看不告警，否则告警疲劳，真出事被淹没。面板的「3am CPU 一次尖峰」就是这条的反例证明。
- 仪表盘看趋势，告警推行动：仪表盘回答"现在怎么样 / 事后复盘"，告警回答"现在就 page 谁"；面板里指标一直在动，但只有超阈值且持续才升级为 FIRING 告警。
- 告警带规则、版本、requestId：规则（"5xx > 5% 持续 1m"）说清触发条件，版本（v1.4.2）把部署列为第一嫌疑人，requestId 让你能沿日志复现这一次——面板告警卡和日志抽屉就是这条的具象。
- 多窗口防抖：「持续 1m」是短窗 + 长窗组合：短窗（如 1m）触发、长窗（如 5m）确认，避免单次尖峰抖动造成误报；面板的 CPU 尖峰不告警，就是因为它没过"持续"这关。
- SLO / 错误预算是契约：SLO（如可用率 99.5%）是服务和用户的契约；错误预算 = 100% - SLO，是"允许出错的额度"。预算内的小波动不 page，预算耗尽才升级——面板右上角的"错误预算 12%"在告急。
什么时候上监控，告警怎么取舍
从「这个服务出事时，我希望多快知道」出发，而不是把所有指标都报一遍。
- 关键路径必须监控：登录、支付、下单、注册——这些路径挂了用户立刻流失；按 5xx 率 + P95 延迟 + 可用率三个症状指标设告警，附 runbook 和回滚入口。
- 有指标再设告警：先有"在看"的指标，再谈"超阈就告"；不要凭空设一条告警规则却没人采这个指标，那样告警永远不会响，等于没设。
- 不是所有指标都要告警：CPU、内存、磁盘只看不告，除非持续超阈且会拖垮用户路径；面板的 CPU 尖峰就是"只看不告"的典型。
- 别拿监控当日志用：监控告诉你"错了多少、多慢"（聚合数字），日志告诉你"为什么错"（单次细节）；两者用 requestId 串起来，不要在仪表盘上堆每一行日志。
从一次报错到告警：最短路径
一条能 page 到人的症状告警，只走这几步。
- 在关键路径埋点采指标：按
route + method + status聚合 5xx 率和 P95 延迟，按版本和环境分维。 - 设基于 SLO 的阈值：如
5xx > 5% 持续 1m、P95 > 700ms 持续 1m；阈值来自用户能感觉到的边界，不是凭感觉。 - 用短窗 + 长窗防抖：短窗触发（敏锐）、长窗确认（稳定），避免一次抖动半夜 page 人。
- 告警带上下文：规则文案 + 当前值 + 版本 + requestId + runbook 链接；接到告警的人 30 秒内知道去哪查。
- 分 page / 工单两级：用户有感的症状 = page（半夜也叫人）；容量预警 = 工单（上班处理）。
- 恢复时标记 RESOLVED 并保留历史：告警要有进有出、可追踪，便于复盘和告警噪音治理。
同一份接口监控：5 分钟介入，还是被用户先发现
只改一处关键选择，结果差很多。这是监控设计里最该记住的一组对照。
CPU > 85% 立刻告 / 磁盘 > 80% 立刻告 / 单次慢查询立刻告 / 告警文案"服务异常"告警全盯内部原因、单次就 page：凌晨流量波动、定时任务跑批、一次冷启动都触发告警，团队在一周内被吵 40 次，全部是误报；真正接口挂时，告警淹没在噪音里没人看，用户先在群里反馈"下单失败"，团队比用户晚知道 20 分钟。
快速自测
你的服务 5xx 率从 0.4% 涨到 0.8%，但 SLO 是「5xx 低于 1%」，错误预算还剩 60%。该怎么处理？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。