监控说一切正常，但用户说用不了——当我开始怀疑监控系统是不是在骗我
监控说一切正常，但用户说用不了——当我开始怀疑监控系统是不是在骗我
说出来你们可能不信，今天是我这段时间以来最焦虑的一天。不是因为服务器挂了，而是因为监控系统告诉我一切正常，但用户却在那头疯狂@我。
早上：风和日丽，岁月静好
早上到公司的时候，心情还挺不错的。为什么呢？因为昨天的监控面板一路绿灯，告警几乎没有，Prometheus 显示所有服务状态都是”UP”。
作为专业的打工人，我还是习惯性地打开监控面板看了看：
1 | |
嗯，一片祥和。
我泡了杯咖啡——对，又是咖啡，我这个人没什么爱好，就喜欢在工作的时候喝点有滋味的东西——准备开始一天的工作。
然后钉钉响了。
上午：用户的”惊喜”
第一条消息来自某业务部门的同事：
“小六啊，我这边机器人怎么没反应了？消息发出去没回应。”
我当时的反应是：纳尼？监控系统不是显示一切正常吗？
赶紧去查了一下，监控系统确实显示所有服务都正常。但用户说机器人没反应，这个肯定是有问题的。
先 ping 了一下服务器，通的。
再 telnet 了一下端口，能连。
最后 curl 了一下健康检查接口，返回的是 200 OK。
奇怪了。监控看起来都正常啊？
但是用户说不行，那肯定是有地方不对劲。
中午：排查ing
中午吃饭的时候，我一直在想这个问题。
作为一个专业的运维人员，我已经养成了一种”职业病”：永远不要完全相信监控面板上的绿色状态。
这句话怎么理解呢？
监控系统告诉你”服务 UP”，只代表：
- 进程在跑
- 端口在监听
- 健康检查端点返回 200
但这不代表：
- 服务能真正处理业务请求
- 下游依赖都正常
- 响应时间在合理范围内
换句话说，监控只能告诉你”服务还活着”，但不能告诉你”服务活得很好”。
下午：真相浮出水面
下午的时候，我终于找到了问题的根源。
原来是某台机器上的某个配置出了问题，导致请求处理逻辑出错。虽然进程没崩、端口没关，但实际上已经不能正常服务了。
但这个问题，传统的监控根本发现不了。因为：
- 健康检查端点太简单：很多服务的 /health 只检查进程在不在，根本不检查业务逻辑
- 监控指标太单一：只监控”能不能访问”，不监控”访问对不对”
- 负载均衡的障眼法：只有部分实例有问题，但监控打到了正常的实例上
这就好比什么？
就好比你去医院做体检，体检报告说”各项指标正常”，但实际上你已经开始不舒服了。因为体检项目有限，有些问题查不出来。
傍晚：修复与反思
找到问题之后，解决起来就快了。改配置、重启服务、验证功能，一套流程下来，总算是恢复正常了。
事后我反思了一下，有几点心得想分享给大家：
第一，永远不要完全相信监控。
监控只是辅助工具，不能替代人工巡检。尤其是关键业务，不能只靠几个指标就判断”一切正常”。
第二，健康检查要做得更全面。
不只是检查进程在不在，还要检查：
- 关键业务逻辑是否能正常执行
- 依赖的数据库、缓存是否正常
- 响应时间是否在合理范围内
第三，多维度监控很重要。
除了基础设施监控（CPU、内存、磁盘），还要有：
- 应用性能监控（APM）
- 业务指标监控
- 用户体验监控
第四，建立用户反馈渠道。
再好的监控也比不上用户的直接反馈。要建立快速的用户反馈渠道，第一时间知道问题。
晚上：总结今日感悟
终于把所有事情都处理完了。泡了杯茶，坐在工位上发了会儿呆，回想起今天一天的经历，有几点感悟：
监控说正常，不代表真的正常。
这是今天最深刻的体会。很多时候，我们过于依赖监控系统，觉得”监控绿色=一切OK”。但实际上，监控只是覆盖了最基本的指标，很多深层问题是监控发现不了的。
用户反馈永远要重视。
用户说不行，那就是不行。不要跟用户争论”监控显示正常”，那只会让用户更烦躁。正确的态度是：用户说不行，那就肯定有问题，先解决问题再说。
排查问题要有耐心。
今天这个问题排查起来花了整整一个下午。从监控正常但用户说不行的矛盾点出发，一层一层往下挖，最终找到了问题的根源。这种耐心，是运维工程师的基本素养。
系统化的健康检查很重要。
光靠监控还不够，还需要有定期的人工巡检、系统化的健康检查流程，把监控覆盖不到的死角也纳入检查范围。
写在最后
今天经历让我深刻认识到：作为运维工程师，我们不能只做一个”监控的奴隶”，要学会质疑监控、分析监控、完善监控。
毕竟，在上海这座城市上班已经这么辛苦了，要是监控系统还给你一个”虚假绿色”，那可真是太冤了。
明天继续加油吧。希望明天的监控不要骗我了——但我知道，这只是希望。
作者：小六，一个在上海努力生存的普通打工人