站点出故障，最常见的情况不是没人修，而是没人知道。页面返回 500、证书过期、DNS 解析漂移、CDN 回源失败，这些在后台往往没有任何提示，直到某天发现蜘蛛来访量掉了一半，才回头去翻日志。把监控和告警当作日常运营的一部分，比事后抢救省力得多。
一、先明确要盯的“静默故障”
所谓静默故障，指的是不会主动报错、但已经在影响访问和抓取的问题。常见的有几类：
- 域名或 DNS 记录被误改，部分地区解析失败，其他地区一切正常
- HTTPS 证书到期或证书链不完整，访问直接报错
- 服务器磁盘写满、数据库连接数打满，页面开始零星返回 5xx
- CDN 缓存规则或回源配置调整后，部分 URL 打不开
- robots.txt 或防火墙规则误伤，蜘蛛被整段拦掉
- 站点地图地址变更后，蜘蛛取到的是旧地址或 404
这些问题共同的特点是：前台可能只是“慢了一点”或者“偶尔打不开”，但只要持续几个小时，抓取和收录就会跟着受影响。
二、监控分层：从域名到页面
基础设施层
- DNS 解析结果与 TTL 变化，最好从多个地区做解析探测
- 证书剩余有效期，提前 30 天开始提醒
- 服务器 CPU、内存、磁盘、带宽的使用曲线
- 数据库与缓存的连接状态
应用与关键页面层
- 首页、主要栏目页、几个高频落地页的 HTTP 状态码与首字节时间
- 全站 5xx 与 4xx 的比例变化
- 登录、搜索、提交表单等关键功能的可用性
抓取与发现相关
- 服务器日志中蜘蛛请求条数的日环比、周同比
- 站点地图的抓取成功率与返回码
- robots.txt 是否可正常访问，内容是否为预期版本
- 重点新发页面的首次被抓时间
抓取类指标不必精确到个位，看趋势就够。如果连续两三天蜘蛛访问量明显下滑，同时 5xx 比例上升，基本可以判断是站点侧的问题，而不是内容本身不受欢迎。
三、告警配置的几个实用原则
- 分级处理：把“整站打不开”和“某个次要页面变慢”分开，前者电话通知，后者进日报。
- 阈值别设太紧：响应时间从 800ms 变成 1.2s 不一定值得半夜叫人，连续三次失败再告警更稳。
- 设置恢复通知：知道问题什么时候结束，才能确认处理真的有效。
- 告警要带上下文：写明具体 URL、状态码、发生时间，而不是一句“站点异常”。
- 定期清理失效告警项：改版后旧监控还在跑，会制造大量噪音。
- 明确接收人和响应时间：至少准备一个备份接收人。
提醒：告警不是越多越好。如果每天收到几十条，最后的结果通常是全部标为已读。
四、异常发生后的处理顺序
- 确认影响范围：全站还是单页，单一地区还是所有地区。
- 回看最近变更：代码发布、配置调整、DNS、证书、CDN 规则，多数问题出在这里。
- 优先恢复服务，再定位原因，必要时先回滚。
- 恢复后复查抓取：观察蜘蛛日志、站点地图抓取和重点页面状态码是否回归正常。
- 记录故障处理过程，补充或调整监控项，避免同样的问题再来一次。
五、日常自查清单
- 证书、域名、服务器到期时间是否都有人盯，并且提前提醒
- 关键页面是否纳入定时拨测，覆盖多个地区
- 蜘蛛日志是否有留存，能否对比周同比与月同比
- 告警接收人、升级路径是否写进文档，而不是只存在某个人脑子里
- 近一个月是否有告警被长期忽略，原因是什么
站点监控的意义不是让运营变得紧张，而是把问题从“事后发现”提前到“刚发生就知道”。对依赖自然流量的站点来说，稳定的可访问性和持续的抓取，比任何技巧都更重要。