日志爆满先别急着删:用 logrotate 与 journald 配额给日志上锁

举报
yd_246130537 发表于 2026/11/05 09:45:44 2026/11/05
【摘要】 服务器出问题,第一反应往往是看日志;可很多机器真正倒下,不是因为服务本身,而是日志把磁盘写满了。应用日志一天几 GB、systemd 日志默认不设上限、再加上没人清理的旧压缩包,磁盘一满,数据库写不进、服务起不来,连登录排查都变慢。本文用三步给日志上锁:先定位谁在疯长,再用 logrotate 管应用日志,最后给 journald 设配额,三者配合,日志既留得住、又不会反噬磁盘。第一步:先定...

服务器出问题,第一反应往往是看日志;可很多机器真正倒下,不是因为服务本身,而是日志把磁盘写满了。应用日志一天几 GB、systemd 日志默认不设上限、再加上没人清理的旧压缩包,磁盘一满,数据库写不进、服务起不来,连登录排查都变慢。本文用三步给日志上锁:先定位谁在疯长,再用 logrotate 管应用日志,最后给 journald 设配额,三者配合,日志既留得住、又不会反噬磁盘。
第一步:先定位,别上来就删。删日志之前,先确认两件事:是哪类日志在涨,以及它现在占了多少。应用日志通常在 /var/log 下面,systemd 日志在 /var/log/journal 里,两处都要看:du -sh /var/log/* 按大小排序,journalctl --disk-usage 只看 journald 占了多少,df -h / 确认根分区还剩多少。如果 journald 一家就占了几个 GB,问题在配额上;如果是某个应用的 access.log、error.log 在疯长,问题在 logrotate 上。定位不清就批量删,很容易把正在排查的那段日志也删掉。还有一个常见误区:直接把正在被写的文件删掉,磁盘空间不一定释放,因为进程还握着文件句柄,删的只是目录项,空间要等进程重启或句柄关闭才回来。正确做法是先轮转、再让进程重新打开文件,而不是 rm 正在写的文件。
第二步:logrotate 管应用日志,四个参数就够。大多数 Linux 发行版自带 logrotate,每天由 cron 或 systemd 定时跑一次。给某个应用写一份配置,放到 /etc/logrotate.d/ 下面,例如:/var/log/myapp/*.log { daily rotate 14 compress delaycompress missingok notifempty sharedscripts postrotate systemctl reload myapp endscript }。意思是每天轮转一次,只保留 14 份,旧的自动删并压缩,昨天那份先不压缩方便马上翻查,日志不存在也不报错,空文件不轮转,轮转后通知服务重新打开日志文件,避免“删了也不释放空间”。如果服务不支持 reload,改成 restart 也可以,但要接受一次短暂中断,生产服务优先用 reload 或发信号的方式。写好配置先用 logrotate -d 做调试模拟,只模拟不真正轮转,能看到它打算怎么处理每个文件;确认无误后再用 logrotate -f 强制跑一次验证,看到旧日志变成 .gz、服务仍在正常写新文件,才算真正生效。轮转周期不必越短越好,保留 14 天是常见折中,故障排查一般看最近一周,审计要求长的可以把 rotate 放大,但要同步算好磁盘预算。
第三步:给 journald 设配额,防止它一家独大。journald 默认会按磁盘比例自动扩容,磁盘越大它能占的越多,小磁盘机器上尤其危险。在 /etc/systemd/journald.conf 里显式设上限:SystemMaxUse=500M、SystemKeepFree=1G、MaxRetentionSec=14day、Storage=persistent。SystemMaxUse 是总量硬上限,SystemKeepFree 要求至少留 1G 空闲,两者取更严格的那个生效,保留 14 天,重启后日志仍保留,排障时能看到上次启动前的内容。改完执行 systemctl restart systemd-journald 生效,再用 journalctl --disk-usage 核对,必要时用 journalctl --vacuum-size=500M 手动立即清理到 500M 以下,适合配额刚设好、旧日志已经超标时先清一次。按时间清理则用 journalctl --vacuum-time=7d,保留最近 7 天,时间和大小两种清理按需选一种,不必同时用。
第四步:留一个兜底告警,别等满了才发现。轮转和配额都设好了,还差一个兜底:磁盘用量告警。最简单的办法是每天跑一次检查,根分区超过 80% 就发通知或写一条明显日志,脚本可用 df 取用量、超过 80% 就 logger 记一条警告,放进 cron 每天跑一次,有监控平台的直接接磁盘用量告警更省事。80% 这个阈值是给轮转留出反应时间,等到 95% 再处理往往已经来不及,数据库可能已经先写失败了。
一张清单收尾:先用 du 与 journalctl --disk-usage 定位最大的日志来源;再给应用日志写 logrotate 配置,轮转后务必 reload 服务重新打开文件;然后给 journald 设 SystemMaxUse 与保留天数,防止它无上限增长;最后加一个 80% 的磁盘告警兜底。做完这四步,日志还是那个最有用的排障证据,只是不再是半夜把磁盘写满的隐患。

【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0)

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。