服务器日志是站点运营里最容易被忽略的一手资料。它记录的不只是访问次数，还有每一次请求的路径、状态码和耗时。不少团队在排查抓取异常时才发现：上周的日志已经被轮转覆盖，只能凭印象说一句“蜘蛛好像来得少了”。把日志留存这件事做在前面，比事后翻找要省力得多。

日志的价值不在“有”，而在“能对比”

只看一天的日志，能读出的信息很有限：某个时段请求多、某个时段请求少，仅此而已。真正有用的是把改版前、改版后、上线新栏目前后、调整 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. 每季度验证一次归档可读性，顺便更新分析口径

这些动作看起来琐碎，但真正跑起来之后几乎不需要额外维护。等到某天发现抓取数据不对劲，你会庆幸手里还有前几周的日志可以对照，而不是只能对着图表猜测。