容器日志悄悄吃满磁盘：三步先定位再清理

刚把一个 Python 小服务放进 Docker 时，我只关心 docker ps 是不是 Up。直到宿主机磁盘报警到百分之九十五，进容器执行 df -h 却发现根分区还很空，才明白空间常常不在容器可写层里，而在宿主机上 Docker 托管的 json 日志。

容器默认使用 json-file 日志驱动。标准输出和标准错误都会追加到路径 /var/lib/docker/containers/容器ID/容器ID-json.log。如果服务在循环里打印调试信息，或者把访问日志也打到 stdout，这个文件会一直变大。你用 docker exec 进去看不到它，所以会出现「容器里还有空间、宿主机却满了」的错位。

我固定用三步排查，都不改业务代码。第一步在宿主机执行 sudo du -sh /var/lib/docker/containers//-json.log，再按大小排序，先看是哪一个容器在写。第二步用 docker ps --no-trunc 对照容器 ID 前缀，确认是自己的服务，而不是系统组件。第三步执行 docker logs --tail 50 容器名，看最近是不是同一行错误在重复刷屏。如果每秒几十次，优先把日志降下来，而不是先删文件。

想限制增长，运行时可以加上参数 --log-opt max-size=10m 和 --log-opt max-file=3。它只对新建容器生效，已经很大的旧文件不会自动缩小。清理前先 docker stop，再处理对应的 json.log，避免运行中直接截断导致日志驱动报错。生产环境更稳妥的做法，是把日志交给采集端，容器本身只保留短期滚动。

给学生做实验时记住一件事就够：stdout 不是免费的。本地练习也给日志设上限；磁盘报警时先找 json.log，确认来源后再决定要不要清。

另外，json.log 里每一行都带时间戳和流类型，不适合当业务日志的长期存档。实验做完记得停掉不用的容器，避免后台进程还在刷日志。