Docker 日志占满磁盘的服务器存储压力示意图

Docker 日志占满磁盘怎么办：轮转配置、清理步骤与容量预警

作者

Docker 日志占满磁盘的服务器存储压力示意图

Docker 日志占满磁盘怎么办？这篇指南帮助你从“先止血、再配置、最后预警”的顺序解决问题。很多站点不是应用代码突然崩溃，而是容器标准输出持续写入本机磁盘，几天后把 /var/lib/docker/containers/ 撑满，进而导致数据库写入失败、网站上传失败，甚至服务重启后无法正常拉起。

如果你的业务运行在 VPS（虚拟专用服务器）或独立服务器（专用物理服务器）上，日志增长速度通常和访问量、错误重试、调试级别直接相关。处理时不要只删除文件，更要确认日志驱动、单文件上限、保留份数和磁盘告警是否闭环，否则同样的问题很容易在下一次流量波动时重复出现。

先判断：是不是容器日志真的占满了磁盘

磁盘报警出现后，第一步不是立刻清空目录，而是确认空间到底被谁占用。Docker 默认常见日志路径位于 /var/lib/docker/containers/，每个容器目录下会有一个以容器 ID 命名的 *-json.log 文件。你可以先用 df 看分区，再用 du 找大目录：

df -h
sudo du -h --max-depth=1 /var/lib/docker 2>/dev/null | sort -h
sudo du -h --max-depth=1 /var/lib/docker/containers 2>/dev/null | sort -h | tail -20

如果 /var/lib/docker/containers 占用明显偏高，再查看具体容器日志文件大小：

sudo find /var/lib/docker/containers -name '*-json.log' -type f -printf '%s %p\n' \
  | sort -nr \
  | head -10 \
  | awk '{printf "%.2f GB %s\n", $1/1024/1024/1024, $2}'

这一步能避免误删应用数据卷。比如 MySQL、Redis、对象缓存等服务的数据通常不在同一个文件里，直接对整个 Docker 目录做清理可能带来更大风险。关于服务器目录和性能排查，也可以结合 服务器优化相关内容 建立统一检查流程。

先止血：安全清理超大的 json 日志

确认是 *-json.log 过大后，可以先清空日志文件内容，而不是删除文件本身。删除正在被 Docker 进程持有的日志文件，可能出现文件名消失但磁盘空间没有立即释放的情况；用 truncate 清空内容更稳妥。

sudo truncate -s 0 /var/lib/docker/containers/<container-id>/<container-id>-json.log

如果要批量处理超过 1GB 的容器日志，可以先列出清单再执行，避免误操作：

sudo find /var/lib/docker/containers -name '*-json.log' -type f -size +1G -print
sudo find /var/lib/docker/containers -name '*-json.log' -type f -size +1G -exec truncate -s 0 {} \;

这里要保留两个边界：第一，清空日志会丢失历史排障线索，建议在执行前至少保存最近 200-500 行；第二，如果应用还在持续输出错误，清理后空间会很快再次上涨。可以先导出关键尾部日志：

docker logs --tail 500 <container-name-or-id> > /root/docker-log-snapshot.txt

如果你管理的是面向外贸或业务站点的环境，建议把“磁盘剩余空间低于 15%”视为需要立即处理的信号。磁盘满不仅影响日志，还可能影响网站缓存、图片上传和会话写入，这与 网站性能优化 中的响应稳定性问题经常同时出现。

清理超大容器日志前先保留排障线索

再治本：为 Docker 默认日志驱动配置轮转

清理只是止血，真正的修复是给 Docker 日志设置上限。默认 json-file 日志驱动如果没有配置 max-size 和 max-file，日志文件可能持续增长。建议在 /etc/docker/daemon.json 中加入全局日志轮转配置：

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

这个配置表示单个日志文件最大约 100MB，最多保留 3 个文件。对多数中小型站点来说，单容器日志上限约 300MB，既能保留近期排障信息，也不会让一个异常容器无限占用磁盘。修改后需要重启 Docker 服务，并重新创建容器后才会对新容器生效：

sudo systemctl restart docker
docker inspect <container-name-or-id> --format '{{.HostConfig.LogConfig.Type}} {{.HostConfig.LogConfig.Config}}'

如果你使用 Compose，可以在服务级别写入日志策略，适合不同容器设置不同保留量：

services:
  web:
    image: example-web:latest
    logging:
      driver: json-file
      options:
        max-size: "50m"
        max-file: "5"

这里的关键不是数值越小越好，而是要按业务排障窗口决定。访问入口容器可以保留 3-7 天关键日志，任务型容器可以更短；如果应用每天产生 2GB 日志，应该优先降低应用日志级别，而不是单纯扩大磁盘。对需要更稳定运行环境的站点，也可以参考 VPS（虚拟专用服务器）方案 选择合适的磁盘和资源规格。

排查源头：为什么日志会突然暴涨

日志轮转能限制磁盘风险，但它不能替代应用修复。一次日志暴涨背后通常有明确原因：接口重试失败、数据库连接异常、调试级别未关闭、健康检查频率过高，或者反向代理不断记录同类 4xx/5xx 请求。建议从最近 500 行开始看高频模式：

docker logs --tail 500 <container-name-or-id> | sed -n '1,120p'
docker logs --since 30m <container-name-or-id> | wc -l

如果 30 分钟内输出数万行，就要把排查重点放到应用配置。常见处理方式包括：

  • 将生产环境日志级别从 debug 改为 info 或 warn，并记录变更时间，便于回滚；
  • 对重复报错增加采样或限流，例如同类错误每 60 秒只输出 1 次摘要；
  • 检查健康检查间隔，避免 1 秒一次的探测在异常时放大日志量；
  • 将应用日志输出到专门日志系统时，仍保留本机轮转，避免转发失败时本地堆积；
  • 对数据库、缓存、DNS（域名解析系统）连接失败设置退避重试，而不是毫秒级循环重试。

如果容器承载的是 WordPress 站点、接口服务或任务队列，日志暴涨也可能和插件报错、计划任务失败有关。WordPress 环境可以参考 WordPress 运维与优化内容，把应用层错误和主机层容量问题一起排查。

容器日志暴涨通常来自应用错误和重试循环

建立预警：不要等磁盘到 100% 才处理

日志治理最后一步是预警。一个实用规则是设置两级阈值：磁盘使用率超过 80% 时提醒检查，超过 90% 时进入紧急处理；单个容器日志超过 1GB 时提醒定位原因。即使没有完整监控平台，也可以先用 cron 加一个轻量脚本。

#!/usr/bin/env bash
THRESHOLD=80
USE=$(df /var/lib/docker | awk 'NR==2 {gsub(/%/,"",$5); print $5}')
if [ "$USE" -ge "$THRESHOLD" ]; then
  echo "Docker disk usage is ${USE}% on $(hostname)" | mail -s "Docker disk alert" admin@example.com
fi

再配合每天列出最大的日志文件，便于发现增长趋势：

sudo find /var/lib/docker/containers -name '*-json.log' -type f -printf '%s %p\n' \
  | sort -nr | head -20 \
  | awk '{printf "%.2f MB %s\n", $1/1024/1024, $2}'

如果你维护多台服务器，可以把磁盘、inode、容器重启次数和日志增长速度放在同一个巡检清单里。对独服（独立服务器）或业务量较大的部署，建议预留至少 20%-30% 可用磁盘空间，避免备份、镜像拉取和日志写入互相抢占。需要更高资源隔离时，也可以评估 独立服务器（专用物理服务器） 是否更适合长期运行容器业务。

日常维护建议：清理镜像不等于清理日志

很多人看到磁盘满，会先执行 docker system prune。这个命令能清理未使用的镜像、停止容器、网络和构建缓存，但它不一定解决正在运行容器的日志增长问题。执行前要看清范围：

docker system df
docker system prune -a

docker system prune -a 可能删除本地未被使用的镜像，下一次部署需要重新拉取，生产环境不要把它当作定时万能清理。更推荐的顺序是：先查日志文件大小，再清理超大日志，然后配置轮转，最后按需清理无用镜像和构建缓存。这样既能恢复空间，也能降低误删风险。

对于使用虚拟主机（共享式网站托管）运行普通网站的用户，通常不会直接接触 Docker 日志目录；但如果你在自管 VPS（虚拟专用服务器）上部署容器，就需要把日志轮转纳入基础运维。Hostease 提供的主机环境适合不同阶段的网站部署，但具体日志策略仍应结合你的应用写入量、排障需求和备份策略来配置。

总结：把“清理一次”变成“持续可控”

Docker 日志占满磁盘的处理建议按三步走：先用 df、du、find 确认大文件位置；再用 truncate 安全清理超大 *-json.log；最后通过 daemon.json 或 Compose 配置 max-size、max-file，并建立 80%/90% 两级容量预警。

如果你需要一个可执行的最低配置，可以考虑从 max-size=100m、max-file=3 开始，并在 1 周后根据实际日志增长调整。真正可靠的运维不是等磁盘满了再删除，而是让日志、磁盘、应用错误和告警形成闭环。这样即使业务访问量增加，服务器也能保持更稳定的运行状态。

发表评论