Docker 日志占满磁盘怎么办？日志驱动、轮转与保留策略
磁盘变满先确认日志来自哪里
本文适用于 Linux Docker Engine 与当前 Compose 插件。容器通常把标准输出和标准错误交给日志驱动，但应用也可能另外写文件到挂载目录。先看主机磁盘与 inode，再区分镜像、数据卷、应用文件和容器日志，不能看到 Docker 目录大就判断全是日志。
用下面的只读命令查看具体容器的日志设置及最近输出。把 app 换成实际容器名称；Compose 服务名与生成的容器名称可能不同。日志可能包含个人数据或凭据，排查记录应进行脱敏。
docker inspect --format '{{json .HostConfig.LogConfig}}' app
docker logs --since 10m --tail 200 app
如果短时间重复输出同一连接错误，应同时修复应用重试和日志级别。轮转可以限制占用，却不会减少故障产生的负载。应用自行写入数据卷的日志，需要它自己的轮转策略，Docker 的标准输出设置不会自动管理这些文件。
给保留窗口设置明确边界
默认 json-file 日志驱动在没有配置上限时可能持续增长。Docker 对常规场景也建议考虑自带轮转的 local 驱动；已有采集系统依赖特定驱动时，应先检查兼容性再换。以下示例保留 json-file，方便在现有服务上理解限制项。Docker 日志驱动说明
把片段合并到现有 Compose 服务的配置中，不要用它覆盖完整服务定义：
services:
app:
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
max-size 控制轮转大小，max-file 控制保留文件数量且需要配合大小限制。选值应结合每分钟增长量与排错时需要回看的时段，而非认为三份文件就代表三天。这里的数值是示例，实际空间还受日志实现及其他文件影响。json-file 配置选项
重新创建才会采用新的设置
日志设置属于容器创建时的配置。修改 Compose 文件后仅执行 restart，或修改守护进程默认配置后只重启旧容器，都不能保证旧容器获得新设置。先用 docker compose config --quiet 检查配置，再安排目标服务按现有部署流程重建。
重建之前，核对镜像版本、环境设置、端口与持久卷，确认重要数据没有只放在容器可写层，并保留需要追溯的日志。对有流量的服务，采用已有切换或维护窗口方案；不要为了一个服务的日志问题重建整套数据库和网站。
用增长趋势验证而非等待再次满盘
重建后再次检查实际容器的 LogConfig，确认驱动和两个选项与预期相同，再观察正常业务产生的日志及磁盘增长。不要在生产环境制造大量输出来强行触发轮转；可以在测试服务验证边界，再通过日常增长确认线上效果。
轮转会淘汰最旧记录。需要长时间保留的审计信息应送到权限受控的集中存储，并检查采集延迟与断线补偿。减少本地保留量前先确认历史已被接收，不能把磁盘问题转化成事故发生后无日志可查。
避免直接处理 Docker 管理的文件
Docker 官方明确提醒，底层 JSON 日志文件由守护进程管理，外部工具直接修改可能干扰日志系统。因此不要把删除或截断 Docker 目录中的文件作为常规操作，也不要顺手执行全局清理卷命令。紧急空间不足时，先限制异常输出并按受控流程处理目标容器。
如果新驱动导致采集异常，恢复原日志设置并重新创建该服务，检查采集恢复和应用状态。配置回退无法恢复已轮转删除的旧日志，所以恢复材料与保留策略应在实施前准备好。最终记录每个关键服务的日志来源、上限与归档去向。