抓取异常、流量下滑、接口报错，运营和运维的第一反应通常是翻日志。但真正去翻的时候，不少人会发现日志只剩最近一两天，前面全被覆盖了——不是分析不出来，而是根本没有数据可分析。日志留存和轮转属于最不起眼的基础设置，却决定了排查时有没有路可走。
留存周期先对齐排查周期
日志留多久，不该拍脑袋，而要看实际排查的节奏。如果问题往往是“上周开始流量不对”“上个月收录掉了”，那三天的留存毫无意义。多数站点把访问日志和错误日志的留存定在 30 到 90 天比较稳妥；蜘蛛抓取相关的记录建议单独留一份，便于和搜索资源平台里的数据对上时间线。
轮转的关键不是删除，是切分
轮转的目的有两个：让单个文件不至于大到无法打开，以及让历史记录有序可查。几个容易忽略的点：
- 按天或按体积切分，文件名里带上日期，方便定位时间段；
- 切分后压缩归档，纯文本压缩率通常很高，能省下大量磁盘空间；
- 轮转完成后要让服务进程重新打开文件句柄（例如 Nginx 需要重载或发送信号），否则日志会继续写进已被重命名的旧文件；
- 多进程、多实例写同一个文件时要格外小心，错行和丢行往往出在这里。
字段是否够用，要按将来会提的问题来定
日志字段的取舍，决定了以后能问出什么样的问题。自查时可以对照下面几项：
- 是否记录了真实访客 IP。站点前面挂了 CDN 或反向代理时，要确认拿到的是转发头里的地址，而不是代理自身的地址。
- 是否保留 User-Agent 和 Referer，否则很难区分蜘蛛、监控探针和普通用户。
- 是否记录响应状态码和响应耗时，这两项是判断抓取预算被浪费还是被正常消耗的基础。
- 时间戳的时区是否统一。日志时区和后台报表时区不一致，会让排查平白多绕一圈。
- 是否误记了敏感信息，例如查询串里的手机号、令牌、身份标识，有必要做脱敏或排除。
- 是否有异地备份。本机磁盘故障时，日志往往和站点一起没了。
别把日志做成负担
“记录得越全越好”是一种误解。全量记录图片、样式、脚本请求，会让日志体积迅速膨胀，既占磁盘也拖慢分析。合理的做法是按目录或后缀做取舍，但要守住一条底线：不要顺手把蜘蛛的请求也过滤掉，那等于自断排查依据。
排查问题的顺序应该是：先确认日志还在，再确认字段够用，最后才是分析。顺序颠倒，往往就卡在第一步。
可以固定成月度动作的几件事
- 看一次磁盘水位，确认剩余空间足够支撑下一个留存周期；
- 核对留存天数是否仍与配置一致，有没有被临时改动后忘记还原；
- 随机挑一个较早的归档文件解开，确认内容可读、时间连续、没有断层；
- 把结论记在同一处文档里，避免每次换人排查都从头摸索。
日志本身不会带来流量，但它决定了出问题时你能不能把原因说清楚。把留存周期、轮转方式和字段范围这三件事定下来，站点运营里很多“说不清”的问题，至少能变成“查得到”。