在 Docker 日常运维中，容器运行正常却突然出现磁盘告警，常见原因之一就是日志文件持续增长。Docker 会收集容器写入标准输出和标准错误的数据，再由日志驱动负责保存或转发。如果没有设置轮转、保留数量或外部采集策略，高频访问日志、调试日志和异常堆栈就可能长期堆积。本文将从日志驱动原理、问题定位、配置方法和治理建议几个方面，梳理一套可直接执行的排查流程。🔍
一、先了解 Docker 日志驱动
Docker 日志驱动决定容器日志写到哪里、采用什么格式以及如何被读取。常见驱动包括 json-file、local、journald、syslog、fluentd、gelf 和 awslogs 等。Docker 默认使用 json-file 驱动，将容器标准输出和标准错误保存为宿主机上的 JSON 文件，具体说明可参考 Docker 日志驱动官方文档。
json-file 配置简单，也便于使用 docker logs 查看内容，但默认情况下不会自动限制文件大小。对于持续输出日志的容器，如果没有配置轮转，日志可能不断占用磁盘空间。Docker 官方建议，在不需要兼容特定场景时，可以考虑使用自带轮转能力且存储格式更高效的 local 驱动。
二、确认磁盘是否被容器日志占满
首先在宿主机执行以下命令检查整体磁盘使用情况：
df -h
如果 Docker 数据目录所在分区使用率明显偏高，再执行：
du -h /var/lib/docker/containers --max-depth=2 | sort -h | tail
该命令可以帮助找出占用空间较大的容器目录。
使用 json-file 驱动时，日志通常位于：
/var/lib/docker/containers/<容器ID>/<容器ID>-json.log
可以通过目录中的容器 ID，再结合 docker ps -a --no-trunc 找到对应的容器名称和镜像，从而判断是哪个服务产生了大量日志。
查看当前日志驱动
执行 docker info，检查输出中的 Logging Driver 字段，可确认 Docker 守护进程的默认日志驱动。针对单个容器，还可以执行：
docker inspect -f '{{.HostConfig.LogConfig.Type}}' 容器名称
如需同时查看日志选项，可使用 docker inspect 容器名称，重点检查 HostConfig 下的 LogConfig 内容。
三、排查日志无限增长的常见原因
- 未设置轮转：json-file 没有配置 max-size 和 max-file，单个日志文件会持续增长。
- 配置只改未重建：修改 daemon.json 后，新的默认配置通常只对新创建的容器生效，旧容器不会自动继承。
- Compose 配置覆盖：compose.yaml 中的 logging 配置可能覆盖 Docker 守护进程默认值。
- 应用输出异常：程序启用了 debug 模式、请求日志过于详细，或发生循环报错、频繁重试。
- 日志采集重复：应用同时写文件和标准输出，采集器又重复读取，造成额外存储压力。
- 业务流量突增：轮转配置虽然存在，但保留文件数量或单文件上限设置过大。
四、为 json-file 配置日志轮转
可以在 Linux 宿主机的 /etc/docker/daemon.json 中设置全局默认策略。配置结构示例如下：
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}
其中，max-size 表示单个日志文件达到指定大小后触发轮转，max-file 表示保留的日志文件数量。具体数值应根据日志产生速度、磁盘容量、故障回溯周期和审计要求确定，不宜直接照搬固定参数。需要注意，daemon.json 中的 log-opts 值应写成字符串，例如使用 "3"，而不是数字 3。
修改前应先检查 daemon.json 是否已有 registry-mirrors、data-root 或其他配置，避免覆盖原内容。完成后可执行：
dockerd --validate --config-file=/etc/docker/daemon.json
确认格式有效，再通过 systemctl restart docker 重启 Docker。重启可能影响正在运行的业务，应安排维护窗口并提前评估。
让配置真正应用到容器
全局日志配置不会自动改变已经创建的容器。使用 Docker Compose 部署时，可以在确认业务允许后执行：
docker compose up -d --force-recreate
重建完成后，再次使用 docker inspect 检查 LogConfig，确认 max-size、max-file 和驱动类型均符合预期。⚙️
五、使用 local 驱动降低本地日志风险
如果日志主要用于 docker logs 查询，不要求直接处理底层 JSON 文件，可以考虑将默认驱动改为 local：
{
"log-driver": "local"
}
local 驱动默认具备日志轮转机制，并采用更高效的内部存储格式。其行为和可配置选项可查看 来源链接 日志驱动说明。
需要强调的是，Docker 管理的日志文件不应被外部工具直接修改或长期占用。手工删除正在写入的日志文件可能出现空间没有立即释放、文件句柄仍被进程持有等情况。紧急处置时，可以先停止对应容器，再清理日志并重建容器；长期解决方案仍然是配置轮转、降低应用日志级别并建立磁盘告警。
六、生产环境的治理建议
- 为每类服务制定日志级别，生产环境避免长期启用 debug 或 trace。
- 统一配置日志轮转，并通过自动化脚本检查新容器是否继承策略。
- 监控宿主机磁盘使用率、日志目录增长速度和容器异常重启次数。
- 需要长期检索时，将日志发送到集中式平台，而不是无限保留在单机。
- 定期检查异常堆栈、连接失败和重试日志，从源头修复高频输出问题。
- 变更日志驱动前验证 docker logs、监控代理和审计流程是否兼容。
总结
Docker 日志文件无限增长通常不是单一故障，而是默认驱动未限制、旧容器未重建、应用日志异常或监控缺失共同造成的结果。✅ 推荐按照“检查磁盘占用、定位容器、确认日志驱动、核对轮转参数、重建验证、持续监控”的顺序处理。与其在磁盘告警后临时清空文件，不如提前配置合适的日志驱动和保留策略，并结合集中采集与应用侧降噪，形成稳定、可追踪的容器日志管理方案。
