网站可用性监控怎样做

去年秋天，网站一个电商客户在凌晨两点给我打电话，可用控样说他们的性监支付页面挂了四十分钟，损失了至少六位数。网站我打开监控后台一看，可用控样服务器响应正常，性监CDN也没报警——问题出在前端一个第三方JS库加载超时，网站而我们的可用控样监控只盯着HTTP状态码。这件事让我彻底重新思考了"网站可用性"到底该怎么定义。性监

大多数人理解的网站可用性监控，就是可用控样搞个脚本每隔几分钟curl一下首页，看返回200就万事大吉。性监这跟拿体温计判断一个人健不健康差不多——没发烧不代表没病。网站真正的可用控样可用性监控得从用户视角出发，模拟真实访问路径。性监比如一个电商网站，首页能打开但搜索挂了、搜索能用但购物车报错、购物车正常但支付跳转白屏——这些对用户来说都是"网站坏了"。

分层监控，别只盯一个点

我现在习惯把监控拆成三层来做。最底层是基础设施层，CPU、内存、磁盘IO、带宽这些，用Prometheus加Grafana或者Zabbix就能搞定，开源方案很成熟。中间层是服务层，HTTP状态码、响应时间、DNS解析、SSL证书到期时间，这块用UptimeRobot或者自建的Blackbox Exporter都行。最上层是业务层，也是最多人忽略的——模拟用户完成关键操作流程，比如登录、下单、支付。工具方面，Playwright或Puppeteer写脚本，配合定时任务跑，能抓到很多表面正常的暗病。

说个具体细节。有一次我们发现某个地区的用户投诉页面加载慢，但监控显示全国平均响应时间才300毫秒。后来把监控节点按运营商和省份拆分，才发现是某个省级DNS解析出了问题，导致那一片的用户实际加载时间超过8秒。全局平均值把问题稀释掉了。所以监控节点要分散，至少覆盖主流运营商和核心城市。

告警策略比监控本身更重要

监控系统最怕的不是漏报，是误报太多导致没人看。我见过一个团队配了三百多条告警规则，结果运维直接把告警群静音了。告警要分级：P0是核心业务不可用，打电话；P1是性能严重下降，发企业微信或钉钉；P2是次要功能异常，邮件就行。另外一定要设告警抑制和聚合，别让一个机房断电触发两百条通知。

响应时间阈值也别拍脑袋定。有人设个"超过3秒就告警"，结果业务高峰期天天报警。正确做法是先跑两周基线，取P95或P99值作为参考，再留20%余量。不同页面阈值也该不同——首页要求1.5秒内，后台报表页面5秒也能接受。

日志和链路追踪不能省

监控告诉你"出问题了"，日志和链路追踪告诉你"哪里出了问题"。ELK或者Loki做日志聚合，Jaeger或SkyWalking做分布式追踪。三者结合，排查效率完全不一样。以前排查一个接口超时，翻三台服务器日志要半小时；现在在Jaeger里点一下，直接看到是哪个微服务、哪个SQL拖慢了整条链路。

还有个小经验：合成监控和真实用户监控（RUM）要搭配用。合成监控是主动拨测，知道问题什么时候开始；RUM是在用户浏览器里埋点，知道问题影响了多少人、在什么网络环境下。两个数据对不上号的时候，往往能挖出意想不到的根因。

最后说句实在话，工具选什么不是最重要的。我见过用最简陋的shell脚本加crontab做得风生水起的团队，也见过花几十万买商业监控方案结果告警没人理的。关键是有人对"网站能不能用"这件事真正负责，愿意花时间定义什么叫"可用"，然后持续去验证它。