docker日志直接把我的服务器干崩了

被服务器宕机叫醒的早晨

周末早上正睡得香呢，手机突然狂响。一看是监控告警：服务器宕机了。

我心想完了，肯定又是哪个同事在测试环境搞事情，把服务器玩崩了。赶紧爬起来看看什么情况。

image-20250624103941756

一看监控面板，我人都麻了：所有服务都DOWN了！

这台服务器配置虽然一般，但上面基本都是前端项目和一些小服务，按理说不应该有什么问题。怎么突然就全军覆没了？

没办法，先重启服务器再说。

重启后的新发现

服务器重启完，我满心以为Docker容器会自动启动，结果一查看：

image-20250624104315329

这就奇怪了，Docker服务状态显示failed！我明明配置了开机自启动的，怎么Docker本身就启动失败了？

查看Docker启动失败的原因

赶紧看看Docker的启动日志：

sudo journalctl -u docker.service --no-pager | tail -n 100

翻了半天日志，看到了关键信息：No space left on device

磁盘空间不足！这下我明白了，不是服务的问题，是磁盘满了，Docker连启动都启动不了。

确认磁盘使用情况

用df -h检查磁盘使用率：

image-20250624104731624

好家伙，根分区直接100%使用率！

这就解释了为什么Docker启动不了：磁盘都满了，Docker想写个临时文件都写不了，当然启动失败。

找到罪魁祸首

磁盘满了，那得找找是什么东西占了这么多空间。

逐级排查大目录

du -h --max-depth=1 / | sort -hr | head -n 10

image-20250624105115088

一目了然，/var目录占了35G！这个就是大头。

Docker默认把所有数据都存在/var/lib/docker下面，问题应该就在这里。

深入Docker目录查看

继续往下查：

du -h --max-depth=1 /var/lib/docker | sort -hr

image-20250624105818417

看到这个结果我就全明白了：

• containers目录18G - 这里面存的是容器日志
• overlay2目录13G - 这是容器的文件系统层

18G的容器日志！这就是把磁盘撑爆的罪魁祸首。

应急处理

问题找到了，现在得赶紧清理出空间，让Docker能正常启动。

清理容器日志

# 清空所有容器的日志文件
find /var/lib/docker/containers/ -name "*-json.log" -exec truncate -s 0 {} \;

这个命令会把所有容器的日志文件清空，腾出大量空间。用truncate而不是rm的好处是不会删除文件，只是把内容清空，比较安全。

清理完之后，再检查磁盘使用率，应该就恢复正常了。

重启Docker服务

systemctl start docker
docker ps -a

现在Docker应该能正常启动了，容器也能重新跑起来。

治本方案：配置日志限制

临时清理只是救急，要防止以后再出现这种问题，必须配置Docker的日志限制。

全局日志配置

编辑Docker配置文件：

vim /etc/docker/daemon.json

加入这些配置：

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

这个配置的意思：

• 每个日志文件最大100MB
• 最多保留3个历史日志文件
• 超过限制会自动轮转删除

配置完重启Docker：

systemctl restart docker

重要的坑

已经运行的容器不会自动应用新配置！

你得手动重建容器才能让日志限制生效：

docker stop container_name
docker rm container_name
docker run ...  # 重新运行

这会有短暂的服务中断，最好选在业务低峰期操作。

后续预防措施

被这次事故折腾怕了，我现在每次部署Docker都会：

1. 必配日志限制

新环境第一件事就是配置/etc/docker/daemon.json，这已经成为我的标准操作了。

2. 加个磁盘监控

写了个简单的监控脚本，定期检查磁盘使用率：

#!/bin/bash
# 磁盘使用率监控
usage=$(df / | tail -1 | awk '{print $5}' | sed 's/%//')
if [ $usage -gt 80 ]; then
    echo "⚠️ 磁盘使用率 ${usage}%，该清理了！"
    # 可以发个通知提醒
fi

血的教训

这次故障让我认识到：别小看Docker日志配置。

平时看起来不起眼，但是不配置就是个定时炸弹。特别是那些7×24小时运行的服务，日志积累几个月就能把服务器干趴下。

现在我的运维checklist上，Docker日志限制配置是必检项。谁也不想周末早上被宕机告警吵醒啊😂

劝告各位：赶紧检查一下你们的Docker有没有配置日志限制，别等服务器被撑爆了再来找解决方案！