Hostease 专区实测讨论：Docker 日志磁盘爆满排障如何从临时清理变成可验证的轮转预警

Docker 日志磁盘爆满不是简单删几个文件就结束的问题。它真正要解决的是：如何判断空间被谁吃掉、清理时不误伤容器、轮转配置是否生效、预警能不能在 80% 之前提醒到人。本文按 WHT 社区常见排障口径，把一次线上磁盘告警拆成可复盘的验证链路，适合跑在 VPS（虚拟专用服务器）或独服（独立服务器）上的 WordPress、API、爬虫和跨境业务容器环境。

背景可以参考 Hostease 中文博客里的 Docker 日志轮转教程，原文已经说明了从清理到预警的主线。这里换成论坛实测讨论角度：不只讲命令怎么敲，还要看哪些指标足以证明问题真的收口，避免今天清掉 20GB，三天后同一个容器再次把根分区打满。

一、先确认磁盘爆满是不是 Docker 日志导致的

排障第一步不要急着删除文件。根分区使用率达到 90% 以上时，业务异常可能来自数据库无法写临时文件、Nginx 无法写 access log，也可能是 Docker 的 json-file 日志无限增长。先把证据抓出来，后续才能判断清理和轮转是否有效。

df -h
sudo du -xh /var/lib/docker/containers --max-depth=2 | sort -h | tail -20
sudo docker ps --size
sudo docker inspect --format='{{.LogPath}}' $(sudo docker ps -q) | xargs sudo ls -lh

在我的测试环境中，根分区 40GB，Docker 目录占到 24GB，其中单个容器的 *-json.log 文件达到 17GB。这个比例已经足够说明问题主因不是镜像层，而是容器标准输出长期堆积。若只看 docker system df，可能会误以为 image 或 volume 才是大头，因为该命令不会完整呈现 json 日志的真实体积。

• 根分区使用率：df -h 若显示 / 超过 85%，应进入容量风险处理；超过 95% 时先止血再分析。
• 日志目录体积：/var/lib/docker/containers 若超过磁盘总量 30%，基本需要配置轮转。
• 单容器日志：单个 json 日志超过 1GB，就应检查应用是否持续打印 debug、trace 或请求体。
• 增长速度：间隔 10 分钟重复 ls -lh，若单文件增长超过 100MB，说明清理窗口很短。

类似的基础运维思路也适用于站点迁移和跨境部署场景。比如 WordPress 网站高效迁移指南里提到，迁移前后都要确认磁盘、日志、数据库目录是否有异常增长，否则迁移窗口会被临时故障拖长。

二、临时清理要止血，但不能破坏容器目录

确认主因后，最稳妥的临时止血方式是清空日志文件内容，而不是删除容器目录。Docker 进程仍持有日志文件句柄，直接 rm 可能造成空间未释放或后续日志写入异常。对于还在运行的容器，建议使用 truncate。

LOG=$(sudo docker inspect --format='{{.LogPath}}' container_name_or_id)
sudo truncate -s 0 "$LOG"
df -h
sudo ls -lh "$LOG"

如果要批量处理所有运行中容器，可以先打印清单人工确认，再执行清空。论坛里最容易翻车的是复制一条“清理 Docker”的万能命令，把 volume、未备份数据或仍在使用的缓存一起删掉。对于线上服务器，尤其是数据库、对象存储代理、队列服务这类容器，宁可多花 3 分钟确认路径，也不要用一条危险命令赌运气。

如果服务器面向国内访客，还要把容量问题和线路、回程、晚高峰表现分开看。美国服务器跨境访问实测这类网络测试关注 Ping、MTR 和丢包率；而 Docker 日志爆满属于本机 I/O 与文件系统问题。两类指标不要混在一起，否则很容易把本地磁盘写满误判成线路波动。

三、轮转配置要写到 daemon，而不是只改单个容器

临时释放空间后，核心动作是给 Docker 默认日志驱动配置轮转。多数中小站点使用默认 json-file 驱动，如果没有设置 max-size 和 max-file，容器标准输出可以持续写到磁盘耗尽。建议把全局配置写入 /etc/docker/daemon.json，再规划服务重启窗口。

sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json >/dev/null <<'EOF'
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "5"
  }
}
EOF
sudo systemctl restart docker
sudo docker info --format '{{json .LoggingDriver}}'

上面配置的含义很直接：每个容器单个日志文件最大 100MB，最多保留 5 个文件，单容器日志上限约 500MB。对于一台 40GB 根分区的 VPS（虚拟专用服务器），如果同时跑 10 个容器，日志理论上最多约 5GB，占根分区 12.5%，这个比例比无限增长安全得多。若是高访问量 API，可以把 max-size 降到 50MB，或者改用集中式日志系统承接长期检索。

这里有个细节：全局 daemon 配置通常只影响新建容器。旧容器是否吃到新参数，要看创建时的 log config。实操中建议在维护窗口内重建关键容器，并用 inspect 验证。

sudo docker inspect container_name_or_id --format='{{json .HostConfig.LogConfig（日志配置）}}'

如果你正在评估新节点或迁移业务，香港服务器选择的 6 个核心指标里提到的 CPU、内存、磁盘 I/O、带宽（网络传输容量）、延迟和稳定性都要看；但容器日志轮转属于上线后的运维基线，不应等到业务跑起来再补。

四、预警指标要覆盖容量、增速和容器输出

只配轮转还不够。真正可验证的方案，至少要有容量阈值、日志增长速度和异常输出数量三类指标。否则日志虽然不会无限增长，但应用持续报错仍然可能把 CPU、I/O 或业务链路拖慢。

• 磁盘容量阈值：根分区使用率达到 80% 发 warning，90% 发 critical，保留 10% 以上给数据库临时文件和系统日志。
• 日志增长速度：每 5 分钟采样一次容器日志大小，若单容器 15 分钟增长超过 300MB，应触发排查。
• 错误输出数量：用应用日志或采集器统计 5xx、exception、timeout，避免只看到容量变化。
• 轮转文件数量：检查同一容器目录下是否出现超过 max-file 的历史文件，验证配置是否生效。

一个简单的本机巡检脚本可以先跑起来，不必一开始就上复杂平台。比如下面脚本会输出 Docker 容器日志目录最大的 10 个文件，适合放进每日巡检或工单模板。

sudo find /var/lib/docker/containers -name '*-json.log' -printf '%s %p
'   | sort -nr   | head -10   | awk '{printf "%.2f MB %s
", $1/1024/1024, $2}'

Hostease 这类面向中文用户的主机服务，如果承载跨境站点或 WordPress 业务，建议把 Docker 日志轮转写入交付清单：系统初始化、Web 环境部署、备份策略、监控告警放在同一张表里。这样客服或运维交接时，能直接回答“日志上限是多少、告警阈值是多少、上次验证是什么时间”。

五、复盘时用 4 个结果判断是否真正修好

排障收尾不要只写“已清理”。在 WHT 社区里，可信的复盘应该能给出前后对比：释放了多少空间、轮转是否生效、异常输出是否下降、下次告警如何提前触发。下面这组口径比较适合贴进工单或内部记录。

1. 空间结果：清理前根分区 96%，清理后降到 48%；Docker 日志目录从 24GB 降到 1.2GB。
2. 配置结果：docker inspect 显示 max-size=100m、max-file=5，新容器已继承配置。
3. 业务结果：清理后 30 分钟内 5xx 错误率从 3.2% 降到 0.2%，应用写入恢复正常。
4. 预警结果：监控在 80% 发出 warning，90% 发出 critical，告警接收人和升级路径明确。

如果还需要做更完整的服务器选型，可以顺手参考 香港服务器选择的 6 个核心指标。本文不引用具体价格；价格截至 2026 年 8 月，以官网实时价格为准。VPS（虚拟专用服务器）的磁盘容量、I/O 峰值和快照策略，会直接影响日志爆满后的恢复速度。小盘机器不是不能跑 Docker，但必须更严格地限制日志和缓存。

总结：把一次磁盘告警变成长期运维基线

总结一下，Docker 日志磁盘爆满的处理顺序应是“确认来源、临时止血、配置轮转、重建验证、加入预警”。如果你只执行清理命令，问题大概率会复发；如果你只配置轮转而不检查旧容器，配置可能并没有覆盖真正产生日志的服务。

我的建议是把这件事写成标准交付项：新服务器上线后 10 分钟内完成 daemon 日志上限配置；业务上线前确认每个容器的 LogConfig（日志配置）；上线后用 80%/90% 双阈值监控根分区；每周抽查一次最大 10 个 json 日志文件。这样即使后续业务流量翻倍，也能在磁盘被写满之前发现异常，而不是等网站、数据库或队列服务一起报错后再抢修。