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/* 不但白干，重启后还会重新索引旧日志。

• 编辑 /etc/systemd/journald.conf，取消注释并设置：
  SystemMaxUse=512M（建议 256–1024M 区间）
  MaxRetentionSec=2week（控制保留时长）
• 生效命令：sudo systemctl restart systemd-journald
• 立即释放空间：journalctl --vacuum-size=512M 或 --vacuum-time=2d，比删文件安全十倍

Docker 容器日志爆满？从 daemon.json 开始堵漏

一个容器几小时内打满宿主机磁盘，大概率是 Docker 默认的 json-file 日志驱动没加限制。这不是应用问题，是运行时配置缺位。

• 在 /etc/docker/daemon.json 中加入：

{   "log-driver": "json-file",   "log-opts": {     "max-size": "10m",     "max-file": "3"   } }

• 重启生效：sudo systemctl restart docker
• 验证是否加载：docker inspect --format='{{.HostConfig.LogConfig}}'，输出里必须包含 max-size 和 max-file
• 注意：max-size 是单个日志文件上限，max-file 是保留份数，超出后自动轮替删除最老的

真正容易被忽略的是：容器日志路径（/var/lib/docker/containers//-json.log）不在 /var/log 下，常规 logrotate 规则扫不到——必须靠 Docker 自身驱动来管。