最稳妥的日志轮转方案是直接用 logrotate 配置，因其不依赖 rsyslog 或 syslog-ng 的内置机制，兼容性好、行为可预测，且能统一管理所有日志；rsyslog 的 $systemlogrotatedays 仅控制其自身主日志，不处理子进程或应用日志，且在旧版本中存在 keep 策略失效问题。
直接用 logrotate 配置最稳妥，不依赖 rsyslog 或 syslog-ng 的内置轮转机制，兼容性好、行为可预测，且能统一管理所有日志（包括 Nginx、自定义应用等）。
为什么不用 rsyslog 的 $SystemLogRotateDays？
rsyslog 的 $SystemLogRotateDays 仅控制其自身写入的主日志（如 /var/log/syslog），但不处理子进程日志、应用日志或已切割的归档文件；更重要的是，它在较老版本（如 rsyslog 8.19 之前）中存在 keep 策略失效问题，实际保留天数可能远超预期。你看到日志目录里堆着 syslog.1.gz 到 syslog.100.gz，大概率就是这个参数没生效。
logrotate 配置必须加这 4 个关键项
以 /var/log/syslog 为例，在 /etc/logrotate.d/rsyslog 中写入：
/var/log/syslog {
daily
rotate 7
compress
missingok
notifempty
create 640 root adm
sharedscripts
postrotate
systemctl kill --signal=USR1 --kill-who=main $(systemctl show --property=MainPID --value rsyslog.service) 2>/dev/null || true
endscript
}
-
rotate 7：只保留 7 个归档文件（不是 7 天），配合daily才等效于“7 天” -
compress+delaycompress（建议补上）：避免刚轮转完就压缩，方便调试时快速查看上一份明文日志 -
missingok：防止因日志路径临时不存在导致整个 logrotate 失败 -
postrotate里的USR1信号：通知 rsyslog 关闭旧文件句柄，否则新日志仍会写进已被 rename 的文件（即磁盘空间不释放）
验证是否真按 7 天清理？别只看文件名
常见误判：看到 syslog.7.gz 就以为保留了 7 天——其实 .7 只是序号，不代表日期。正确检查方式：
- 运行
logrotate -d /etc/logrotate.d/rsyslog（dry-run 模式），看输出里是否包含removing old log /var/log/syslog.7.gz - 手动触发一次：
logrotate -f /etc/logrotate.d/rsyslog，再执行ls -lt /var/log/syslog*，确认最老的归档文件修改时间是否 ≈ 7 天前 - 检查
find /var/log -name "syslog.*" -type f -mtime +7是否无输出（若有，说明有漏删）
真正容易被忽略的是：logrotate 不会自动清理 .gz 文件之外的残留，比如 syslog.1（未压缩）和 syslog.1.gz 并存时，rotate 7 只保证最多留 7 个归档，但不保证这 7 个都是压缩态。如果你同时启用了 compress 和 delaycompress，就要接受第 1 天的归档是明文、第 2 天起才压缩——这是设计使然，不是 bug。
