修改 daemon.json，给 Docker 加上 max-size 和 max-file，重启服务后磁盘还在涨，很可能是旧容器仍然使用创建时的日志配置。Docker 守护进程的默认设置只影响之后创建的容器，已有容器需要重建才能采用新设置。单独执行 docker restart 不会改变容器的日志驱动和选项。
还有一种常见情况：应用把日志写进容器内的文件或挂载目录，Docker 的标准输出日志轮转根本没有接管这些文件。排查要先确认增长的是哪一份日志，再决定是否重建容器。
本文面向 Linux 上的 Docker Engine 与 Compose V2，聚焦 json-file 和 local 驱动。Docker Desktop、Rootless Docker、远程 Docker context 的数据路径和服务管理方式可能不同；Kubernetes 的容器日志也不应直接套用这套流程。文中命令为示例，没有在读者的服务器上执行。
先读取运行容器的实际日志配置
以下命令在具有 Docker 管理权限的终端执行。web 是示例容器名，要替换为实际名称；Docker 权限通常意味着较高的主机控制能力，不应随意授权。
docker context show
docker info --format '{{.LoggingDriver}}'
docker inspect --format '{{json .HostConfig.LogConfig}}' web
docker inspect --format '{{.LogPath}}' web
docker info 显示当前连接的守护进程默认驱动；docker inspect 显示指定容器创建时采用的实际配置。两者不同完全可能。也要确认 context 指向预期服务器，避免本机改配置、检查时却连接了远程 Docker。
例如容器返回 Type 为 json-file、Config 为空，说明没有显式配置日志选项。这个驱动的 max-size 默认不设上限。如果 Compose 文件里已经出现限制，而 inspect 仍是旧值，就要检查部署使用的 Compose 文件、覆盖文件，以及容器是否确实重建。
LogPath 用于定位，不能据此直接编辑日志文件。Docker 官方提醒，这些内部文件由守护进程独占管理，外部删除、截断或 logrotate 操作可能干扰日志系统。
区分 Docker 输出日志和应用自己的文件
json-file、local 捕获容器的标准输出和标准错误。应用写入 /app/logs/app.log，再通过挂载保存到宿主机的文件，不受这些驱动的 max-size 控制。
docker inspect --format '{{json .Mounts}}' web
docker logs --tail 100 --timestamps web
df -h
df -i
对比最近日志内容、挂载目录和磁盘增长位置。不要对整个 Docker 数据目录执行删除操作，也不要把卷数据误当作日志。若要用 du 观察大小，应在宿主机上对已经确认的目录进行只读统计；大目录遍历会带来 I/O 开销，繁忙时应控制范围。
如果增长的是应用文件，应使用应用自带的轮转机制，或为相应挂载目录设计独立的轮转方案。应用是否会重新打开文件、是否支持轮转信号，必须查对应程序文档。只轮转 Docker 标准输出不会解决这一层的问题。
先在一个 Compose 服务上设置限制
对少量现有服务，直接在 Compose 中声明日志配置，通常比为了改默认值而重启整个 Docker 更便于控制影响范围。把下面内容合并到现有服务定义，保留原来的镜像、端口、环境变量和挂载，不能拿片段覆盖完整文件。
services:
web:
logging:
driver: json-file
options:
max-size: "20m"
max-file: "5"
日志选项按字符串填写。max-file 要与有限的 max-size 配合使用，达到大小阈值后才会发生对应轮转。
这里的参数是容量示例，不能直接理解为“保留五天”。若一个容器持续每小时输出 10 MiB，约 100 MiB 的轮转预算只能覆盖约十小时；这是估算示例，实际还受日志条目、轮转时机和实现开销影响。确定参数前，需要先明确排错或审计所需的时间窗口。
修改前备份 Compose 源文件，随后检查最终合并结果：
docker compose config --quiet
docker compose config
使用 -f、--env-file、profiles 或不同项目名部署的环境，检查和更新时都应带上原来的参数。配置输出可能含有展开的环境变量与凭据，不要公开粘贴。
旧容器需要重建，重启不够
重建会替换容器，也会影响服务可用性。操作前确认应用数据已经存入命名卷或明确的绑定挂载，完成数据备份与恢复检查；容器可写层中的数据不能指望重建后保留。匿名卷也需要单独核对生命周期与复用方式。
对单个 Compose 服务，在维护窗口内可按实际部署参数执行：
docker compose up -d --no-deps --force-recreate web
这会强制重建指定服务；--no-deps 避免同时启动其依赖，不代表整个操作无停机。单实例 Web 服务仍可能出现短暂中断，有状态服务还要遵循数据库或应用的停机流程。
不需要为修改一个服务的日志设置先执行全项目 down，更不要添加 down -v。后者会删除对应卷，风险远超日志配置调整。也不要使用 docker system prune --volumes 作为这类问题的通用修复。
重建前若需要保存历史日志，应导出有用的时间范围到空间充足且访问受控的位置。历史日志可能含令牌、用户信息，不宜随意复制；移除旧容器后，不能再依赖它提供原来的本地日志。
回滚时恢复原 Compose 定义，再按同样范围重建，并验证业务。配置回滚无法恢复已经随旧容器删除的可写层数据和日志，因此前置备份必须独立完成。
全局默认值与服务配置怎样配合
如果要为今后创建的容器设置默认限制，可把下面键合并到 Docker 的实际守护进程配置文件。常规系统级安装常用 /etc/docker/daemon.json，Rootless 或自定义启动参数可能使用其他位置。
{
"log-driver": "json-file",
"log-opts": {
"max-size": "20m",
"max-file": "5"
}
}
编辑前备份文件，保留现有镜像源、存储和网络配置。启动参数与配置文件若重复声明同一选项，也可能导致启动失败。支持该参数的 Docker Engine 可用下列方式验证文件，再安排维护窗口让守护进程加载新配置：
sudo dockerd --validate --config-file=/etc/docker/daemon.json
不要把重启 Docker 当作只影响日志的小操作。它可能影响该主机上的所有容器，是否配置并满足 live-restore 条件也需要事先确认。应用全局默认值后，仍需逐批重建旧容器；服务显式声明的日志配置则应按该服务自己的设置核验。
Docker 官方在不需要 json-file 兼容性的场景下推荐考虑 local 驱动，它默认支持轮转并使用更节省空间的内部格式。不过切换前要核对日志采集链路：直接读取 *-json.log 的采集器不能假定兼容 local。不要把 local 内部文件交给普通文本工具处理，也不要把不同驱动的选项原样互换。
怎样证明轮转已经生效
更新后再次读取运行容器：
docker compose ps
docker inspect --format '{{json .HostConfig.LogConfig}}' web
docker logs --since 10m --tail 100 web
先确认容器 ID 或创建时间已更新，实际 LogConfig 与预期一致，再检查健康状态、HTTP 响应及关键业务操作。容器状态是 running，只能表明主进程仍在运行。
在正常流量下持续观察磁盘占用，或在隔离测试环境中用受控的日志输出验证阈值。不要在生产环境通过大量打印日志来“压测轮转”。小流量服务短时间没有轮转很正常，因为尚未达到大小阈值。
docker system df 可辅助观察镜像、容器和卷，但不能代替对日志文件系统的独立容量监控。仍需监控磁盘可用空间、inode，以及应用是否突然开启了高频 DEBUG 输出。
如果配置已正确、容器也已重建，而容量继续异常增长，排查方向应转向应用文件日志、其他容器、集中采集缓冲和日志输出量。大小限制会淘汰较早日志；需要长期留存时，必须另行设计集中存储与保留策略，不能靠增大本地轮转额度无限延长。
官方参考
- Docker：配置日志驱动及默认值的生效范围
- Docker：json-file 日志驱动与轮转选项
- Docker：local 日志驱动
- Docker：docker compose up 与强制重建参数
资料核验日期：2026 年 10 月 20 日。