蜘蛛池跑起来之後，很多操作者能看到的只有「有没有抓取」這一個模糊印象。要判断池子是否健康、哪個环节出了問题，靠的是抓取日誌。日誌留得好，排查問题时能直接定位到入口頁、狀態碼和時間段；留得不好，只能凭感觉反复更換入口頁。
一、日誌里真正有用的字段
不是字段越多越好，而是每次出問题都能靠這几個字段回答「谁在什么时候請求了什么，结果如何」。
- 時間戳（带时区）：跨机房、跨区域部署时，不带时区的日誌基本没法對齐。
- 来源 IP 與 User-Agent：区分真實蜘蛛、普通訪客與掃描器的基础。
- 請求方法與完整 URL：包括路径和參數，方便判断蜘蛛走到了哪一层。
- 狀態碼與响應体大小：5xx 和零字节响應往往比 404 更值得警惕。
- 响應耗时：TTFB 突然拉長，通常先于抓取量下降出現。
- 入口頁标识：池子里有多個入口頁时，一定要能反查請求是從哪個入口頁發起的。
需要提醒的是，日誌中如果包含查询參數、Cookie 或用戶标识，落盘前應做脱敏處理，避免把無關信息長期留存。
二、儲存多久：分两层更實际
全量長期儲存成本高，也没必要。比較常见的做法是分热冷两层：
- 热資料：保留 7 到 30 天的原始日誌，用于逐條排查異常請求。
- 冷資料：按天或按周聚合成統計量，比如每日抓取次數、狀態碼占比、獨立 IP 數，長期保留。
聚合之後，即使原始日誌被清理，趋势仍然可看。
三、看趋势，而不是看某一天
單日的抓取量波動很正常，會受节假日和搜尋引擎自身調度节奏影响。真正有意义的是几周尺度的趋势：
- 抓取總量是缓慢上升、持平，還是持續下滑；
- 狀態碼分布有没有變化，5xx 比例是否抬头；
- UA 與 IP 段是否長期集中在少數几個来源；
- 蜘蛛是否只停在入口頁，很少繼續向目标頁走。
日誌的價值在于對比。孤立的一天資料几乎說明不了任何問题。
四、几個容易踩的坑
- 把總請求數当成蜘蛛抓取量，没有先做来源過滤；
- 站点前面挂了 CDN 或 WAF，源站日誌里看到的其實是中間层 IP，判断失真；
- 多套入口頁共用一份日誌，出問题时無法定位到具体是哪一套；
- 只记錄成功請求，忽略 4xx 與 5xx，導致問题被掩盖。
五、一份最小可用的记錄方案
- 在入口頁所在服務上開啟訪問日誌，關掉不必要的冗長字段；
- 落盘後按小时切分，便于快速定位到具体時間段；
- 每天跑一次聚合脚本，輸出抓取量、狀態碼分布、UA 分布三張表；
- 每周對一次趋势，發現異常时再回到原始日誌中抽样核對；
- 根據结论調整入口頁或連結结构，並把調整時間点记下来，方便下次對照。
日誌不會直接带来抓取，但它决定了你遇到問题时是盲調，還是有依據地調整。把记錄這件事做扎實，後面每一步操作都會轻松一些。