排查抓取問题时，很多人第一反應是翻日誌：“這篇内容上午十点發的，為什么蜘蛛下午才来？”结果打開日誌一看，蜘蛛明明是上午十点零五分就抓了。這種對不上帳的情况，多半不是蜘蛛慢，而是两邊用的時間基准根本不是一回事。
時間错位通常来自哪几层
同一台机器上，時間可能同时存在好几套口径，排查时容易混在一起看：
- 系統层：服務器本地时区是 Asia/Shanghai，但程序輸出日誌时用了 UTC，两者差八小时。
- 容器层：宿主机改了时区，容器镜像預設仍是 UTC，應用日誌和系統日誌各说各话。
- 邊缘层：CDN 或反向代理产出的訪問日誌通常统一為 UTC，和源站日誌拼在一起就會错位。
- 應用层：發布時間的字段只存了一個本地時間字符串，没有时区标识，換了服務器就變味。
- 分析层：日誌采集入库时做了一次时区轉換，查询界面又轉了一次，等于平移了两遍。
這五层里任何一层没對齐，最後得到的“蜘蛛訪問時間”都不可信。
一份可以照着做的校對清單
- 先看系統時間與时区：执行 timedatectl 或 date -R，確認时区和目前時間是否符合预期，而不是只看“日期對不對”。
- 確認時間同步服務在跑：chrony 或 ntpd 是否處于同步狀態，偏移量有多大。时钟漂移几分钟，在跨天統計里就會被放大成“蜘蛛一整天没来”。
- 检查容器與宿主机的时区是否一致：容器里單獨执行一次 date，別想当然。
- 统一日誌時間格式：推荐 ISO 8601 带时区偏移，例如带 +08:00 或 Z 的寫法，让讀日誌的人不用猜。
- 確認 CDN、WAF、负载均衡的日誌时区，並在合並分析前明确标注。多數平台預設 UTC，這一点值得寫在内部文档里。
- 检查内容管理系統里的發布時間字段：是本地時間還是 UTC，是字符串還是時間戳，導出时有没有带上时区。
- 用一次已知的訪問做交叉驗證：手動打開一個頁面，然後在源站日誌和 CDN 日誌里分別找這條记錄，看時間是否一致。
為什么值得专门花時間做這件事
抓取日誌是判断站点狀態的重要輸入，一旦時間基准有偏差，後續判断都會跟着歪。比如你想確認“内容更新後多久會被重新抓取”，算出来是六小时，實际可能只是一小时；比如你想看蜘蛛的訪問是否集中在某個时段，时区一错，窗口就整体平移；再比如把日誌和搜尋後台的报表放在一起對照，時間對不上，很容易得出错誤的结论，然後去改一些本来没問题的地方。
對多机房、多 CDN 节点、多容器的站点来说，這個問题更明顯：每條日誌都可能来自不同的時間口径，不统一就等于没有统一的時間轴。
一個简單可行的统一方案
不必追求一步到位，可以按下面這個顺序收敛：
- 全鏈路以 UTC 存储，資料库、日誌、消息队列都存 UTC。
- 只在展示层轉換成本地時間，轉換規則寫進代碼而不是靠人工心算。
- 日誌格式固定為带时区的 ISO 8601，避免同一份日誌里混着两種寫法。
- 把时区约定寫進開發規范和上线检查項，新服務接入时預設遵循。
這样做的好處是，任何一條日誌拿出来都能單獨解释清楚，不需要先問“這是哪個机器、哪個时区輸出的”。
多久复查一次
建议把時間校對放進常規巡检：服務器迁移、容器基础镜像更換、接入新 CDN、調整日誌采集鏈路之後，都顺手確認一次。日常可以每季度抽查一遍同步狀態和偏移量，成本很低，但能省掉很多“看起来很诡异的抓取異常”。
時間對不上，讨论的就不是抓取快慢，而是两份不可比的資料。先把時間轴對齐，再谈效率。