Docker 容器日志吃满磁盘？三种根治方案与取舍

一、先看清楚是谁在写

磁盘写满先别急着删文件，两条命令定位：

du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail -5
docker inspect --format '{{.Name}} {{.HostConfig.LogConfig.Type}}' $(docker ps -q)

第一条按大小列出每个容器的 json 日志，第二条确认它用的是哪种日志驱动。很多人到这一步直接 rm，但进程还握着文件句柄，inode 不释放，du 变小而 df 不变，看着像没生效。要立刻回收空间用 truncate -s 0，或者重启那个容器。

二、三种根治方案

方案 A：单容器限流

在 compose 里给容器单独加日志上限：

services:
  app:
    logging:
      driver: json-file
      options:
        max-size: "50m"
        max-file: "3"

单个容器最多占 150 MB，改完要重建容器才生效。粒度细，但每个新服务都得记得写，容易漏。

方案 B：daemon 层默认值

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "50m", "max-file": "3" }
}

写进 /etc/docker/daemon.json 后执行 systemctl reload docker。两个坑：只对之后新建的容器生效，存量容器仍按旧配置继续写；文件必须是合法 JSON，写坏了 Docker 直接起不来，reload 前先用 python -m json.tool 校验一遍。

方案 C：日志外送，本地不留

{ "log-driver": "journald" }

日志交给 journald，本地不再生成 *-json.log，容量由 SystemMaxUse 统一约束，检索改用 journalctl CONTAINER_NAME=app。代价是那些直接 tail json 文件的采集脚本和告警规则都要跟着改，换驱动前先确认下游。

三、怎么选

单机、容器不多：方案 B 打底，方案 A 给话多的服务单独收紧。

已经有 journald 或集中日志：方案 C，别让 Docker 再写一份。

排障依赖 docker logs：用 A 或 B，别用 none 驱动图省事——出问题时你会失去唯一的一手证据。

四、收尾自检

docker inspect --format '{{.HostConfig.LogConfig}}' app

确认配置真的落到了容器上，再看一眼 df -h。日志不是不能长，是必须有上限；上限配在哪一层，决定了你下次是被磁盘告警叫醒，还是被日志直接叫醒。