死链优化：抓取日志与应用日志时间不一致时怎样对齐事件
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a798e8577790.html
📄
死链优化：抓取日志与应用日志时间不一致时怎样对齐事件
不能直接把两份日志按时间戳并排比较。先确认两边记录的是不是同一时间含义：抓取日志常用UTC且记的是请求到达或响应完成，应用日志常用本地时区且记的是业务处理时刻。对齐的第一步是统一时区与语义，第二步是用请求ID或URL加时间窗配对，第三步才是判断某条死链的404是抓取器看到的结果还是应用侧返回的结果。
先判断两份日志的时间语义是否相同
抓取日志的一条记录通常包含请求时间、URL、状态码和抓取器标识；应用日志的一条记录通常包含处理时间、URL、响应状态和内部耗时。若抓取日志记的是响应完成时刻，而应用日志记的是请求进入时刻，两者相差一个处理耗时。此时直接按秒对齐会把同一事件拆成两条。
可执行动作：从两份日志中各取一条已知URL的记录，比较时间差是否稳定。若差值稳定且等于应用侧平均处理耗时，说明只是语义不同；若差值随机跳变，说明时区或时钟源不同。这个判断决定了下一步是改语义还是改时区。
用请求ID或URL加时间窗配对，而不是只靠时间戳
规模化后最常见的例外是同一URL在短时间内被多次抓取，而应用日志只记录一次业务处理。此时按时间戳一对一匹配会漏配或错配。更稳的做法是优先找请求ID；若两边都没有请求ID，就用URL加一个时间窗配对，窗口宽度取应用侧处理耗时的上限。
- 有请求ID：直接按ID连接，时间只用于校验顺序。
- 无请求ID：按URL分组，再在时间窗内配对，记录未配对的孤立条目。
- 配对后统计未配对比例，比例高说明窗口太窄或日志字段缺失。
假设某URL在抓取日志中出现三次，应用日志中出现一次，且应用侧处理耗时上限为两秒。把窗口设为两秒后仍有三条抓取记录无法配对，这时不应直接判定为死链，而应检查抓取器是否在重试、应用是否对同一请求合并处理。这个结果会影响下一步：先修配对规则，再谈死链判定。
区分抓取侧404与应用侧404，再决定处理顺序
对齐之后，状态码仍可能不一致。抓取侧看到404，应用侧记录200，常见原因是抓取器访问的是旧URL、CDN缓存了旧响应，或应用在抓取之后才更新了路由。反过来，应用侧记录404而抓取侧看到200，可能是抓取器命中了缓存或另一台后端。
可执行动作：对不一致的URL逐条记录抓取时间、应用处理时间、两侧状态码和中间层。若同一URL在应用侧持续返回404，而抓取侧仍返回200，应优先检查缓存与负载均衡，而不是先改站点地图。站点地图不保证收录，robots.txt的抓取限制也不等于可靠的索引移除，这两点在对齐事件时不能当作状态依据。
把对齐结果转成可复查的处理清单
对齐的目的不是让两份日志时间完全一致，而是让每条死链事件都能追溯到一次确定的请求与响应。处理清单可按以下顺序执行：
- 统一时区，标注每条记录的时间语义。
- 优先用请求ID配对，无ID时用URL加时间窗。
- 标记未配对条目，单独核查，不混入死链统计。
- 对已配对条目比较状态码，区分抓取侧与应用侧。
- 只对两侧都确认失效的URL执行死链处理。
若某段时间内抓取量或请求量归零，不能单独证明死链处理正确，也可能是抓取器调整了抓取频率、应用日志轮转或采集管道中断。需要结合配对成功率与状态码分布一起判断。
边界：个别样本成立不代表可以规模化照搬
在小样本上，按分钟对齐可能刚好够用；当URL数量上升、同一URL被多次抓取时，分钟级窗口会大量错配。此时应改用请求ID或更细的时间粒度，并接受一部分条目无法配对。无法配对的条目应进入人工核查队列，而不是自动标记为死链。对齐规则一旦改变，之前基于旧规则得出的死链比例需要重新计算，否则会把配对误差当成死链变化。
