Docker 日志把磁盘写满怎么办json-file 限制和清理方案分类运维知识磁盘突然 100%一查发现不是数据库也不是上传文件而是某个容器的 json 日志写了几十 G。这种问题很常见而且会拖垮整台机器。本文给出临时止血、长期限制和排查顺序。摘要适合 Docker 服务多、日志增长快的服务器读完能设置日志大小上限。适合场景和不适合场景适合一台机器跑多个 Compose 项目容器日志经常刷屏需要避免磁盘被单个服务写满不适合需要集中日志审计的平台日志必须长期完整保留的合规场景已经使用 Loki/ELK 的成熟环境这一步要先讲清楚是因为很多服务器教程只告诉你“怎么装”却不告诉你“该不该装”。如果场景不匹配后面配置写得再漂亮也只是把问题推迟到上线之后。配置和成本怎么取舍日志治理不吃配置1 核 2G 都能做。关键是提前限制而不是等磁盘满了再删。系统盘小于 40G 的服务器尤其要设置 Docker log opts。我会把 Docker 日志治理 放在雨云服务器 rainyun-com的 云服务器上处理多容器日志轮转几乎没有额外压力。注册填优惠码2026off领 5折这类配置更适合先稳定跑起来再按真实负载升级。准备工作准备一台干净的 Ubuntu 22.04 或 Debian 12 服务器先确认 SSH、时间同步和防火墙状态。规划目录/opt/docker-logs-fill-disk-20260601。配置、数据、备份脚本都放在同一主题目录下后面迁移更省事。根据主题放行端口local。游戏和网络服务尤其要分清 TCP/UDP。先用测试数据跑通再导入正式数据或邀请其他人使用。核心配置下面配置用于说明关键项发布前要按当前官方文档确认镜像版本、环境变量和端口。{log-driver:json-file,log-opts:{max-size:50m,max-file:3}}怎么确认真的可用执行docker inspect 容器名 --format {{.LogPath}}找日志文件再用du -h看大小。设置后新日志应按 max-size 轮转。验证时不要只看进程是否存在至少完成一次真实动作游戏服要让外部玩家连接应用要登录并写入一条数据运维项要确认状态变化真的生效。这样能提前发现端口、权限、反代和路径问题。踩坑清单不要直接删除正在被 Docker 占用的 json 日志文件后就以为完事。更稳妥是 truncate 清空随后设置 daemon.json 并重启 Docker。排查建议按这个顺序来看日志里第一条明确错误不要只看最后一屏。查端口监听和云安全组确认协议没有写错。检查数据目录权限尤其是容器用户和宿主机目录映射。回滚到上一个能工作的配置再逐项恢复新改动。备份、升级和迁移日志通常不需要全量备份但关键业务日志应发送到独立日志系统不要只留在容器本机。维护时建议保留一份“最小恢复说明”需要哪些文件、恢复命令是什么、域名和端口在哪里改。等真正出问题时人通常没那么冷静清单比记忆可靠。总结Docker 日志治理是低成本高收益的运维动作越早做越不容易遇到磁盘满的深夜事故。