清晨收到华为云磁盘告警短信，发现是Docker日志悄悄把系统盘吃光了

平时做个人开发，最容易被遗忘的就是服务器磁盘空间。手头那台跑着几个测试容器的华为云服务器买了有大半年，平时只要接口还能访问，我基本很少特意登上去看系统状态。

前几天早晨刚睡醒，手机突然收到一条华为云监控发来的短信，提示系统盘使用率已经超过了90%。连上SSH敲了个df -h，40G的系统盘只剩下不到800M可用空间。当时我第一反应是代码里是不是有哪个脚本陷入死循环在拼命写临时文件，顺着目录一层层往下排查，结果发现罪魁祸首竟然是Docker默认生成的容器日志。

花了半个上午把磁盘空间腾出来并彻底锁死日志上限，记录一下排查细节和处理姿势，省得以后换新服务器又踩同一颗雷。

第一个坑是千万不要看到大日志文件就随手敲rm删除。
我用du -sh一步步往里挖，很快就定位到了/var/lib/docker/containers目录，里面有两三个运行了小半年的容器，每个目录底下都躺着一个快十个G的json.log日志文件。
很多人的第一反应是直接rm -rf把这个大文件删掉。但在Linux下，如果写日志的容器进程还在运行，文件句柄被占用，你直接执行rm，虽然文件名在目录里看不到了，但操作系统并不会真正释放磁盘块空间，df -h看到的占用依然是满的。更麻烦的是，容器还在继续往被删除的文件句柄里写数据，找起来更费劲。
正确的应急清空方式是用截断命令。在终端里对准那个长长串名字的日志文件执行truncate -s 0或者cat /dev/null直接重定向过去。这样文件句柄不丢，文件大小瞬间被置零，磁盘空间也能在几秒钟之内立即实打实地释放出来。

第二个关键步骤是改全局配置，别指望自己每次起容器都记得加参数。
把现存的大日志清空只能救急，如果不从根源上控制，过几个月磁盘还是会被慢刀子割肉一样吃满。
Docker默认的日志驱动（json-file）如果不特意干预，是完全不设大小上限的，容器里的应用只要往控制台stdout打印一行，它就老老实实往磁盘记一行，直到把硬盘撑爆为止。
虽然在写docker-compose文件时可以在logging字段里指定大小，但我经常随手docker run跑个临时容器测试，很容易忘记加参数。最省心的做法是直接改全局的/etc/docker/daemon.json。
在配置文件里加上log-driver为json-file，并且把log-opts里的max-size设为20m，max-file设为3。配好之后重启一下Docker服务。这样以后不论是用命令随手跑的容器，还是compose编排的项目，单个容器的日志文件最多只允许写20M，超过就会自动轮转切片，最多保留3个历史文件。从全局底层把日志膨胀的口子彻底堵死。

第三个细节是清理那些堆积如山的虚悬镜像和构建缓存。
处理完日志后，我发现磁盘空间虽然回落了不少，但Docker整体占用的空间依然有点虚高。
平时在服务器上直接打镜像或者拉新版本，老的镜像标签就会变成none，也就是所谓的虚悬镜像（dangling images），悄悄藏在磁盘深处；而且每次执行docker build产生的构建层缓存，长年累月下来也能吃掉好几个G。
在控制台执行docker system df，就能一目了然看清楚镜像、容器和缓存各自占了多少空间。
确认现有的生产容器都在正常跑之后，执行一次docker system prune，把无用的虚悬镜像、已停止的陈旧容器和构建缓存一口气清干净。这里稍微注意一点，如果不想误删没挂载的数据卷，命令后面千万不要手抖加-v参数，保持默认的清理范围就足够腾出好几个G的清爽空间。

第四个顺手做的小优化是在华为云控制台把告警阈值往前挪一挪。
这次之所以能及时处理，多亏了华为云CES（云监控服务）默认配的系统盘使用率规则。但默认的90%阈值对于40G的小盘来说其实已经非常危险了，只留不到4G的余量，一旦遇上某个服务突发写Core dump或者解压大文件，很容易在几分钟内把系统盘彻底打死，导致SSH都连不上去。
清理完之后，我顺手在监控控制台里把规则调整了一下：设置成使用率达到80%时就发一条邮件和短信提醒。多留出这几G的缓冲空间，能给自己留出足够充裕的白天排查时间，不至于半夜被紧急告警闹钟叫醒。

折腾完这几步，服务器的系统盘占用直接从39G压缩回到了不到12G，跑了快两周，磁盘曲线一直平稳在安全水位。

买低配云服务器做个人项目，40G的系统盘属于精打细算的资源。应用跑起来之后，一定要早点给Docker套上日志轮转的紧箍咒，别等到磁盘被不声不响塞满、数据库因为写不进数据突然宕机的时候才到处找原因。花十分钟把daemon.json改好，能省去以后很多莫名其妙的系统排错麻烦。