服務器日誌是站点运营里最容易被忽略的一手资料。它记錄的不只是訪問次數，還有每一次請求的路径、狀態碼和耗时。不少团队在排查抓取異常时才發現：上周的日誌已经被轮轉覆盖，只能凭印象说一句“蜘蛛好像来得少了”。把日誌留存這件事做在前面，比事後翻找要省力得多。

日誌的價值不在“有”，而在“能對比”

只看一天的日誌，能讀出的信息很有限：某個时段請求多、某個时段請求少，僅此而已。真正有用的是把改版前、改版後、上线新栏目前後、調整 robots 前後的日誌放在一起看，观察狀態碼分布、抓取路径和响應時間有没有變化。前提是這些日誌都還在，而且字段口径一致。

值得長期保留的字段

日誌格式各家不同，但下面這些字段建议原样保留，不要為了省空間提前裁剪：

• 時間戳，且带明确时区，方便和其他系統的時間對齐
• 請求的完整路径，包括查询參數
• HTTP 狀態碼，這是判断抓取是否顺畅的核心
• 响應字节數與响應時間
• User-Agent，用于区分不同来源
• 来源 IP，如需長期儲存建议做匿名化或截断處理
• 站内来源頁，可用于观察跳轉路径

如果日誌已经被压缩或轉成表格，至少保留原始文件和一份结构化副本，避免後續換了分析工具又要重新解析。

保留周期與轮轉策略

按時間和容量双轨控制

只按天數轮轉，遇到流量暴涨可能一天就寫满磁盘；只按容量轮轉，低峰期又可能把文件拆得過碎。比較稳妥的做法是两條线同时設定，先到者触發轮轉：

1. 在线滚動日誌保留七到十四天，方便快速查阅
2. 压缩归档保留九十天以上，覆盖一次完整改版周期
3. 對每月的代表性时段做抽样長期儲存，用于季度對比

留意时区與時間同步

服務器时区若與团队所在地不同，日誌里的“凌晨”可能是另一回事。建议统一使用同一種时区记錄，並開啟時間同步服務，否則日誌、缓存和統計报表三邊對不上，排查时會多绕很多弯路。

存储與合規上的注意事項

• 压缩後再归档，常用 gzip 或 zstd，能省下大量空間
• 文件名带上日期，避免出現 log、log.1、log.2 這類顺序命名
• 归档文件放到獨立的离线或對象存储，別和執行环境挤在同一块盘上
• IP 属于個人信息范畴，長期儲存前先脱敏，並限制訪問權限
• 定期驗證归档文件能正常解压，別等要用的时候才發現损坏

分析日誌时容易踩的几個坑

• 只看總量不看狀態碼分布，請求數没變但错誤碼上升了，問题被掩盖
• 把 User-Agent 当作唯一判據，UA 可以伪造，需要结合 IP 段和行為模式
• 样本太短，一两個小时的資料不足以說明趋势
• 忽略图片、样式等静態资源的請求占比，誤以為内容頁被抓得很多
• 先有结论再找資料，只挑對自己观点有利的那几天

日誌留存的目标不是堆满硬盘，而是在需要的时候，能拿出至少两個時間点的資料做對照。

一份可执行的落地清單

1. 確認目前日誌是否包含時間戳、路径、狀態碼、UA、字节數、耗时
2. 检查轮轉配置，设定時間與容量两個阈值
3. 把归档文件迁到獨立存储，並設定压缩與命名規則
4. 對 IP 做脱敏，限制日誌目錄的訪問權限
5. 每月抽一天日誌做人工抽样，熟悉正常狀態下的分布
6. 每季度驗證一次归档可讀性，顺便更新分析口径

這些動作看起来琐碎，但真正跑起来之後几乎不需要額外维護。等到某天發現抓取資料不對劲，你會庆幸手里還有前几周的日誌可以對照，而不是只能對着图表猜测。