size 和 yearly 互斥，配置 size 时 yearly 无效；应根据日志特性选 size（防爆满）或 yearly（需手动调度）；推荐 size + dateext + rotate/maxage 组合实现稳定长期归档。
size 和 yearly 不能共存
Logrotate 的 size 参数与时间类参数（daily、weekly、monthly、yearly）是互斥的。一旦配置了 size，所有时间周期指令都会被忽略——yearly 不会生效，也不会按年检查或触发轮转。它只在每次 logrotate 执行时判断：当前日志文件是否 ≥ 指定 size，是则立即轮转，与年份无关。
所以，“size + yearly”本身是一个无效组合，无法实现“超长周期内稳定归档”的目标。真正可行的路径是根据日志增长特性，选择单一可靠触发机制，再配合保留策略与命名规则来支撑长期归档需求。
明确触发逻辑：用 size 还是用 yearly？
- 选 size：适合日志写入不规律、可能突发暴涨的服务（如调试期应用、API 网关、批量任务日志）。只要单个文件达到阈值（如 size 500M），就立刻切割，防止单文件过大影响 grep、传输或备份。 - 选 yearly：适合日志量极低、全年写入总量可控、且需严格按自然年归档审计的场景（如合规日志、年度汇总报告）。但注意：yearly 仅表示“每年检查一次”，实际轮转仍依赖 cron 是否真在每年执行一次——而系统默认 cron 只每天运行 logrotate，不会自动适配 yearly；必须手动调整 cron 或使用外部调度器。简单说：yearly 在默认环境下几乎不工作，除非你额外配置每年 1 月 1 日零点执行 logrotate —— 这既不健壮也不推荐。
真正支持长期归档的实用组合
要达成“超长周期内稳定归档”，关键是： ✅ 触发及时（防爆满） ✅ 归档可追溯（带时间戳） ✅ 保留策略清晰（不无限堆积）推荐这样配：
- 触发方式：用 size 200M（或根据服务调优），确保大日志不卡死磁盘
- 归档标识：启用 dateext + dateformat -%Y%m%d-%s（含秒级时间戳，避免同秒多轮转冲突）
- 保留逻辑：用 rotate 365（保留约一年的归档文件），或结合 maxage 365（按最后修改时间自动清理超期文件）
- 压缩控制：加 compress 和 delaycompress，保证最新一份不压，便于快速查看
示例配置片段：
/var/log/myapp/app.log {
size 200M
dateext
dateformat -%Y%m%d-%s
rotate 365
maxage 365
compress
delaycompress
missingok
notifempty
copytruncate
}
补充关键细节：让长期归档更稳
- copytruncate 必须加：尤其对不支持 reopen 的进程（如某些 Java 应用），否则轮转后日志写入会中断或丢失 - 状态文件别忽略：logrotate 默认读取 `/var/lib/logrotate.status`，确保该文件可写且不被误删，否则可能重复轮转或跳过 - 手动验证用 -d 或 -t：改完配置先运行 `logrotate -d /etc/logrotate.d/myapp` 看模拟输出，确认触发条件和文件名生成逻辑符合预期 - 不要依赖 yearly 实现“长期”：长期 ≠ 按年轮转，而是靠足够大的 rotate 数 + 合理的 maxage + 可读的时间戳命名，实现按需检索、自动清理归档的稳定性，不来自“年”这个单位，而来自可预测的触发、可识别的命名、可收敛的保留边界。
