问题通常不是没有数据，而是没人去看
站点运营做久了容易有一个惯性：出问题才去翻日志，翻完发现异常已经持续了两三周。这段时间里，蜘蛛可能早就在稳定地少抓，用户也已经在搜索结果里撞见过错误页。监控的价值不在于多装几个工具，而在于让异常在变成事故之前被看到。
从搜索蜘蛛的角度看，站点健康其实很朴素：域名能不能稳定解析，服务器能不能在合理时间内返回正确状态码，返回的内容是不是当前版本。这几点只要有一项不稳，抓取量就会跟着变。下面这些信号值得日常盯住。
值得盯住的几类信号
可用性与状态码
- 5xx 与超时比例：偶发一两次不必紧张，持续出现就要查后端服务、数据库连接和上游接口。
- 异常 404 增长：可能是模板改版漏了链接，也可能是内容被误删或路径被改。
- 证书与域名：证书到期、DNS 记录被改，都会让蜘蛛连页面都拿不到。
蜘蛛行为变化
- 抓取总量突然下降，先排除服务器变慢和 robots 规则被误改。
- 平均响应时间变长，常见原因是慢查询、缓存失效或静态资源走了源站。
- 同一 URL 反复抓取却拿不到内容，要检查是否有拦截或渲染失败。
服务器本身
- 磁盘空间、日志体积、inode 数量，日志写满磁盘是很常见的停站原因。
- 服务器时间与时区，错位会让排查日志变得非常痛苦。
- 备份能不能真的恢复，建议每季度实际演练一次，而不是只看备份任务成功。
告警怎么设才不吵人
告警最大的敌人是噪音。规则设得太细，一天几十条，最后没人看；设得太粗，等发现时已经影响了一段时间的抓取。几条可以参考的原则：
- 按严重程度分级，只有真正影响访问的问题才走即时消息或电话。
- 加持续时间条件，例如连续几次检测失败才触发，避免网络抖动误报。
- 同一问题合并通知，恢复时也发一条，别让告警一直挂着没人收尾。
- 告警要落到具体的人，而不是一个长期没人登录的公共邮箱。
把监控和日志对照着看
监控负责回答“什么时候开始不对”，日志负责回答“不对在哪里”。两边对照起来，很多问题会很快定位：监控显示某个时段响应变慢，日志里往往能直接找到那批耗时请求的路径；抓取量下降，访问日志里能看到蜘蛛是减少抓取还是完全没来。建议把这两份数据放在同一个时间轴上比对，而不是分开各看各的。
几个常见误区
- 只监控首页。首页正常不代表栏目页、详情页正常，尤其当它们走的是不同服务时。
- 只看平均值。平均响应三百毫秒，但有一批请求在十秒以上，蜘蛛照样会受影响。
- 监控节点单一。至少要有一个站外节点，机房内部互通正常但外网不通的情况并不少见。
- 改了配置不留记录。什么时候改的 robots、什么时候换的 CDN，出问题时全靠猜。
一份最小可用的巡检清单
- 每天看一次状态码分布和抓取量趋势，留意有没有突然的断层。
- 每周检查证书剩余天数、磁盘使用率、日志清理任务是否真的执行。
- 每次发版后抽查核心栏目，确认状态码和内容都正常。
- 每月核对一次告警接收人，人员转岗或离职后及时更新。
监控不是为了证明站点一直没问题，而是为了在问题刚出现时就有人知道。把它做成日常习惯，比事后一段段翻日志省力得多。