用户已经投诉了监控为什么还是一片绿客服群里已经出现多条投诉提交订单一直转圈。值班同学打开监控却发现CPU、内存、健康检查和平均响应时间全是绿色。十几分钟后网关超时才终于触发告警。这不是监控没有采集数据。真正的问题是我们监控了机器是否正常却没有监控用户正在经历什么。一、故障现场所有组件都说自己没问题事故期间各层给出的结论是KubernetesPod Ready Spring Boothealth UP CPU38% 内存62% 平均响应时间120ms 数据库可连接 Redis可连接但订单提交接口的数据是P5090ms P994.2s 网关504持续增加 部分地区成功率93%用户投诉比告警早了17分钟。我们没有缺少监控而是犯了四个典型错误。二、错误1健康检查只证明进程能回答健康检查通常访问一个轻量端点/actuator/health它返回200只能说明这个端点当前可以响应以及被纳入检查的组件状态满足条件。它不能自动证明用户真实入口可达 网关路由正确 关键业务可以完成 尾延迟符合SLO 跨地区网络正常如果健康检查不访问订单真实路径就发现不了订单接口里的连接池等待。健康检查用于判断实例是否可接流量黑盒业务探测用于判断用户旅程是否真的可用两者不能互相替代。三、错误2平均值把少量严重故障抹平了总体平均响应时间只有120ms是因为大多数查询接口仍然很快。真正异常的是低流量但非常关键的订单提交查询接口90%的流量平均70ms 订单提交3%的流量P99 4.2s所有接口聚合后订单故障几乎看不见。告警必须按用户价值划分服务而不是把所有接口平均在一起。至少把这些路径单独观察登录 下单 支付 回调 核心查询 后台任务四、错误3只告警原因没有告警症状原来的告警几乎全是资源阈值CPU 80% 堆内存 85% 磁盘 90% 连接数 90%这些指标适合排查原因却不一定代表用户已经受损。这次事故中应用线程大量等待下游CPU反而不高。资源告警全部保持绿色用户请求却已经超时。Prometheus官方告警实践建议在线服务优先从靠近用户的高延迟和错误率等症状告警并让仪表盘帮助定位原因。可以把告警分成两层需要叫醒人的症状告警核心接口成功率低于SLO P99超过用户可接受阈值 黑盒业务探测失败 订单或支付成功量异常下降用于排查和提前治理的原因告警CPU和内存接近容量 线程池、连接池饱和 Redis延迟上升 数据库锁等待 磁盘空间下降原因告警可以进入工单或仪表盘不必每一条都半夜叫醒人。五、错误4告警等待时间比故障本身还长原告警规则要求条件持续15分钟才触发for:15m设置for是为了过滤短暂抖动方向没有错。问题是我们没有根据业务恢复目标设计等待时间。对支付接口来说连续15分钟超时已经太久。更合理的方式是分级短窗口快速发现明显故障 长窗口发现持续偏离SLO 不同严重程度发送不同通知阈值和窗口必须通过真实流量、错误预算和误报成本验证不能从别的系统复制一个5m或15m就直接上线。六、正确的监控顺序先从用户往里看我通常按这个顺序搭建线上监控。第1层用户结果核心业务成功率 真实请求P95/P99 订单、支付等业务结果 外部黑盒探测第2层入口和应用网关状态码 QPS Tomcat活跃线程 线程池队列 实例和版本分布第3层依赖数据库连接等待和慢查询 Redis延迟和超时 HTTP下游P99 消息积压 DNS和网络第4层资源CPU 内存 GC 磁盘 文件描述符 网络重传告警从第1层发现用户影响排查时再逐层向里定位。七、黑盒探测不能只请求首页真正有价值的黑盒探测应该模拟最小业务路径例如访问网关域名 → 调用公开测试接口 → 验证响应码 → 验证关键字段 → 记录总耗时对于登录、下单等有副作用的流程可以使用专用测试账号、沙箱数据或无副作用的业务探针。同时限制探测频率避免它本身产生业务数据、触发风控或造成费用。黑盒探测必须从服务外部执行。只在同一集群内部探测可能发现不了公网DNS、证书、CDN和边缘网关问题。八、别忘了监控“监控系统”还有一种最危险的绿色监控已经停止采集但仪表盘还显示最后一次正常数据。至少检查Prometheus抓取是否成功 规则评估是否运行 Alertmanager是否可用 通知渠道是否送达 采集数据是否新鲜可以定期发送一条端到端测试告警验证规则触发 → Alertmanager处理 → 企业微信/短信/电话送达 → 值班人员确认Prometheus也建议对监控和告警基础设施做元监控并用外部黑盒作为补充。九、一条告警至少应该告诉值班人员什么不要只发送HighLatency一条可行动的告警至少包含哪个服务、接口和环境 当前值与阈值 持续了多久 影响范围 仪表盘链接 日志或Trace入口 处理手册 最近发布信息值班人员不应该在凌晨两点先花十分钟猜“这是哪个集群”。十、这次事故最终怎么改我们做了五项调整为下单和支付建立独立成功率、P95和P99从集群外增加最小业务黑盒探测将核心接口错误率和尾延迟设为症状告警将线程池、连接池和资源指标作为原因面板增加告警链路的端到端自检调整后我们在下一次下游抖动发生后两分钟内收到告警比客服反馈早了九分钟。这才是监控真正应该提供的价值不是证明机器还活着而是在用户大面积受损前告诉你哪里出了问题。十一、告警体系自查清单是否监控核心业务成功率而不只是HTTP 200是否按关键接口查看P95/P99是否有集群外黑盒探测是否区分症状告警和原因告警告警阈值是否来自SLO和真实基线for持续时间是否符合业务恢复目标是否避免把低流量关键接口淹没在聚合指标里告警是否包含仪表盘、日志和处理手册是否监控采集、规则和通知链路本身是否定期演练告警能够真正送达写在最后用户已经投诉监控却还是绿色通常不是因为“没有监控”。而是监控回答错了问题。机器CPU是否正常、进程是否存活当然重要。但真正应该最先回答的是用户现在还能不能完成关键操作这是「性能排障周」第6篇也是本周收尾篇归入「生产环境保命清单」。如果你们的告警仍然以CPU、内存为主可以把这篇发给负责监控平台的同事一起补上用户视角。你遇到过用户先于监控发现故障吗当时漏掉的是尾延迟、业务指标、黑盒探测还是告警通知链路欢迎在留言区说说。系列导航上一篇《别再只盯慢SQL100ms的SQL也能把连接池排满》本周合集回复关键词保命获取完整文章入口关注公众我回复关键词保命获取完整「生产环境保命清单」。