昨天下午三点十七分，网站我的监控个人博客宕机了。不是作用被攻击，也不是网站服务器欠费，纯粹是监控数据库连接数被打满——一篇讲爬虫技术的旧文突然被某技术社区推到首页，流量瞬间冲垮了这台跑了两年多的作用低配云主机。

我是网站在五分钟后才发现的。要不是监控顺手刷了下手机上的监控推送，可能要到晚上回家打开电脑才能察觉。作用那五分钟里，网站每个访问者看到的监控都是白屏，而我一无所知。作用这让我想起去年帮朋友看的网站一个电商网站——他们的监控告警直接发到微信群，凌晨三点支付接口超时，监控运维小哥被叫醒，作用十分钟内切了备用通道。据他说，那晚要是再晚半小时发现，大促期间的损失够他半年工资。

网站监控这玩意儿，说白了就干三件事：看它死没死，看它慢没慢，看它有没有被人搞。但真做起来，细节多得让人头疼。

先说“死没死”。最粗浅的办法是定时去请求首页，看返回码是不是200。但光这样远远不够。有些页面是动态渲染的，接口挂了但外壳还在，你看着页面正常，实际用户点任何按钮都没反应。我见过一个极端案例——某新闻网站的头条区域是静态缓存，正文区走动态接口，结果接口挂了整整两天，首页看起来一切正常，点进任何文章都是404。监控脚本要是只测首页，这种事根本发现不了。所以稍微靠谱点的做法，得把关键路径上的核心接口都加进去，哪怕只是隔几分钟模拟一次用户操作。

再说“慢没慢”。响应时间比宕机更隐蔽。用户不会告诉你页面打开要六秒——他们只会默默关掉，然后去隔壁家。我自己的博客之前有个图片没做压缩，单张图两兆多，移动网络下加载要八秒。要不是监控里看到页面平均耗时飙到五秒以上，我根本意识不到问题出在图片上。压缩之后，耗时降到一秒以内，访问量反而涨了——原来之前好多用户根本没等到页面加载完就走了。

至于“被人搞”，那就更有意思了。有一次我监控到某个IP在五分钟内请求了上千次注册接口，一看就是撞库攻击。当时没当回事，结果第二天服务器CPU直接跑满，日志里全是乱码字符串的POST请求。后来加了简单的频率限制，又用监控盯了一段时间，才把这类流量挡在门外。没监控的话，你连自己是怎么死的都不知道。

不过监控也不是万能的。它最大的问题在于——你得先知道该监控什么。新手最容易犯的错是只盯着服务器CPU和内存，结果业务逻辑出了bug，服务器资源却一切正常。我犯过这个错。有一回网站的搜索功能突然返回乱码数据，监控面板上所有指标都是绿的，直到有用户发邮件来骂我才发现。后来学乖了，不光看基础设施指标，还得盯业务层面的数据——比如搜索请求的成功率、订单创建的成功率。这些指标才真正反映用户体验。

还有一点容易被忽略：监控本身也会给人安全感，而这种安全感可能是虚假的。告警阈值设得太宽，天天被垃圾告警轰炸，慢慢就没人看了；设得太窄，真出事的时候又没反应。我见过最夸张的团队，告警群里一天刷几百条消息，最后管理员把群屏蔽了——这跟没监控有什么区别？

说到底，监控的价值不在于那个面板有多炫酷，也不在于你买了多贵的监控服务。它就是个看门狗，平时不吭声，真出事的时候能及时叫醒你。而叫醒之后怎么办，那才是真正考验人的地方。