rotate仅控制归档文件数量，不保证保留天数；必须搭配daily/weekly等时间策略及maxage按修改时间强制清理，才能精准实现差异化保留周期。
rotate 参数本身只控制保留多少个归档文件，不保证“保留多少天”——它数的是文件个数，不是时间。你看到 rotate 7 就以为是“留 7 天”，但实际可能跨两周（比如某天没轮转），也可能只撑 3 天（如果日志量大、高频轮转）。真正要稳住保留窗口，得靠组合策略。
为什么 rotate 单独用不可靠
logrotate 每次运行时检查是否满足轮转条件（如 daily 到期、或 size 100M 达标），再执行归档。如果服务停了两天，daily + rotate 7 仍只生成 5 个文件，但它们可能横跨 9 天；反之，若每小时都因 size 触发一次轮转，rotate 7 可能几分钟内就刷掉旧文件。
-
rotate是“计数器”，不是“计时器” - 它不读文件修改时间，也不校验日期后缀
- 和
dateext一起用时，文件名带日期，但 logrotate 不据此判断过期
rotate 必须搭配时间策略才可控
要让“保留 N 个”落地为“最多存 M 天”，必须明确指定轮转频率，并用 maxage 补位：
-
daily + rotate 14 + maxage 14：每天最多生成 1 个归档，maxage强制删掉 >14 天的文件，双保险 -
weekly + rotate 8 + maxage 60：至少保留最近 8 周，但绝不超 60 天（哪怕某周漏转） - 禁止单独写
rotate 30而不配daily/weekly或maxage，否则行为不可预期
不同业务场景下的典型配置
关键不是“统一设成 rotate 30”，而是按日志价值和写入节奏差异化设置：
- API 访问日志（高频、体积大）：
daily+rotate 14+maxage 14+compress+delaycompress - 审计日志（低频、需长期可查）：
weekly+rotate 12+maxage 90+create 0600 root root - 调试日志（临时启用、易爆炸）：
size 50M+rotate 5+maxage 7（注意：size和daily互斥，不能共存）
所有规则建议写在 /etc/logrotate.d/myapp 独立文件里，避免污染全局 /etc/logrotate.conf。
验证配置是否生效的实操步骤
别等 cron 自动跑，先手动测通再上线：
- 加
-d模拟运行：logrotate -d /etc/logrotate.d/myapp，看输出是否匹配预期路径和动作 - 加
-f强制执行一次：logrotate -f /etc/logrotate.d/myapp，然后立刻检查ls -lt /var/log/myapp/ - 确认归档文件名含日期（用了
dateext）、权限正确（create生效）、旧文件被删（rotate和maxage共同作用） - 留意
/var/lib/logrotate.status文件，它记录各日志上次轮转时间，是maxage的判断依据
maxage 的计算基准是文件的 mtime（最后修改时间），不是文件名里的日期，也不是轮转发生时间——这点最容易被忽略，导致误判清理逻辑。
