做抓取核对时，很多站点只打开一份日志。实际记录往往散落在三处：CDN 或边缘节点日志、源站 Web 服务日志、以及搜索平台后台的抓取统计。三者的字段、时间基准和覆盖范围都不一样，直接把数字相加或互相替代，很容易得出错误结论。
先确认记录有几种来源
- CDN 边缘日志：记录到达边缘节点的全部请求，包括命中缓存的请求，样本相对完整；但字段可能被裁剪，UA 或查询参数会被截断。
- 源站访问日志：只包含回源请求。当页面被缓存命中时，蜘蛛的请求不会出现在这里，单看源站会明显低估抓取量。
- 平台后台统计：通常按天或小时聚合，口径与自家日志不同，且一般只覆盖主要搜索蜘蛛。
时区不统一，时间窗口就对不上
源站日志常按服务器本地时间写入，边缘日志多按 UTC 记录，第三方统计又可能按账号设置的时区展示。差几个小时的记录，如果直接按小时比对，同一次抓取会被拆到两个时段里，看上去像两个不同来源的访问。
稳妥的做法是先把所有日志统一到同一时区，再取一段连续时间做比对，比如完整的 24 小时，而不是随手抽几分钟。时间窗口太短，正常波动会被误读成异常。
常见字段偏差与处理
- 状态码：缓存命中时，边缘节点可能直接返回自己生成的成功响应或 304，源站看到的可能是另一套结果。按状态码统计前，先确认这份日志是否可以自行生成响应。
- 客户端 IP：边缘日志里的地址有时是节点地址，需要看转发字段才能还原真实来源。
- User-Agent：被截断或被统一改写的情况不少，用 UA 做精确匹配反而会漏掉记录，用包含匹配更稳。
- 字节数：压缩传输、分块响应会让不同位置的字节数含义不同，只适合看趋势，不适合逐条对齐。
- 查询参数：部分日志会丢弃参数，带参数的地址会和不带参数的记录混在一起，统计前需要先做归一化处理。
比对方法：先匹配，再统计
- 选定时间窗口，统一时区，剔除明显异常或明显来自本站自身探测的记录。
- 以 URL 路径为主键，辅以时间窗口匹配，允许几十秒到几分钟的偏差。
- 标记出只在边缘日志出现、源站没有的请求，这部分多数是缓存命中，属于正常现象。
- 对剩余对不上的记录，单独看状态码与响应时间，判断是抓取失败还是记录丢失。
抓取量的差异，很多时候不是蜘蛛少来了，而是记录落在的位置不同。
按抓取路径分组才有判断价值
只看总量容易得出片面结论。把记录按目录或页面模板分组，看哪些路径抓得多、哪些几乎没被触及。如果列表页频繁被抓而详情页稀少，问题往往出在内链入口或站点地图的覆盖，而不是服务器响应能力。反过来，如果各路径的请求都集中在少数时段，并且伴随大量超时，那才更可能是服务器或网络侧的问题。
核对清单
- 时区是否统一，比对窗口是否足够长。
- 每个字段的含义是否确认过，尤其是状态码与客户端地址。
- 是否把缓存命中造成的记录缺失考虑进去。
- 日志的采样比例与保留期是否清楚，避免用不完整数据下结论。
- URL 是否先做过归一化，大小写、尾斜杠和参数顺序是否统一。
核对的目的是让判断有依据，而不是要求两份数据完全一致。存在合理偏差是正常的，关键是能说清偏差来自哪里，再决定要不要调整入口、缓存策略或抓取节奏。