凌晨三点，大家的网我收到一条短信：“您的熟悉网站无法访问。”那是用性我维护了三年的一个个人博客，平时每天也就几十个访客。监控但那一刻我比收到银行扣款通知还紧张。大家的网爬起来打开电脑，熟悉发现是用性服务器硬盘满了。问题不大，监控但如果没有那条短信，大家的网我可能要到第二天上班路上才会发现。熟悉

这就是用性可用性监控最朴素的价值——它替你熬夜。

监控到底在盯什么

很多人以为网站监控就是监控“看网站能不能打开”。这个理解不算错，大家的网但太粗了。熟悉真正跑起来的用性监控系统，盯的东西细得多。

最基础的一层是端口和进程。服务器上的Nginx还在跑吗？MySQL端口通不通？这些检查一秒钟就能做一次，成本极低。再往上一层是HTTP状态码。用户访问首页，返回的是200还是502？这个区别大了。502通常意味着后端挂了，而200至少说明Web服务器还活着。

但光看状态码不够。我见过一个案例：某电商网站首页返回200，响应时间却从平时的200毫秒飙到了12秒。状态码是绿的，监控面板上一片祥和，实际上用户早就关掉页面走了。所以还得看响应时间、页面内容校验、甚至关键业务接口的返回数据是否正确。

再往深了说，还有DNS解析监控、SSL证书到期提醒、CDN节点可用性。这些东西平时没人注意，一旦出问题就是全站级别的灾难。

那些年我踩过的监控坑

刚开始做监控的时候，我设了五分钟一次的检查频率。觉得够了。后来有一次服务器磁盘IO爆了，网站卡了整整四分钟才恢复。监控确实报了警，但报警的时候故障已经快结束了。从那以后我把核心页面的检查频率调到了30秒。

频率高了，新的问题来了：误报。网络抖动一下，监控节点自己丢了个包，报警短信就来了。半夜被吵醒三次，结果网站什么事都没有。后来我学乖了，设置了重试机制——连续两次检查失败才发报警。这个简单的策略把误报率降了八成以上。

还有一个容易被忽略的点：监控节点本身的位置。如果你只在上海有一个监控节点，那上海到你的服务器网络正常，不代表广州用户访问也正常。跨地域的监控节点部署，能帮你发现区域性的网络问题。我之前有个客户，华北用户访问正常，华南用户却经常超时，查了半天是某个中间运营商节点的问题。单节点监控根本发现不了。

工具的选择没那么重要

市面上监控工具一大堆。UptimeRobot、Pingdom、阿里云监控、自建的Zabbix和Prometheus。选哪个？我的看法是：先用起来再说。

个人项目用UptimeRobot免费版就够了，五分钟检查一次，支持HTTP和ping。企业级的话，Prometheus加Grafana组合灵活度高，但维护成本也不低。国内的话阿里云监控和腾讯云监控跟自家基础设施集成得好，省心。

关键不是工具多高级，而是你有没有认真对待报警。我见过太多团队装了监控，报警邮件发到一个人邮箱里，那个人休假了，网站挂了三天没人知道。监控的价值不在于面板多好看，而在于报警能不能触达该触达的人，以及收到报警的人会不会真的去处理。

监控之外的事

说到底，可用性监控是个兜底手段。它不能防止故障发生，只能让你更快知道故障发生了。真正要提高可用性，还得从架构上做冗余、做限流、做降级。监控是最后一道防线，不是第一道。

但话说回来，没有这道防线，你连自己网站什么时候挂的都不知道。那才是最可怕的。