站点的抓取量出現下滑时，很多人第一反應是“蜘蛛不来抓了”，但更常见的情况是：蜘蛛還在来，只是每次請求等得太久，單位時間内能完成的抓取次數被拖了下来。服務器稳定性與抓取节奏之間是互相牵制的關系，排查时最好把两邊放到同一條時間轴上看。
先確認波動發生在哪一侧
日誌里至少有两條時間线索：請求到達的時間和响應結束的時間。如果請求間隔本身没變，但每條记錄的响應耗时明顯拉長，問题多半在站点侧；如果响應耗时正常，但同一時間窗内的請求條數變少，就要考虑抓取侧降低了對本域的抓取频次。
需要一起看的三组資料
- 按分钟聚合的請求條數，观察是否出現台阶式下降；
- 平均响應時間與 P95 响應時間，两者一起看才不會被少量慢請求誤導；
- 5xx、超时與连接中断的比例，尤其是同一時間段内是否集中出現。
把這三组資料画在同一張時間轴上，通常能直接看出是“請求少了”還是“請求變慢了”。
稳定性波動的常见来源
响應時間突然抬升，往往不是單一原因，而是几個因素叠加：
- 缓存失效或击穿：批量 URL 同时回源，資料库压力集中释放；
- 定时任務與抓取撞车：生成站点地图、跑資料統計的時間段正好赶上抓取高峰；
- 動態參數過多：篩選、排序、分頁參數让同一份内容反复生成；
- 第三方依赖拖慢：頁面渲染时同步調用外部接口，接口抖動直接传導到 HTML 輸出。
這些情况在日誌上的表現相似，都是响應時間拉長；但恢复方式不同，需要结合服務器监控和慢查询记錄進一步区分。
把日誌時間窗和服務器指标對齐
只盯着爬虫日誌，很难判断是站点變慢還是抓取變少。做法是把日誌按 5 分钟或 10 分钟分桶，同时拉取同一時間段的 CPU、内存、資料库连接數、带宽等指标，逐桶比對。
一個可操作的核對顺序
- 先定位响應時間抬升的起始分钟；
- 看该分钟是否有部署、任務或缓存刷新记錄；
- 再看 5xx 是否與慢請求同时出現，若同时出現，優先修错誤而不是調抓取；
- 最後看請求條數是否在响應恢复後才回升。
如果 5xx 和超时反复出現在同一路径上，先修這條路径，而不是先去改抓取間隔。带错誤的地址被反复請求，本身就是對抓取額度的浪費。
抓取节奏的調节思路
抓取节奏不是越慢越安全，也不是越快越好。合理的目标是让服務器在抓取高峰时仍能稳定返回 200，同时把响應時間控制在自己可以接受的范围内。
- 静態化與缓存：詳情頁、列表頁尽量走缓存，减少每次抓取都穿透到資料库；
- 收敛參數组合：對篩選、排序類參數设定取舍規則，避免大量近似 URL 被反复生成；
- 错峰执行：把批量任務、站点地图生成放到抓取低谷时段；
- 分离動静资源：图片、脚本交给 CDN，避免占用源站连接；
- 观察而非猜测：調整後繼續用同样的時間窗對比，確認响應時間與抓取條數是否同步變化。
與 URL 發現的關系
服務器長期不稳定還會間接影响 URL 發現：新地址首次被抓到时如果遇到超时，蜘蛛未必會立刻重试，發現到首抓的等待就會被拉長。因此，站点地图和内鏈里新增的入口，最好在提交後的一段時間内保證响應稳定，不要在這個窗口做大規模發布或架构調整。
小结
判断“抓取是不是被拖慢”，關键是把請求條數、响應時間和狀態碼分布放在同一個時間窗里比對。站点侧先把错誤和慢查询压下去，抓取侧再谈节奏；顺序反了，往往既没有改善抓取，也掩盖了真實的稳定性問题。