开源web网站监控平台

去年冬天，开源控平我负责运维的站监一个小型电商网站半夜挂了。不是开源控平服务器宕机，也不是站监数据库锁死，而是开源控平首页的某个JavaScript文件被CDN缓存了一个损坏的版本，导致所有用户看到白屏。站监问题从发生到被用户投诉，开源控平中间隔了整整47分钟。站监那47分钟里，开源控平我手机上的站监监控工具——一个商业SaaS服务——只发了一条“响应时间正常”的邮件。它没告诉我页面根本渲染不出来。开源控平

这件事之后，站监我开始认真折腾开源监控方案。开源控平商业监控工具通常盯着服务器CPU、站监内存、开源控平HTTP状态码这些指标，但用户真正看到的东西，它们往往测不到。开源社区里有一批项目专门解决这个问题，而且思路跟商业产品很不一样。

Uptime Kuma算是我第一个上手的。它用Node.js写的，部署起来就一条Docker命令。界面干净得不像开源项目，添加监控项时支持HTTP(s)、TCP、Ping、DNS甚至Steam游戏服务器。我拿它监控了12个站点，包括那个电商首页。它有个功能叫“关键词监控”——你可以指定页面里必须出现某个字符串，比如“立即购买”或者“库存充足”。如果返回的HTML里没有这个词，立刻报警。这比单纯看状态码200有用多了。不过Uptime Kuma的告警渠道虽然多（Telegram、Slack、邮件、Webhook），但历史数据只保留180天，对我这种喜欢翻旧账的人来说有点不够。

后来我换到了Uptime Kuma + Prometheus + Grafana的组合。Prometheus负责抓取指标，Grafana画图。但Prometheus原生不支持HTTP探测里的内容校验，得靠Blackbox Exporter。Blackbox Exporter的配置写起来有点绕，YAML里要定义prober、module、timeout，还得处理TLS证书过期。我花了两个晚上才让一个带Basic Auth的页面监控跑通。好处是数据永久保留，而且Grafana的告警规则可以写得很细——比如“连续3次探测失败且响应体长度小于500字节”才触发，避免网络抖动误报。

如果你更关心真实用户视角的性能，Sitespeed.io值得一试。它基于Browsertime，能调用真实Chrome或Firefox加载页面，然后输出Core Web Vitals、资源瀑布图、甚至视频录像。我拿它跑过那个电商首页，发现某个第三方统计脚本阻塞了渲染整整2.3秒。Sitespeed.io的缺点是资源消耗大，一个测试实例至少吃2GB内存，不适合放在小VPS上长期跑。我的做法是每天凌晨用GitHub Actions触发一次，结果推到S3，再用Grafana读S3里的JSON。

还有一个冷门但好用的：Statping。它跟Uptime Kuma定位类似，但支持多用户和OAuth登录，适合团队用。不过它的前端是Vue 2写的，移动端适配一般。我最后没选它，因为它的通知模板自定义程度不如Uptime Kuma灵活。

折腾一圈下来，我的建议是：个人项目或者小团队，直接上Uptime Kuma，十分钟就能跑起来，关键词监控能覆盖80%的“页面白屏但状态码200”场景。需要长期数据分析和复杂告警，再考虑Prometheus那套。别指望一个工具解决所有问题——我现在的方案是Uptime Kuma做实时告警，Sitespeed.io每天跑一次深度体检，两者结果都推到钉钉机器人。那个电商网站后来再没出现过半夜白屏没人知道的情况。

开源监控工具的通病是文档零散，很多配置得翻GitHub Issues。但好处也明显：数据在自己手里，想怎么改就怎么改。上周我给Uptime Kuma加了个自定义Webhook，把告警信息转发到公司内部的一个聊天机器人，改代码加重启只花了15分钟。商业工具提工单等回复的时间都不止这个数。