做抓取核對时，很多站点只打開一份日誌。實际记錄往往散落在三處：CDN 或邊缘节点日誌、源站 Web 服務日誌、以及搜尋平台後台的抓取統計。三者的字段、時間基准和覆盖范围都不一样，直接把數字相加或互相替代，很容易得出错誤结论。
先確認记錄有几種来源
- CDN 邊缘日誌：记錄到達邊缘节点的全部請求，包括命中缓存的請求，样本相對完整；但字段可能被裁剪，UA 或查询參數會被截断。
- 源站訪問日誌：只包含回源請求。当頁面被缓存命中时，蜘蛛的請求不會出現在這里，單看源站會明顯低估抓取量。
- 平台後台統計：通常按天或小时聚合，口径與自家日誌不同，且一般只覆盖主要搜尋蜘蛛。
时区不统一，時間窗口就對不上
源站日誌常按服務器本地時間寫入，邊缘日誌多按 UTC 记錄，第三方統計又可能按帳號設定的时区展示。差几個小时的记錄，如果直接按小时比對，同一次抓取會被拆到两個时段里，看上去像两個不同来源的訪問。
稳妥的做法是先把所有日誌统一到同一时区，再取一段连續時間做比對，比如完整的 24 小时，而不是随手抽几分钟。時間窗口太短，正常波動會被誤讀成異常。
常见字段偏差與處理
- 狀態碼：缓存命中时，邊缘节点可能直接返回自己生成的成功响應或 304，源站看到的可能是另一套结果。按狀態碼統計前，先確認這份日誌是否可以自行生成响應。
- 客戶端 IP：邊缘日誌里的地址有时是节点地址，需要看轉發字段才能還原真實来源。
- User-Agent：被截断或被统一改寫的情况不少，用 UA 做精确匹配反而會漏掉记錄，用包含匹配更稳。
- 字节數：压缩传輸、分块响應會让不同位置的字节數含义不同，只适合看趋势，不适合逐條對齐。
- 查询參數：部分日誌會丢弃參數，带參數的地址會和不带參數的记錄混在一起，統計前需要先做归一化處理。
比對方法：先匹配，再統計
- 選定時間窗口，统一时区，剔除明顯異常或明顯来自本站自身探测的记錄。
- 以 URL 路径為主键，辅以時間窗口匹配，允许几十秒到几分钟的偏差。
- 标记出只在邊缘日誌出現、源站没有的請求，這部分多數是缓存命中，属于正常現象。
- 對剩余對不上的记錄，單獨看狀態碼與响應時間，判断是抓取失敗還是记錄丢失。
抓取量的差异，很多时候不是蜘蛛少来了，而是记錄落在的位置不同。
按抓取路径分组才有判断價值
只看總量容易得出片面结论。把记錄按目錄或頁面模板分组，看哪些路径抓得多、哪些几乎没被触及。如果列表頁频繁被抓而詳情頁稀少，問题往往出在内鏈入口或站点地图的覆盖，而不是服務器响應能力。反過来，如果各路径的請求都集中在少數时段，並且伴随大量超时，那才更可能是服務器或網絡侧的問题。
核對清單
- 时区是否统一，比對窗口是否足够長。
- 每個字段的含义是否確認過，尤其是狀態碼與客戶端地址。
- 是否把缓存命中造成的记錄缺失考虑進去。
- 日誌的采样比例與保留期是否清楚，避免用不完整資料下结论。
- URL 是否先做過归一化，大小寫、尾斜杠和參數顺序是否统一。
核對的目的是让判断有依據，而不是要求两份資料完全一致。存在合理偏差是正常的，關键是能说清偏差来自哪里，再决定要不要調整入口、缓存策略或抓取节奏。