问题描述

  今天售后同事匆匆忙忙跑过来说:“客户那边的机器人挂掉了,app都运行不起来,可硬件都是正常的,我也不知道什么问题”,我心想:“我们机器人系统已经开发迭代好多年了,还会出现这种问题?”,没方法,还是借助我们开发好的远程工具排查吧,排查当然得从机器人服务器Ubuntu系统开始。

排查步骤

1.用docker ps 命令检查docker 正在执行的容器,竟然发现有容器服务不能正常运行。

docker的overlay2占用大 docker的overlay2满了_docker


2. 好好的容器为什么起不了呢?记得以前出现过硬盘爆满导致服务起不了的情况,用df -h 命令查询,果然是硬盘满了!!!

docker的overlay2占用大 docker的overlay2满了_ubuntu_02

3. 硬盘满后,查不了很具体的磁盘信息,先删除一些无关紧要的文件,再次进行查询,查到了又是/var/lib/docker/overlay2文件,以前出现这个问题情景历历在目。。。

docker的overlay2占用大 docker的overlay2满了_ubuntu_03

4. 用 du -h max-depth=1 命令一步一步找到到底是哪个文件把硬盘吃掉了?原来是某个容器的log文件。。。

docker的overlay2占用大 docker的overlay2满了_docker_04

5. 用docker ps | grep 命令找到对应的运行容器(这里容器的id是var/lib/docker/containers文件夹名字的前12位,用grep命令很容易找到)。

docker的overlay2占用大 docker的overlay2满了_docker_05


1. 用docker logs -f 命令打印对应容器的logs信息,原来这个容器服务是客户那边定制的测体温服务,刚开发好就出货了,log等级还是debug等级,输出了好多好多的log信息。

docker的overlay2占用大 docker的overlay2满了_docker的overlay2占用大_06

7. 找到问题就好办了,修改容器服务的log等级,不要输出那么多log,把第四点提到占了巨大存储的xxx-json.log文件删除,sudo reboot,解决。

docker的overlay2占用大 docker的overlay2满了_运维_07

8. 为了安全其实也可以限制每个容器的log文件大小,可我们机器人服务器存储还是有的,就没必要去做这个限制了。