很多站点出事的时候，第一个“发现者”不是运维，也不是用户投诉，而是搜索引擎蜘蛛。抓取日志里突然一片 5xx，过几天收录掉了一截，才回头去查，发现网站已经挂了小半天。可用性监控这件事，本质上就是把“发现问题的时刻”从故障发生几小时后，提前到几分钟内。
蜘蛛反馈太慢，不能当监控用
蜘蛛确实会持续访问你的站点，但它的访问是抽样式的、周期性的，而且反馈不会实时给到你。等它在日志里留下大量失败记录，往往意味着：
- 故障已经持续了一段时间，而不是刚刚开始；
- 抓取频率可能已经被下调，恢复后需要一段时间才回到原来水平；
- 你手上没有故障发生时刻的数据，排查只能靠猜。
所以监控要自己做，蜘蛛的日志只作为参考，不作为报警来源。
该盯住哪几类指标
基础可用性
- HTTP 状态码：重点看 5xx 和 3xx 异常跳转，4xx 突然升高也要留意。
- 响应时间：不只是平均值，更要看 P95 之类的分位值，平均值容易掩盖慢请求。
- DNS 解析：解析失败时，外部看起来就是整站不可达。
- SSL 证书到期时间：证书过期等于整站访问被拦，提前 30 天提醒比较稳妥。
与抓取相关的指标
- 抓取成功率：日志中 2xx 请求占蜘蛛总请求的比例。
- robots.txt 与站点地图：这两个地址本身也要监控，它们不可访问会直接影响蜘蛛判断。
- 重要落地页抽查：首页、主要栏目页、核心详情页各挑几个固定 URL 持续探测。
后端与依赖
页面返回 200 不代表链路健康。数据库连接、缓存服务、搜索服务、第三方接口，任何一环慢下来，前台响应时间都会跟着涨。有条件的话，把这些依赖也纳入监控项。
告警阈值怎么定
- 连续两次失败再告警，避免偶发抖动把值班的人吵醒。
- 区分地域和线路，多节点探测能快速判断是全局故障还是局部网络问题。
- 分时段设置，业务低峰期的短暂波动可以放宽一些。
- 告警要带上下文：具体 URL、状态码、响应时间、探测节点，一条说清楚，别只发一句“网站不可用”。
真出故障时，别让蜘蛛继续抓
计划内的维护或短时故障，正确做法是返回 503 状态码，并在响应头里带上 Retry-After，告诉蜘蛛多久之后再来看。这是搜索引擎明确支持的信号，通常不会因此把页面判定为失效。
需要避免的是：维护页返回 200，内容写着“系统维护中，请稍后访问”。这类页面在抓取系统看来是正常内容，反复抓到之后，正常的页面反而可能被替换掉。同样，也不要图省事直接返回 404，那等于告诉搜索引擎这些地址永久消失了。
告警之后的三件事
- 先确认影响范围：多少页面、哪些栏目、持续了多久。
- 记录时间点：故障起止时间写进日志，之后对照抓取日志看蜘蛛有没有受影响。
- 恢复后主动验证：手动请求几个关键 URL，确认状态码和内容都正常，再观察一段时间抓取量是否回升。
监控的意义不是保证不出故障，而是让故障的持续时间可控。少挂一小时，对抓取和收录的影响就小一分。
一个可以立刻执行的清单
- 给首页和 5 到 10 个核心页面配上外部探测；
- 加上证书到期、域名到期提醒；
- 确认维护页返回的是 503 而不是 200；
- 把 robots.txt 和站点地图纳入探测列表；
- 每季度回顾一次告警记录，把误报多的阈值调一调。
这些事都不复杂，加起来一两个小时就能配好，但省下的往往是几个小时的抓取损失和一场手忙脚乱的排查。