服务器磁盘爆满排查实录Docker 与 Systemd 日志的临时止血与永久根治概述问题服务器磁盘每周增长几个 Gdf -h告警根分区仅剩 1.4GB。目标定位空间刺客分场景处理 Docker 与 Systemd 日志从临时止血到永久根治。适合谁看负责 Linux 服务器运维的开发者、SRE、运维工程师。前置条件能 SSH 到目标机器具备sudo权限。一、故障现象根分区 97%Docker 容器告警df-hFilesystem Size Used Avail Use% Mounted on /dev/vda1 40G 36G 1.4G 97% / overlay 40G 36G 1.4G 97% /var/lib/docker/overlay2/...可用空间仅剩 1.4GB一连串overlay挂载点表明 Docker 容器正在运行。任何一次日志写入都可能直接触发No space left on device。二、定位空间刺客从 / 逐级下钻df告诉你满了du告诉你谁满的。逐级下钻是定位大文件的标准动作。2.1 根目录排序du-sh/*2/dev/null|sort-rh|head-n10目录大小/var23G/www7.2G/usr4.5G/swap.img2.1G/var独占 23GB首要怀疑对象。2.2 进入 /vardu-sh/var/*2/dev/null|sort-rh|head-n10子目录大小/var/lib17G/var/log5.1G/var/cache127M两个重灾区/var/lib持久化数据与/var/log日志。2.3 精准区分 /var/log 里的两类住客/var/log下住着两种本质完全不同的日志要用对应命令才能区分类别路径查大小命令Systemd 统一日志/var/log/journal/journalctl --disk-usage应用 / Docker 容器日志/var/log/*.log、/var/lib/docker/containers/*-json.logls -lhS /var/log/本次排查发现journalctl --disk-usage只有 450MB真正的元凶是 Docker 容器下一个 5GB 的-json.log。三、两大元凶的本质为什么日志会无限膨胀是/var/log 5G超过 1GB正常/var/lib 17G磁盘使用率 90% 告警df -h 确认根分区du -sh /* 定位大目录是否 /var?du -sh /var/*/var/log 还是 /var/lib?journalctl --disk-usageJournald 日志问题find 查找 *-json.logDocker 容器日志问题du -sh /var/lib/docker/*临时方案: journalctl --vacuum临时方案: truncate -s 0永久方案: journald.conf永久方案: daemon.json配置巡检脚本df -h 验证 ≤ 80%3.1 元凶一Systemd Journaldsystemd-journald接管了内核与系统服务SSH、Cron 等的日志。默认配置下不限制总容量上限文件会一直追加直到撑爆磁盘。判定标准journalctl --disk-usage超过 1GB 即可确认。3.2 元凶二Docker json-file 日志驱动容器内应用把日志输出到stdout/stderrDocker 用json-file驱动接收并落到/var/lib/docker/containers/id/id-json.log。默认同样无大小限制——一个高频输出的容器几天内能写出几十 GB。判定标准journalctl --disk-usage正常但单个*-json.log达数 GB。这两类日志默认无界的设计是 Linux 服务器磁盘爆满的头号通缉犯。四、应急止血临时方案秒级生效业务告急时先把空间抢回来再谈根治。临时方案的本质手动清扫垃圾但不限制垃圾桶容量重启后限制规则会失效。4.1 清理 Journald 日志# 限制总容量为 200MB推荐sudojournalctl --vacuum-size200M# 或保留最近 7 天sudojournalctl --vacuum-time7d执行完毕立即生效df -h可见空间释放。无需重启任何服务。4.2 清理 Docker 容器日志⚠️千万不要rm -f *.log容器进程仍持有文件句柄磁盘空间不会立即释放df与du还会出现显示不一致的诡异现象。除非重启容器生产环境等于业务中断。正确做法是截断find/var/lib/docker/containers/-name*.log-exectruncate-s0{}\;容器不重启docker logs仍能查看新产生的日志5GB 空间秒级归还。4.3 临时方案 vs 永久方案一张表看懂维度临时方案止血永久方案根治生效速度毫秒级需重启服务journald 不影响业务docker 中断容器重启后限制规则失效永久生效适用场景磁盘已满Use% ≥ 95%的紧急救火日常预防与固化核心价值快速止血保住业务彻底根治告别复发运维黄金法则先用临时方案秒级止血保住业务再配置永久方案杜绝复发。两者缺一不可。五、永久根治配置固化临时方案只能救一时写入配置文件才能让限制规则在重启后依然生效。5.1 固化 Journald限制 500MB为什么用 override 目录而不是直接改主配置升级系统时主配置文件可能被覆盖override 目录的优先级最高且独立维护符合生产环境的配置规范。sudomkdir-p/etc/systemd/journald.conf.dsudotee/etc/systemd/journald.conf.d/override.conf/dev/nullEOF [Journal] SystemMaxUse500M SystemMaxFileSize100M EOFsudosystemctl restart systemd-journald影响仅重启 journald 服务业务零感知。5.2 固化 Docker限制单文件 100MB × 3 个为什么选 100MB × 3单文件 100MB 足够保留完整上下文3 个轮转文件满足大多数排障需求总上限 300MB 是一个平衡点——既不浪费磁盘又不会因为轮转过频丢失关键日志。方案 A全局配置推荐一次性解决所有容器无需逐个项目配置。sudotee/etc/docker/daemon.json/dev/nullEOF { log-driver: json-file, log-opts: { max-size: 100m, max-file: 3 } } EOFsudosystemctl restartdocker⚠️systemctl restart docker会中断所有运行中的容器请在业务低峰期操作。方案 B项目级配置docker-compose.yml更精细services:library-service:image:library:0.0.1logging:driver:json-fileoptions:max-size:100mmax-file:3只需docker compose up -d --force-recreate不影响其他容器。配置优先级compose的loggingdaemon.json全局配置。六、长效预防自动巡检脚本把每周清理设为兜底任务即使永久配置失效也不会爆盘#!/bin/bash# /root/cleanup_logs.sh —— 每周巡检清理LOG/var/log/cleanup.logecho[$(date%F %T)] 开始巡检...$LOG# 1. Journald 超过 1GB 则压缩到 200MBif[$(journalctl --disk-usage|awk{print $3}|seds/[^0-9]//g)-gt1000];thenjournalctl --vacuum-size200M$LOG21fi# 2. Docker 单文件超过 1GB 则截断find/var/lib/docker/containers/-name*.log-size1G\-exectruncate-s0{}\;$LOG21# 3. 清理 24 小时前的构建缓存dockerbuilder prune-f--filteruntil24h$LOG21df-h/$LOG加入 crontab每周日 03:00 执行0 3 * * 0 /root/cleanup_logs.sh七、重启验证清单完成所有配置后建议进行一次重启验证# 1. 记录清理后的磁盘使用率df-h//tmp/disk_before.txt# 2. 重启服务器sudoreboot# 3. 重启后再次检查df-h/ journalctl --disk-usagefind/var/lib/docker/containers/-name*.log-execls-lh{}\;|head-10检查项预期结果根分区使用率仍保持在 80% 以下与重启前一致Systemd 日志大小≤ 500MB由SystemMaxUse控制Docker 日志文件单个 ≤ 100MB由max-size控制八、总结与思考df与du不一致必有进程持有已删除文件。排查命令lsof L1处理时尽量用truncate -s 0代替rm避免触发句柄残留。临时方案只救火永久方案才治病。vacuum和truncate不写入任何配置重启后上限自动归零——下次还会撑爆。Docker 日志是服务器磁盘爆满的头号惯犯。初始化服务器时务必第一时间配置/etc/docker/daemon.json。生产环境重启 Docker 全量容器中断务必在维护窗口或业务低峰期操作推荐用 compose 项目级配置降低影响面。建立发现即根治的运维意识。单次清理只能解燃眉之急把限制写入文件 巡检脚本双保险才能彻底告别每周告警的噩梦。附录速查手册A.1 常用命令目的命令查看磁盘df -h定位大目录du -sh /* | sort -rh | headJournald 占用journalctl --disk-usageDocker 占用明细docker system df单容器日志大小find /var/lib/docker/containers/ -name *.log -exec ls -lh {} \;截断容器日志find /var/lib/docker/containers/ -name *.log -exec truncate -s 0 {} \;A.2 关键配置组件路径核心参数Journald/etc/systemd/journald.conf.d/override.confSystemMaxUse500MDocker 全局/etc/docker/daemon.jsonmax-size100m, max-file3Compose 项目docker-compose.yml的logging字段同上所有的磁盘爆满都是日志在无声地呐喊你忘记给我设定边界了。