日志文件过大，核心不是“删”，而是“控”和“转”——既要防止无节制增长，又要保障可追溯性。直接 rm 或 echo "" > file 风险高，可能中断服务写入或丢失关键现场；靠人工盯盘更不可持续。真正可靠的方案是分层治理：用 logrotate 管理文本日志，用 journald.conf 约束二进制日志，再辅以应用级日志策略收紧源头。
用 logrotate 实现按大小自动轮转
对高频写入服务（如 Nginx、Java 应用、自研后台），别只依赖 daily，应设 size 触发条件，避免单个文件突破 500MB 甚至几 GB：
-
size 100M：当日志文件超过 100MB，立即轮转（比时间驱动更及时） -
rotate 14：保留最近 14 次归档（若每天轮一次，约覆盖两周；若每小时一次，则覆盖 14 小时） -
dateext：归档名带日期（如access.log-20260303），排查时一目了然 -
delaycompress：刚轮出的日志先不压缩，方便紧急查问题；下次轮转时再压缩 -
missingok notifempty create 0644 user group：防路径不存在、空文件报错，并确保新日志权限正确
示例配置（存为 /etc/logrotate.d/myapp）：
size 100M
rotate 14
dateext
compress
delaycompress
missingok
notifempty
create 0644 appuser appgroup
}
快速验证与即时生效
改完配置别等 cron，用两条命令立刻确认是否有效：
-
logrotate -d /etc/logrotate.d/myapp：模拟运行，输出详细步骤（检查路径是否存在、权限是否匹配、size 是否达标） -
logrotate -f /etc/logrotate.d/myapp：强制执行一次，适用于磁盘已告急需马上释放空间
执行后运行 ls -lt /opt/app/logs/app*.gz，能看到带日期的新归档，且原 app.log 已清空或重置为 0 字节（取决于是否启用 copytruncate）。
约束 systemd-journald 的膨胀
很多系统磁盘爆满，真正元凶是 /var/log/journal/ 下的二进制日志——logrotate 对它完全无效。必须单独限制：
- 编辑
/etc/systemd/journald.conf - 取消注释并设置：
SystemMaxUse=512M（限制总占用不超过 512MB）MaxRetentionSec=30day（日志最长保留 30 天） - 重启生效：
sudo systemctl restart systemd-journald
执行 journalctl --disk-usage 可实时查看当前用量，调整后一般能释放数 GB 空间。
从源头减少日志产出
轮转是兜底，调级才是治本。尤其对 Java 类应用：
- 将日志框架（Logback/Log4j2）的 root logger 级别从
DEBUG改为INFO或WARN，避免海量调试信息刷屏 - 关闭高频但低价值模块的日志，例如 HTTP 客户端的请求体 dump、数据库连接池的每秒心跳
- 避免在循环内打日志（如“处理第 i 条记录”），改用计数器+汇总输出
- 对 nohup.out 这类裸输出，建议改用标准日志框架接管，或通过
nohup java ... >> app.log 2>&1重定向到受 logrotate 管控的文件
