蜘蛛和访客遇到的第一道门槛不是内容质量，而是服务器能不能正常返回页面。一次持续几小时的故障，可能正好覆盖蜘蛛的抓取窗口；等你在日志里看到成片的 5xx，损失已经发生。可用性监控的作用，是把这个问题从「事后从日志里发现」提前到「发生几分钟内就知道」。
先明确要监控哪些地址
监控不是把全站 URL 都加一遍，那只会制造噪声。挑几个有代表性的：
- 首页，以及两到三个主要栏目入口页
- 更新最频繁或与转化直接相关的页面
- robots.txt 和站点地图文件
- 静态资源所在的域名或 CDN 地址
- 关键子域各自一条，不要用主域代替
只监控首页是常见的偷懒做法。首页正常、某个栏目路径因为规则或配置错误持续 500，同样会让蜘蛛在那一块反复碰壁，而这种问题往往几周都不会被访客反馈上来。
状态码之外还要看什么
200 不代表页面就是对的。监控项可以按下面几类来铺：
- 响应时间：不必追求毫秒级，重点看趋势，明显偏离基线数倍就值得看一眼
- 证书与域名到期：TLS 证书、域名本身都设提前提醒，别等到当天
- 解析结果：确认返回的 IP 在预期范围内，迁移或切换服务商后尤其重要
- 内容长度或特征串：防止错误页以 200 状态返回，或页面被降级成空白模板
这几项不必全部自动化，但至少要有一两项能兜住「返回码正常、内容不对」的情况。
抓取侧往往更早给出信号
访客分散在各个时段，一小时的异常可能感觉不到；蜘蛛的抓取更集中，失败率的变化通常更敏感。可以留意：
- 站点地图里的 URL 最近一次抓取时间是否长期不动
- 抓取统计中服务器错误的比例有没有抬头
- 服务器日志中蜘蛛请求的返回码分布是否偏离平时
这几个指标出现异常时，先当作可用性问题查一遍，通常比逐个页面找原因更快。
阈值怎么定更实用
- 连续两次检测失败再告警，避免瞬时抖动刷屏
- 核心页面与非核心页面分开设阈值，不要让低频页面的波动淹没关键告警
- 把告警分级：核心页不可访问立即通知，其余延迟汇总成一条
- 维护窗口提前配置静默，省得每次发布都被叫醒
告警要落到具体的人
只发到一个邮箱，等于把风险押在一个人是否在看手机上。比较稳妥的做法是：值班轮换、超时升级，严重问题走电话或短信，一般问题走群消息。告警内容里带上 URL、状态码、检测节点和时间，能省掉第一轮来回确认。
收到告警后的排查顺序
- 从外部多个节点手动访问，先排除监控节点自身的网络问题
- 查看服务器负载、进程状态、磁盘空间和连接数
- 回忆最近是否有发布、配置变更、解析或证书操作
- 确认是否被限流或安全策略拦截，避免把正常抓取当成攻击
- 恢复后回看抓取是否同步恢复，必要时重新提交站点地图
把顺序固定下来，值班的人不需要临场想先看哪里。
常见误报来源
- 监控节点所在网络或线路故障
- CDN 局部边缘节点异常，源站其实正常
- 健康检查路径本身被访问规则挡住
- 计划内维护没有同步到监控配置
监控的价值不在于告警条数，而在于让问题在蜘蛛和访客之前被发现。告警太吵和没有告警，效果差不多。
可用性没有做完的一天。隔一段时间回看告警记录，把重复出现的类型变成固定检查项，把一直没响过的监控项重新确认真实有效，比不断堆新的监控指标更有意义。