当服务器磁盘突然告警，而镜像、Volume 和容器可写层看起来并不大时，问题往往藏在 Docker 容器日志中。Docker 默认使用 json-file 日志驱动，将容器的标准输出和标准错误持续写入宿主机；如果没有配置大小限制，高频日志可能长期累积，最终占满磁盘。🔍

一、先确认是否真的是容器日志占用空间

首先执行 df -h 查看各挂载点使用率，重点关注 Docker 数据目录所在分区。默认情况下，Linux 上的 Docker 数据通常位于 /var/lib/docker，但实际位置应以 docker info 输出的 Docker Root Dir 为准。

docker info | grep -E "Docker Root Dir|Logging Driver"
sudo du -xh /var/lib/docker --max-depth=2 | sort -h | tail -30

如果 containers 目录占用异常，可以进一步定位体积最大的容器目录和日志文件：

sudo find /var/lib/docker/containers -name "*-json.log" -type f -printf "%s %p\n" | sort -nr | head -20

日志文件通常位于 /var/lib/docker/containers/容器ID/容器ID-json.log。还可以通过文件路径中的容器 ID 反查容器名称：

docker ps -a --no-trunc | grep 容器ID

二、为什么日志轮转配置会“失效”

1. 配置只对新建容器生效

这是最常见的原因。修改 /etc/docker/daemon.json 并重启 Docker 后，新的默认日志策略只会应用于之后创建的容器，已经存在的容器不会自动继承新配置。仅执行 docker restart 重启旧容器通常没有作用，必须重新创建容器。Docker 日志驱动配置文档对此有明确说明。

2. log-opts 的值没有写成字符串

daemon.json 中的日志选项必须使用字符串。即使 max-file 看起来是数字，也应写成带引号的形式，否则可能导致配置校验失败或 Docker 服务无法正常启动。

{
"log-driver": "json-file",
"log-opts": {
"max-size": "50m",
"max-file": "5"
}
}

其中，max-size 表示单个日志文件达到指定大小后轮转，max-file 表示保留的日志文件数量。需要注意，max-file 只有与 max-size 同时设置时才具有实际轮转意义。参数说明可参考 json-file 官方文档。

3. Compose 或启动参数覆盖了全局配置

如果 docker-compose.yml、Compose 配置或 docker run 命令中单独指定了 logging，那么容器级设置会覆盖 daemon.json 的默认值。排查时不要只检查全局配置，还要查看目标容器真正采用的日志驱动和参数。

docker inspect --format='{{json .HostConfig.LogConfig}}' 容器名称

若输出中的 Config 为空，通常表示容器创建时没有写入轮转参数；若 Type 不是 json-file，则应按照对应日志驱动的规则继续排查。还要检查 Compose 文件中是否存在 logging、driver、options、max-size 或 max-file 等配置。

4. 修改了错误的配置位置

普通 Linux Docker Engine 常用 /etc/docker/daemon.json，Rootless 模式、Docker Desktop 或自定义 dockerd 启动方式可能读取其他位置。可以检查 Docker 服务启动参数，确认是否通过 --config-file 指定了配置文件，同时留意 systemd 参数与 daemon.json 之间是否存在冲突。

systemctl cat docker
ps -ef | grep "[d]ockerd"

三、正确应用并验证轮转配置

修改配置后，先校验 JSON 和 Docker 配置，避免因为逗号、引号或字段冲突导致服务启动失败：

sudo dockerd --validate --config-file=/etc/docker/daemon.json

校验通过后重启 Docker，并检查服务状态与错误日志：

sudo systemctl restart docker
sudo systemctl status docker --no-pager
sudo journalctl -u docker -n 100 --no-pager

随后重新创建旧容器。使用 Compose 时可执行 docker compose up -d --force-recreate；直接使用 docker run 部署时，应先保存原有启动参数，再删除并按新配置创建容器。重建完成后，再次使用 docker inspect 核对 LogConfig，而不是仅凭 daemon.json 判断配置已经生效。✅

四、磁盘已满时如何应急处理

优先暂停产生海量日志的业务或降低应用日志级别，然后再释放空间。不要直接删除正在被 Docker 持有的日志文件，因为进程可能继续占用已删除文件的文件描述符，磁盘空间未必立即归还。Docker 官方也提醒，json-file 文件应由 Docker 守护进程管理，不建议使用外部工具直接干预。

紧急情况下，可以谨慎清空已确认的超大日志文件：

sudo truncate -s 0 /var/lib/docker/containers/容器ID/容器ID-json.log

执行前应确认文件确实属于目标容器，同时评估日志丢失对审计和故障分析的影响。清空后使用 df -h 验证空间是否释放；若空间仍未恢复，可通过 lsof +L1 检查是否存在已删除但仍被进程占用的文件。

五、建立长期防护机制

• 为 json-file 同时设置合理的 max-size 和 max-file，并根据容器数量、磁盘容量及日志增长速度调整。
• 在 Compose 项目中显式声明 logging，减少环境迁移后默认策略不一致的问题。
• 定期监控 Docker 数据目录、日志文件增长速度和磁盘剩余空间，设置分级告警。📊
• 从应用侧控制无意义的调试日志，避免在循环中持续输出大段内容或完整请求体。
• 不依赖本地文件长期保存关键日志，应按业务需要接入集中式日志平台。
• 对于不要求兼容 json-file 的场景，可评估 Docker 推荐的 local 日志驱动，它默认具备轮转能力，并采用更高效的存储格式。

总结

排查 Docker 日志占满磁盘，关键路径是：先确认 Docker 根目录和最大日志文件，再检查容器实际 LogConfig，随后验证 daemon.json、容器级覆盖项及配置生效范围。日志轮转“失效”多数不是参数本身无效，而是旧容器未重建、选项类型错误、Compose 覆盖全局设置，或修改了错误的配置文件。完成应急清理后，还应通过日志限额、磁盘监控和应用侧降噪形成闭环，避免同类故障再次发生。🛡️