Docker 日志把磁盘打满了？三招管住容器日志

刚接触 Docker 的人常踩一个坑：服务跑着跑着，服务器磁盘突然满了，查半天发现是某个容器的日志文件长到了几十 GB。Docker 默认不对容器日志做轮转，docker logs 看到的输出会一直往宿主机的 json-file 里写，时间一长就是隐患。下面三招，从急救到根治。

第一招，先定位是谁在写。磁盘满了别急着删，先用 df -h 看哪个分区满了，再用 du -sh /var/lib/docker/containers/*/*-json.log 找出最大的日志文件。找到容器后，docker ps 对一下容器名，就知道是哪个服务在刷日志。很多时候是某个服务把 DEBUG 级别日志全开，或者在死循环里报错，一秒几十行。

第二招，急救：截断而不是删除。正在运行的容器别直接 rm 它的日志文件——文件句柄还被 Docker 占着，删了空间也不释放。正确做法是截断：truncate -s 0 /var/lib/docker/containers/<容器ID>/*-json.log，或者 echo "" > <日志路径>。空间立刻回来，服务不用重启。但这只是止血，日志还会继续长。

第三招，根治：给日志加上轮转。新建容器时带上参数：--log-opt max-size=10m --log-opt max-file=3，意思是单个日志文件最多 10MB，最多保留 3 个，超了自动轮转删除旧的。已经跑起来的容器改不了日志驱动，办法是写进 compose 文件的 logging 小节：

logging:
  driver: json-file
  options:
    max-size: "10m"
    max-file: "3"

然后 docker compose up -d 重建一次。生产环境建议再进一步：日志级别调到 INFO，只记关键事件；需要长期留存的日志交给专门的日志服务（如 Loki、Elasticsearch），别让宿主机磁盘当日志仓库。

一句话总结：先 du 定位、再截断止血、最后用 max-size + max-file 根治。容器日志不管，就等于给磁盘埋了个定时炸弹。