按天轮转是首选，因文件名含日期便于问题定位，单日体积适中利于grep/awk快速查询，配合rotate参数可预期控制磁盘占用。
按天轮转是最常用也最合理的默认选择，兼顾存储控制、查询定位和运维可维护性。
为什么 daily 是首选周期
日志按天切分后，文件名自带日期（如 access.log-20260904），排查问题时能快速锁定时间范围；单日日志体积通常在几十MB到几百MB之间，用 grep 或 awk 查阅响应快，不卡顿；磁盘占用可预期，配合 rotate 30 就能稳定维持约一个月数据，避免突增失控。
- 若业务流量极低（日志 weekly，减少碎片文件，但会弱化“某天异常”的定位效率
- 若突发流量大（单日超 2GB）、或需高频审计，建议加
size +500M作为兜底，防止某天日志爆炸式增长 - 避免用
monthly：跨月日志难以对齐监控周期，且月末大流量易导致单文件过大、影响tail -f实时跟踪
保留份数要匹配实际需要
保留太多浪费空间，太少无法回溯。常规建议：
- 生产环境建议
rotate 30—— 覆盖完整月度分析周期，也留出故障复盘窗口 - 测试/预发环境可用
rotate 7，节省空间，满足基本问题追踪 - 合规强要求场景（如金融、审计）可设
rotate 90或配合归档到对象存储，但需额外配置压缩与异步转移
别忽略压缩与空文件处理
加 compress delaycompress notifempty 能显著降低磁盘压力：
-
delaycompress确保最新一份日志保持明文，方便紧急less或zgrep不用解压 -
notifempty防止凌晨低峰期生成一堆空的.log-20260904文件，干扰识别 - 压缩后体积通常降至原始 10%–20%，对 SSD 友好，也减少备份带宽消耗
验证和微调比盲目设参数更重要
上线前务必手动测试：
- 用
sudo logrotate -d /etc/logrotate.d/nginx检查语法与路径是否识别正确 - 再用
sudo logrotate -vf /etc/logrotate.d/nginx强制跑一次，确认新日志生成、旧文件重命名、postrotate是否成功发 USR1 - 观察
/var/log/nginx/下是否出现access.log-20260904.gz和新的access.log，且后者有新写入内容
