問题通常不是没有資料，而是没人去看
站点运营做久了容易有一個惯性：出問题才去翻日誌，翻完發現異常已经持續了两三周。這段時間里，蜘蛛可能早就在稳定地少抓，用戶也已经在搜尋结果里撞见過错誤頁。监控的價值不在于多装几個工具，而在于让異常在變成事故之前被看到。
從搜尋蜘蛛的角度看，站点健康其實很朴素：域名能不能稳定解析，服務器能不能在合理時間内返回正确狀態碼，返回的内容是不是目前版本。這几点只要有一項不稳，抓取量就會跟着變。下面這些信号值得日常盯住。
值得盯住的几類信号
可用性與狀態碼
- 5xx 與超时比例：偶發一两次不必紧張，持續出現就要查後端服務、資料库连接和上游接口。
- 異常 404 增長：可能是模板改版漏了連結，也可能是内容被誤删或路径被改。
- 證书與域名：證书到期、DNS 记錄被改，都會让蜘蛛连頁面都拿不到。
蜘蛛行為變化
- 抓取總量突然下降，先排除服務器變慢和 robots 規則被誤改。
- 平均响應時間變長，常见原因是慢查询、缓存失效或静態资源走了源站。
- 同一 URL 反复抓取却拿不到内容，要检查是否有拦截或渲染失敗。
服務器本身
- 磁盘空間、日誌体积、inode 數量，日誌寫满磁盘是很常见的停站原因。
- 服務器時間與时区，错位會让排查日誌變得非常痛苦。
- 备份能不能真的恢复，建议每季度實际演练一次，而不是只看备份任務成功。
告警怎么设才不吵人
告警最大的敌人是噪音。規則设得太细，一天几十條，最後没人看；设得太粗，等發現时已经影响了一段時間的抓取。几條可以參考的原則：
- 按嚴重程度分級，只有真正影响訪問的問题才走即时消息或电话。
- 加持續時間條件，例如连續几次檢測失敗才触發，避免網絡抖動誤报。
- 同一問题合並通知，恢复时也發一條，別让告警一直挂着没人收尾。
- 告警要落到具体的人，而不是一個長期没人登入的公共信箱。
把监控和日誌對照着看
监控负责回答“什么时候開始不對”，日誌负责回答“不對在哪里”。两邊對照起来，很多問题會很快定位：监控顯示某個时段响應變慢，日誌里往往能直接找到那批耗时請求的路径；抓取量下降，訪問日誌里能看到蜘蛛是减少抓取還是完全没来。建议把這两份資料放在同一個時間轴上比對，而不是分開各看各的。
几個常见誤区
- 只监控首頁。首頁正常不代表栏目頁、詳情頁正常，尤其当它們走的是不同服務时。
- 只看平均值。平均响應三百毫秒，但有一批請求在十秒以上，蜘蛛照样會受影响。
- 监控节点單一。至少要有一個站外节点，机房内部互通正常但外網不通的情况並不少见。
- 改了配置不留记錄。什么时候改的 robots、什么时候換的 CDN，出問题时全靠猜。
一份最小可用的巡检清單
- 每天看一次狀態碼分布和抓取量趋势，留意有没有突然的断层。
- 每周检查證书剩余天數、磁盘使用率、日誌清理任務是否真的执行。
- 每次發版後抽查核心栏目，確認狀態碼和内容都正常。
- 每月核對一次告警接收人，人員轉岗或离职後及时更新。
监控不是為了證明站点一直没問题，而是為了在問题刚出現时就有人知道。把它做成日常习惯，比事後一段段翻日誌省力得多。