真正有效的日志策略必须同时满足自动切割、合理归档与安全保留，核心是max-size、max-file、compress+delaycompress、missingok+notifempty四项配置缺一不可。
守护进程日志不轮转，等于给系统埋了一颗定时炸弹。真正有效的输出策略，核心是“自动切割 + 合理归档 + 安全保留”，而不是等磁盘报警才动手。
关键配置项必须检查
无论用 logrotate、Docker 日志驱动，还是应用内 RotatingFileHandler，以下四点缺一不可：
- max-size 或 size：设定单个日志文件上限（推荐 10M–100MB，视设备资源而定）
- max-file 或 rotate：明确保留几个历史版本（嵌入式设备建议 3–5，服务器可设 7–30）
- compress + delaycompress：启用压缩并延迟执行，避免影响实时写入
- missingok + notifempty：跳过缺失或空文件，防止轮转失败中断流程
不同场景的典型配置方式
不是所有日志都该用同一种策略：
-
Docker 容器日志：通过 daemon.json 或 run 参数控制，例如：
{"log-driver":"json-file","log-opts":{"max-size":"50m","max-file":"7"}} -
宿主机服务（如 Nginx、rsyslog）：在
/etc/logrotate.d/下建独立配置，配合postrotate发送信号重载服务 -
Python/Java 应用内日志：直接使用
RotatingFileHandler或RollingFileAppender，参数与外部工具逻辑一致
归档不是存着就完事
归档后还需考虑实际可用性：
- 压缩后的
.gz文件要能被zcat或journalctl --all --no-pager直接查看，别让排查变绕路 - 日志路径需统一权限（如
create 0640 root adm），避免因权限问题导致轮转失败 - 定期验证归档是否真正生效——手动触发
logrotate -f /etc/logrotate.d/myapp看能否生成新文件
警惕那些“看似正常”的陷阱
常见失效原因往往藏在细节里：
- logrotate 配置文件没加执行权限，或放在错误目录（必须在
/etc/logrotate.d/或被include引用） - Docker 容器启动时未指定
--log-opt，而是依赖默认的无限制 json-file 驱动 - 应用自身也写日志（比如同时往 stdout 和文件写），造成双日志膨胀，轮转只管了一半
- 定时任务（cron）未启用或时间设置错误，导致 logrotate 从不运行
