抓取異常、流量下滑、接口报错，运营和运维的第一反應通常是翻日誌。但真正去翻的时候，不少人會發現日誌只剩最近一两天，前面全被覆盖了——不是分析不出来，而是根本没有資料可分析。日誌留存和轮轉属于最不起眼的基础設定，却决定了排查时有没有路可走。
留存周期先對齐排查周期
日誌留多久，不该拍脑袋，而要看實际排查的节奏。如果問题往往是“上周開始流量不對”“上個月收錄掉了”，那三天的留存毫無意义。多數站点把訪問日誌和错誤日誌的留存定在 30 到 90 天比較稳妥；蜘蛛抓取相關的记錄建议單獨留一份，便于和搜尋资源平台里的資料對上時間线。
轮轉的關键不是刪除，是切分
轮轉的目的有两個：让單個文件不至于大到無法打開，以及让歷史记錄有序可查。几個容易忽略的点：
- 按天或按体积切分，文件名里带上日期，方便定位時間段；
- 切分後压缩归档，纯文本压缩率通常很高，能省下大量磁盘空間；
- 轮轉完成後要让服務進程重新打開文件句柄（例如 Nginx 需要重载或發送信号），否則日誌會繼續寫進已被重命名的舊文件；
- 多進程、多實例寫同一個文件时要格外小心，错行和丢行往往出在這里。
字段是否够用，要按將来會提的問题来定
日誌字段的取舍，决定了以後能問出什么样的問题。自查时可以對照下面几項：
- 是否记錄了真實訪客 IP。站点前面挂了 CDN 或反向代理时，要確認拿到的是轉發头里的地址，而不是代理自身的地址。
- 是否保留 User-Agent 和 Referer，否則很难区分蜘蛛、监控探针和普通用戶。
- 是否记錄响應狀態碼和响應耗时，這两項是判断抓取预算被浪費還是被正常消耗的基础。
- 時間戳的时区是否统一。日誌时区和後台报表时区不一致，會让排查平白多绕一圈。
- 是否誤记了敏感信息，例如查询串里的手机号、令牌、身份标识，有必要做脱敏或排除。
- 是否有异地备份。本机磁盘故障时，日誌往往和站点一起没了。
別把日誌做成负担
“记錄得越全越好”是一種誤解。全量记錄图片、样式、脚本請求，會让日誌体积迅速膨胀，既占磁盘也拖慢分析。合理的做法是按目錄或後缀做取舍，但要守住一條底线：不要顺手把蜘蛛的請求也過滤掉，那等于自断排查依據。
排查問题的顺序應该是：先確認日誌還在，再確認字段够用，最後才是分析。顺序颠倒，往往就卡在第一步。
可以固定成月度動作的几件事
- 看一次磁盘水位，確認剩余空間足够支撑下一個留存周期；
- 核對留存天數是否仍與配置一致，有没有被临时改動後忘记還原；
- 随机挑一個較早的归档文件解開，確認内容可讀、時間连續、没有断层；
- 把结论记在同一處文档里，避免每次換人排查都從头摸索。
日誌本身不會带来流量，但它决定了出問题时你能不能把原因说清楚。把留存周期、轮轉方式和字段范围這三件事定下来，站点运营里很多“说不清”的問题，至少能變成“查得到”。