站点出问题的时候，第一个知道的往往不是站长，而是访客或者抓取程序。一次数据库连接异常、一次证书过期、一次磁盘写满，可能几小时后才在后台留言里被提醒。站点健康监控的意义不是追求零故障，而是把发现故障的时间缩短，让排查有据可依。
先想清楚要监控哪些指标
监控不是装个探针就完事，先列清楚哪些异常会影响访客和抓取，再决定监控方式。
- 可用性：首页和几个关键栏目页能否正常返回 200，是否存在间歇性 502、504。
- 响应时间：首字节时间与整页加载时间的历史基线，超过基线多少算异常，要有曲线可对比。
- 证书与域名：HTTPS 证书到期时间、域名到期时间、DNS 解析是否正常。
- 服务器资源：磁盘剩余空间、内存、CPU 负载、数据库连接数与慢查询。
- 抓取侧信号：蜘蛛访问量突然归零或暴增、大量 5xx 返回、robots 文件被改动。
- 业务侧信号：表单提交失败、站内搜索无结果、留言量异常下滑。
指标不需要一口气做全，先把「挂了能立刻知道」这一层做扎实，再逐步补充。
阈值和告警分级，比监控本身更重要
告警太敏感，最后所有人都会把它当成噪音划掉；太迟钝，又失去了意义。比较实际的做法是分两到三级。
- 紧急：站点不可访问、证书已过期、数据库无法连接，直接电话或即时通讯找值班人。
- 重要：响应时间持续超过阈值、磁盘剩余空间低于 10%、抓取量异常波动。
- 提示：证书还有 15 天到期、备份任务延迟、个别内页返回 4xx。
阈值不要拍脑袋定。先观察一到两周的正常波动范围，把阈值设在正常值之上一点，减少误报。同时给同类告警做聚合，避免一次故障刷出几十条重复消息。
告警发出去之后，得有人接
- 明确第一响应人，以及联系不上时的第二顺位。
- 告警渠道至少保留两个，避免单一渠道故障导致全部静默。
- 记录每次告警的处理过程，形成简短的事后记录，方便复盘同类问题。
- 定期做一次演练式告警测试，确认接收端真的能收到。
很多团队不是没有监控，而是监控发到了没人看的群，或者告警邮箱早就不再登录。
一次可以照着做的自查
- 列出对访客影响最大的 3 到 5 个页面，作为可用性探测目标。
- 确认探测节点位置，尽量覆盖主要访问来源地区，不要只从本地探测。
- 检查证书与域名到期时间，把提醒设在到期前 30 天和 15 天。
- 配置磁盘、内存、数据库连接数的阈值告警。
- 把站点地图和几个重要 URL 加入定时检查，返回码异常时通知。
- 确认告警接收人是在职人员，离职账号及时移除。
- 每月回看一次告警记录，统计误报比例，调整阈值。
容易忽略的几个细节
- 监控页面本身被缓存，内容更新后仍返回旧版本，被误判为正常。
- 只监控首页，栏目页和内页挂掉很久都没人发现。
- 用搜索结果判断站点状态，滞后且不准确。
- 服务器日志没有留存或轮转策略，出问题后无据可查。
监控和告警做得再细致，也不能保证站点永不出问题，但能让你在问题扩大之前先动手。把它当成日常运营的一部分，比出事后熬夜排查要省力得多。