很多站点运营者會看蜘蛛日誌，却很少检查日誌本身是否“活得够久”。等到某天抓取量骤降、某個栏目突然不被訪問，想回看一周前的记錄时，才發現日誌已经被轮轉覆盖，或者压缩包缺了几天。没有连續日誌，排查抓取異常、URL 發現和服務器波動都會變得很被動。
日誌轮轉與保留不是运维的邊角料，它直接决定你能否還原“蜘蛛在什么时候、以什么方式訪問了哪些地址”。下面按自查顺序梳理常见問题。
一、先確認日誌有没有在正常寫入
排查前先看最基础的一点：Web 服務器或反向代理是否還在记錄訪問日誌。常见情况是：
- Nginx/Apache 的 access log 被關閉，或者只记錄了错誤日誌；
- 站点套了 CDN 後，源站日誌只看到 CDN 回源 IP，真實蜘蛛 IP 在 CDN 日誌里；
- 容器化部署後，日誌寫到了容器内部，容器重啟就丢失；
- 多台服務器各自记日誌，但没有集中收集，查問题时只看了其中一台。
如果日誌源头就不完整，後面的轮轉和保留做得再好也没有意义。建议先確認：至少有一份包含 時間、客戶端 IP、請求方法、URL、狀態碼、User-Agent、响應大小 的记錄，並且能覆盖全站入口。
二、轮轉周期：別让單文件無限增長，也別切得太碎
日誌轮轉通常按天或按大小触發。按天轮轉比較适合站点运营排查，因為蜘蛛抓取、收錄變化、服務器異常往往以天為單位观察。如果按大小切，流量一波動就可能一天切出很多文件，分析时反而麻烦。
需要自查的点：
- 轮轉是否在每天固定時間执行，避免跨天文件混在一起；
- 轮轉後是否通知服務重新打開日誌文件，否則可能繼續寫舊句柄；
- 是否保留了轮轉前後的對應關系，例如 access.log 與 access.log.1 的時間邊界；
- 错誤日誌和訪問日誌是否分開轮轉，避免一個把另一個挤掉。
排查抓取異常时，最怕的不是日誌多，而是日誌時間段對不上。轮轉時間不固定，分析工具會把两天的資料算成一天。
三、保留天數：至少覆盖一個完整的观察周期
保留多久没有统一答案，但可以按站点更新频率和排查需求来定。如果栏目每周更新，保留 7 天只能看到最近一轮；如果遇到抓取骤降、改版、迁移，往往需要對比改版前後至少 14 到 30 天的資料。
- 日訪問量不大的站点：保留 30 到 90 天压缩日誌，成本通常可接受；
- 訪問量較大的站点：可以保留 7 到 14 天原始日誌，再保留更長時間的聚合統計；
- 涉及服務器迁移、URL 調整、robots 修改的节点：建议單獨归档，不要只依赖自動轮轉；
- 合規要求較高的业務：按實际要求延長，並注意脱敏。
關键是：当你想回看“上周三蜘蛛到底抓了什么”时，日誌還在。
四、压缩與归档：別把日誌存成打不開的碎片
很多服務器會啟用压缩轮轉，這本身没問题，但常见坑是：
- 压缩文件命名没有日期，過一段時間分不清哪份是哪天；
- 只保留最近几個压缩包，舊的被自動刪除；
- 归档到對象存储或备份盘时中断，文件不完整；
- 權限設定過嚴，运营人員無法讀取，排查时還要找运维；
- 磁盘寫满後日誌停止寫入，却没有告警。
建议给日誌文件一個清晰命名，例如包含站点标识、日誌類型和日期；归档後抽检能否正常解压和搜尋。如果使用日誌分析工具，還要確認采集端能识別轮轉後的新文件，不會重复采集或漏采。
五、字段與格式：至少能区分蜘蛛和普通用戶
日誌字段决定了你能回答哪些問题。如果 User-Agent 被截断、真實 IP 被代理覆盖、狀態碼缺失，後續分析會很吃力。自查时關注：
- 是否记錄了完整 User-Agent，能识別常见蜘蛛标识；
- 如果套了 CDN 或负载均衡，是否通過 X-Forwarded-For 等字段保留了真實客戶端 IP，並做了可信代理配置；
- 是否记錄請求時間（含时区），避免和服務器时区不一致；
- 是否记錄响應時間，便于判断抓取时服務器是否過慢；
- 静態资源和動態頁面的日誌是否可区分，方便排除图片、CSS 等干扰。
這一步和 URL 發現、抓取预算分析直接相關。日誌字段不全，你可能會把 CDN 回源請求誤判成蜘蛛抓取，也可能漏掉真正重要的頁面訪問。
六、權限、安全與告警
日誌里可能包含 URL 參數、搜尋词、内部路径等信息，開放讀取前要评估范围。运营需要看抓取資料时，可以给只讀帳號或導出分析结果，而不是直接共享服務器 root 權限。同时建议設定：
- 磁盘使用率告警，避免日誌寫满導致服務異常；
- 日誌轮轉失敗告警；
- 關键時間段日誌缺失告警；
- 归档任務失敗告警。
這些告警不需要很复杂，但能避免“問题發生时才發現没有日誌”。
七、把日誌检查纳入日常运营
可以每月做一次简單自查：随机抽取三天的日誌，確認能查到蜘蛛訪問、狀態碼分布和重点 URL 抓取情况；检查压缩包是否完整；核對保留天數是否符合目前需求。若近期有改版、迁移、robots 調整，提前把相關日誌單獨归档。
日誌轮轉和保留不是直接提升排名的操作，但它决定了你在遇到抓取異常、URL 發現變慢、服務器波動时，有没有足够證據做判断。把這份基础工作做稳，後面的站点运营和搜尋優化才有可复盘的資料支撑。