Linux 日志文件失控的治理方案-linux运维

logrotate 配置未生效主因是定时器未触发或规则未被加载；需检查 logrotate.timer 状态、/etc/logrotate.d/ 下文件权限与 include 路径；按大小轮转须避免与 daily 冲突，推荐使用 size、copytruncate、notifempty 和 missingok；journald 和 Docker 日志需分别通过 journald.conf 和 daemon.json 限流。

logrotate 配置写了却没轮转？先查定时器有没有跑

日志文件持续膨胀、logrotate -d /etc/logrotate.conf 手动执行又一切正常——这基本说明配置根本没被触发。不是规则写错了，是压根没进调度队列。

• systemctl list-timers | grep logrotate：新版 systemd 默认启用 logrotate.timer，如果没看到，说明定时器没注册或被禁用
• ls -l /etc/logrotate.d/：确认你的规则文件（比如 myapp）确实在这个目录下，且权限是 644（不能是 600 或 755）
• grep -r "include" /etc/logrotate.conf：必须有 include /etc/logrotate.d 这一行，否则所有 /etc/logrotate.d/ 下的文件都会被忽略

按大小切日志，别迷信 daily

一天 1KB 和一天 8GB 的日志，硬按时间轮转毫无意义。用 size 才能真正控住单个文件体积，但参数之间有冲突，一错就失效。

• size 100M 和 daily 不能共存：只要写了 daily，logrotate 就只看时间，size 形同虚设
• copytruncate 是关键：应用不重开日志句柄时，必须用它，否则轮转后原进程还在往已清空的旧文件写，磁盘空间不释放
• notifempty 和 missingok 建议常驻：避免空日志或临时缺失路径导致整个轮转流程中断

示例规则：

/var/log/myapp/app.log {
    size 100M
    rotate 7
    compress
    delaycompress
    copytruncate
    notifempty
    missingok
}

journald 占满几十 GB？别删文件，改配置再 vacuum

/var/log/journal/ 突然飙到 30GB+，不是磁盘坏了，是 systemd-journald 根本没设上限。直接 rm -rf /var/log/journal/* 不但白干，重启后还会重新索引旧日志。