很多站点出事的时候，第一個“發現者”不是运维，也不是用戶投诉，而是搜尋引擎蜘蛛。抓取日誌里突然一片 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 和站点地图纳入探测列表；
- 每季度回顾一次告警记錄，把誤报多的阈值調一調。
這些事都不复杂，加起来一两個小时就能配好，但省下的往往是几個小时的抓取损失和一场手忙脚乱的排查。