Docker 容器日志疯狂增长占满磁盘？这份清理与限制的全套方案请收好

前言：日志为何成了磁盘杀手

很多跑着 Docker 的生产服务器，突然某天磁盘告警，排查下来往往不是业务数据，而是 /var/lib/docker/containers 目录下的 *-json.log 文件在作祟。默认情况下，Docker 对容器日志的大小和数量没有任何限制，只要容器持续输出，日志文件就会无限膨胀，直到把磁盘塞满。

笔者曾见过一个只跑着 Nginx 反代的容器，三个月没管，日志文件涨到 40 多 GB，直接把系统盘写爆。今天这篇，咱们不聊虚的，直接给出从原理到实操的完整清理与限制方案。

一、问题根源：Docker 默认日志驱动机制

🔥 【限时特惠福利】高性价比独享云服务器限时 1 折起

搭建网站或部署容器推荐选择高稳定性独享云服务器。限时特惠通道开放中，点击即可领取专属满减代金券与特惠折扣：

👉 立刻领取云服务器限时优惠券

💡 延伸阅读：WordPress 图片加载慢？这份 WebP 配置调优指南，把评分拉满

Docker 默认使用 json-file 日志驱动，它将容器的标准输出（stdout/stderr）原样写入宿主机文件。这个文件只增不减，除非你手动清理，否则它会一直占用磁盘空间。

更麻烦的是，即使你删除了容器，只要没有加 -v 参数，这些日志文件依然残留在宿主机上。所以，我们既要学会事后清理，更要学会事前限制。

二、紧急清理：磁盘告警时的急救措施

💡 深度技术指南：别再被参数表忽悠了！云服务器选型与避坑实战：学生党与个人站长的性价比终极指南

如果磁盘已经告警，第一时间先救急。下面三条命令，按顺序执行即可。

1. 定位大文件

先找出哪些容器日志占用了大量空间：

du -sh /var/lib/docker/containers/*/*-json.log | sort -rh | head -20

这条命令按大小降序列出前 20 个日志文件，你能一眼看到是哪个容器在“吃”磁盘。

2. 清空日志文件（不重启容器）

找到目标后，直接清空文件内容即可，无需重启容器，对业务零影响：

cat /dev/null > /var/lib/docker/containers/<container_id>/<container_id>-json.log

注意这里用的是 > 重定向，而不是 rm 删除。因为 Docker 进程持有该文件的文件描述符，直接 rm 虽然能释放空间，但会造成句柄泄漏，直到容器重启才会真正释放。而 cat /dev/null > 文件 是原地截断，立竿见影且安全。

3. 一键清理所有容器日志

如果日志文件太多，不想一个个处理，可以使用下面的脚本遍历清理：

for log_file in $(find /var/lib/docker/containers/ -name "*-json.log"); do
    echo "Truncating: $log_file"
    cat /dev/null > "$log_file"
done

三、根治方案：配置日志轮转与大小限制

急救只是治标，要治本必须让 Docker 在写入日志时就自动切割和清理。Docker 的 json-file 驱动支持两个关键参数：max-size 和 max-file。

1. 全局配置（推荐生产环境使用）

编辑 Docker 守护进程配置文件 /etc/docker/daemon.json：

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

参数含义：

max-size：单个日志文件的最大大小，超过后自动切割。
max-file：保留的日志文件数量，旧的会被自动删除。

上面的配置表示：每个容器最多保留 3 个日志文件，每个文件不超过 10MB，总计最多 30MB。修改后重启 Docker 生效：

systemctl restart docker

需要注意，该配置只对新建容器生效，已存在的容器需要重建才能应用新策略。

2. 单容器配置（适合临时起容器）

如果你只是临时跑个容器，不想改全局配置，可以在 docker run 时直接指定：

docker run -d \
  --log-opt max-size=5m \
  --log-opt max-file=2 \
  nginx:latest

对于 docker-compose 部署的服务，在服务配置下加入：

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

四、进阶方案：切换更高级的日志驱动

json-file 虽然简单，但日志格式是 JSON，解析成本高，且切割时性能一般。如果你的服务器资源充裕，可以考虑切换到 local 驱动，它使用更紧凑的二进制格式，性能更好，且天然支持轮转：

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

对于大型生产集群，更专业的做法是使用 fluentd 或 gelf 驱动，将日志直接推送到中央日志系统（如 ELK、Loki），宿主机上不落盘，彻底解决磁盘问题。但这需要额外搭建日志收集系统，适合日志量极大的场景。

五、验证与日常巡检

配置完成后，需要验证是否生效。创建一个测试容器并持续输出日志：

docker run -d --name log-test --log-opt max-size=1m --log-opt max-file=2 busybox sh -c "while true; do echo test; sleep 0.1; done"

等待几分钟后检查：

ls -lh /var/lib/docker/containers/$(docker inspect -f '{{.Id}}' log-test)/*-json.log

你会看到日志被切割成多个小文件，且总大小被严格控制在限制范围内。确认无误后删除测试容器。

建议将日志目录的检查加入日常巡检脚本，每周自动扫描一次，发现超过阈值的日志文件自动告警或清理。

六、写在最后

日志管理是 Docker 运维中最容易被忽视的环节，但一旦出问题就是磁盘满、服务宕机的大事故。笔者强烈建议：新环境第一时间配置全局日志轮转，老环境尽快补上。同时，选择一台磁盘空间充裕、IO 性能稳定的云服务器也至关重要——毕竟日志轮转本身也需要额外的写入开销。对于日志量大的业务，优先考虑将日志外置到独立的日志系统，让 Docker 宿主机轻装上阵。

希望这套方案能帮你彻底摆脱 Docker 日志撑爆磁盘的烦恼。