蜘蛛和訪客遇到的第一道门槛不是内容质量，而是服務器能不能正常返回頁面。一次持續几小时的故障，可能正好覆盖蜘蛛的抓取窗口；等你在日誌里看到成片的 5xx，损失已经發生。可用性监控的作用，是把這個問题從「事後從日誌里發現」提前到「發生几分钟内就知道」。

先明确要监控哪些地址

监控不是把全站 URL 都加一遍，那只會制造噪声。挑几個有代表性的：

• 首頁，以及两到三個主要栏目入口頁
• 更新最频繁或與轉化直接相關的頁面
• robots.txt 和站点地图文件
• 静態资源所在的域名或 CDN 地址
• 關键子域各自一條，不要用主域代替

只监控首頁是常见的偷懒做法。首頁正常、某個栏目路径因為規則或配置错誤持續 500，同样會让蜘蛛在那一块反复碰壁，而這種問题往往几周都不會被訪客反馈上来。

狀態碼之外還要看什么

200 不代表頁面就是對的。监控項可以按下面几類来铺：

• 响應時間：不必追求毫秒級，重点看趋势，明顯偏离基线數倍就值得看一眼
• 證书與域名到期：TLS 證书、域名本身都设提前提醒，別等到当天
• 解析结果：確認返回的 IP 在预期范围内，迁移或切換服務商後尤其重要
• 内容長度或特征串：防止错誤頁以 200 狀態返回，或頁面被降級成空白模板

這几項不必全部自動化，但至少要有一两項能兜住「返回碼正常、内容不對」的情况。

抓取侧往往更早给出信号

訪客分散在各個时段，一小时的異常可能感觉不到；蜘蛛的抓取更集中，失敗率的變化通常更敏感。可以留意：

• 站点地图里的 URL 最近一次抓取時間是否長期不動
• 抓取統計中服務器错誤的比例有没有抬头
• 服務器日誌中蜘蛛請求的返回碼分布是否偏离平时

這几個指标出現異常时，先当作可用性問题查一遍，通常比逐個頁面找原因更快。

阈值怎么定更實用

1. 连續两次檢測失敗再告警，避免瞬时抖動刷屏
2. 核心頁面與非核心頁面分開设阈值，不要让低频頁面的波動淹没關键告警
3. 把告警分級：核心頁不可訪問立即通知，其余延迟匯總成一條
4. 维護窗口提前配置静默，省得每次發布都被叫醒

告警要落到具体的人

只發到一個信箱，等于把風險押在一個人是否在看手机上。比較稳妥的做法是：值班轮換、超时升級，嚴重問题走电话或短信，一般問题走群消息。告警内容里带上 URL、狀態碼、檢測节点和時間，能省掉第一轮来回確認。

收到告警後的排查顺序

1. 從外部多個节点手動訪問，先排除监控节点自身的網絡問题
2. 查看服務器负载、進程狀態、磁盘空間和连接數
3. 回忆最近是否有發布、配置變更、解析或證书操作
4. 確認是否被限流或安全策略拦截，避免把正常抓取当成攻击
5. 恢复後回看抓取是否同步恢复，必要时重新提交站点地图

把顺序固定下来，值班的人不需要临场想先看哪里。

常见誤报来源

• 监控节点所在網絡或线路故障
• CDN 局部邊缘节点異常，源站其實正常
• 健康检查路径本身被訪問規則挡住
• 計划内维護没有同步到监控配置

监控的價值不在于告警條數，而在于让問题在蜘蛛和訪客之前被發現。告警太吵和没有告警，效果差不多。

可用性没有做完的一天。隔一段時間回看告警记錄，把重复出現的類型變成固定检查項，把一直没响過的监控項重新確認真實有效，比不断堆新的监控指标更有意义。