当我正沉浸在国庆黄金周的悠闲时光里面的某一个下午突然收到报告称：xxx服务器CPU连续几天占用超过99%疑似遭到攻击。 PS：我只是公司打杂的，偶尔写写脚本处理一些业务顺便帮忙买下云服务器什么的。不知道从什么时候开始服务器出了比较大的问题都优先找到我 (^=^)姨母微笑。 我登到控制台一看果然那台Linux服务器宕机了，top命令看到是业务上的关键服务和守护进程占满了CPU。作为外行的我又在休假期间，本着不行就重启试试的基本原则reboot了一下服务器。ssh重新登陆进去查了一圈histroy命令行操作日志、ssh登陆日志和可疑进程，然后是crontab计划任务和rc.local开机启动，都没有找到异常。 看了下CPU占用下来了但是业务服务却没有自动重启，问了下业务都是docker跑的于是手动运行了docker发现也无法正常启动直接报docker.service找不到，socket文件无法创建。然后df -h 查看硬盘占用100%，果然是硬盘满了导致服务无法正常运行CPU100%。 100多G的服务器硬盘，docker占了90%以上，先删了他们业务10多G的日志（你问我什么业务有10多G的日志我也表示疑惑，^_^）先保证服务能正常启动。接着用du -sh 挨个目录检查占用情况，最后查到了/var/lib/docker/containers目录占了70-80个G。我水平比较一般，平常部署项目没有直接在服务器上搞过docker所以不太明白容器目录为啥会占这么多，懂的大神可以跟我科普下，哈哈。然后发现有一个巨大无比的.log文件占了70G。终于找到罪魁祸首，上网查了下这个日志文件可以清理就直接 echo ''> xxx.log了。顺带又查了下docker的幽灵镜像，也用docker rmi 删了。 <img src="https://pic2.zhimg.com/80/v2-074ab3bc4707d0898c46a71dacb7366d_720w.webp" /> <img src="https://pic1.zhimg.com/80/v2-a08e0c01642fec68f2e206ac0d0683a0_720w.webp" /> 然后服务器回归平静。 为了防止下次又产生这么大的日志文件，我在/etc/docker/daemon.json加了个docker配置 <img src="https://pic3.zhimg.com/80/v2-bbcd8ab6f0426d0e176430c5a53589a6_720w.webp" /> 愿下次出问题的时候我正在无聊摸鱼而不是度假中，Amen～