记一次线上系统故障排查

情况

前因：客户反应在线文档无法打开。

在线文档使用了 OnlyOffice 组件。

初步推断是网络连接不通或者硬盘空间不足（有过先例）。

通过堡垒机 SSH 到 onlyoffice server 上开始调查。

首先使用df -h查看硬盘占用，发现是根目录满了。

服务器是 Ubantu Server 系统，根目录只挂载了45G，/data目录挂载了100G。~~不知道运维怎么装的系统~~

然后使用下面的命令查看根目录每个文件夹大小，并排序：

sudo du -h --max-depth=1 / | sort -hr

发现是/var目录非常大，使用类似命令依次查下去之后

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

最后发现是/var/lib/docker/overlay2这个目录占用非常大。
但是这个目录中都是 docker 引擎及容器运行必须得文件。

首先想到清楚悬空镜像、删除无用的容器、删除未使用的卷。

然后使用这个命令查看每个容器的日志大小（可能需要 root 运行）：

docker ps -a --format "{{.ID}}" | xargs -I {} sh -c 'echo "{}: $(du -sh /var/lib/docker/containers/{}*/{}*-json.log 2>/dev/null)"'

发现每个日志文件也都才几十M，都不算很大。

接着使用docker ps -as可以查看所有容器占用的空间（-s参数），发现应用镜像容器占用非常大，一个容器就占用了二十多G，肯定有问题。

接着排查是不是应用中创建了一些临时文件没有删除，检查发现临时文件目录已经映射出去，体积也不大。

一顿排查发现日志文件增长迅速，查看项目的配置发现写入文件的 log4j 的 appender 没有配置级别，变成了默认的 DEBUG，就导致日志文件增长迅速。

项目是老项目，日志配置在了 tomcat 根目录下的一个文件夹内，没有映射出去。

修改日志级别到 Error

锅基本在运维。