為什么值得單獨查一遍可用性监控
大部分站点都装了监控，但很多监控只做一件事：每隔几分钟請求一次首頁，看到 200 就認為一切正常。這種配置能發現整站挂掉，却很难發現“首頁正常、栏目頁 500”“图片服務器不可用”“證书過期半天没人管”這類問题。對搜尋蜘蛛来说，這些局部故障同样會打断抓取。
一、频率和超时是否匹配站点規模
間隔太長，故障可能持續几十分钟才被發現；間隔太短，又會對服務器造成額外压力，尤其是低配机器和抓取高峰重叠时。可以按重要性分級：首頁與核心栏目頁 1 到 3 分钟一次，普通内容頁 5 到 10 分钟一次。超时阈值不要设得比正常响應還紧張，否則會出現大量“假宕机”。建议按正常首字节時間的 3 到 5 倍来设。
二、別只看狀態碼，要校驗内容特征
返回 200 不代表頁面正常。常见的坑包括：
- 頁面狀態碼 200，正文却寫着“資料库连接失敗”；
- 被 CDN 或 WAF 拦下，返回一張人机驗證頁；
- 模板改版後，關键区块没有渲染出来。
做法是在监控里加一段關键字校驗，例如检查頁面中是否出現固定的标题、版本号，或正文長度是否大于某個阈值。關键字要選那種基本不會出現在错誤頁上的内容。
三、探测点與线路差异
單点探测只代表那一條线路。如果站点用了 CDN 或有多线机房，建议至少配置两個不同地域的探测点。有些異常只在特定区域或特定运营商出現，本地反复測試都是正常的，很容易誤判成誤报。
四、把證书、DNS、域名有效期一起纳入
這几項属于“定时炸彈”型問题，平时看不出異常，到期当天直接全站不可訪問。监控項至少應包含：HTTPS 證书剩余天數，提前 30 天和 14 天两級提醒；域名到期時間；DNS 解析结果是否與预期 IP 一致。解析被誤改導致的跳轉異常，往往比服務器宕机更难排查。
五、告警要送到有人看的地方
告警發到没人查看的信箱，等于没有监控。检查几点：告警通道是否包含即时通讯或短信；是否有明确的接收人；夜間與节假日如何處理；同一故障是否會被反复轰炸，有没有收敛和静默規則。
六、恢复通知與事後记錄
告警容易做，恢复通知经常被忽略。站長需要知道“什么时候恢复的”，否則會重复排查。另外每次故障建议简單记一行：時間、現象、受影响頁面、處理動作。积累几個月後往往會看出規律，比如總是某台机器磁盘寫满，或者總是在备份任務執行时全站變慢。
一份可执行的自查清單
- 首頁、栏目頁、内容頁、站内搜尋頁都有监控覆盖；
- 监控包含内容校驗，而不只是狀態碼；
- 至少两個不同地域的探测点；
- 證书、DNS、域名到期都有獨立提醒；
- 告警有明确接收人和值班约定；
- 有恢复通知，並有简單的故障记錄习惯。
监控的目标不是“装一個工具”，而是让故障從“用戶先發現”變成“自己先發現”。频率、内容校驗、告警去向這三件事做到位，多數低級故障就能在影响抓取之前被處理掉。