admin 管理员组

文章数量: 887007

用shell脚本巧解日志文件塞满磁盘导致系统挂起的困惑

作者:田逸(formyz)

出事了,十万火急

一帮可爱的程序员,写的程序没有规划,程序、代码与日志一锅粥,而且都在某云的系统盘,不光生成的文件多,而且不做处理。有一天,来了个十万火急的求救,告知弹性伸缩功能被触发,自动增加云主机到设定的最高值,但系统仍然不能访问,需要我马上解决。登上任意云主机系统,查进程、查负载、再查磁盘使用率,我的天,系统只有一个分区,大小为40G,使用率接近100%。没有空闲空间,系统往/var/log及/tmp里无法写入数据,导致服务不响应,负载均衡监控发现云主机整体异常,认为是容量不够,就自动扩容,但扩容出来的云主机,其磁盘空间也一样是塞满了的,所以….

 

故障排查及临时措施

因为磁盘塞满了,虽然登录进去了系统,但很多操作不能进行,最后在/tmp目录下删掉一些下文件,稍微给系统腾出了一些空间,才有幸把与业务相关的服务停止,用df配合du看看是什么文件占据了这么多的空间。

 

好家伙,居然有单个日志文件超过20G的,虽然日志文件多且大,据猜测,这些程序员可能压根都没有去看这些日志,也不知道产生日志有什么意义(不看不处理等于零)。不管三七二十一,先干掉几个大的文件,让服务恢复。

终极办法

给日志分配单独的磁盘空间,并按约定的统一格式命名日志,每天夜里,做一次日志切割。具体做法是复制前一天的日志到另外一个位置,接着清空原来的日志;在归档日志目录,保留最近15天来的所有日志。

有人问,直接清空服务,会丢失少部分日志记录,为啥不停服务,等日志归档完再重启?这个是因为需要重启的服务太多,数十个,可能存在自动启动不了的风险,并且丢失少许日志是他们可以接受的。

需求明确以后,撰写了一个Shell脚本,内容如下:

[root@s176 logs]# more /usr/bin/logs_arch.sh

#!/bin/bashsource /etc/profilecd /logslist_src_logs=`ls -f  | grep log$`for i in  $list_src_logsdo#echo $icp  $i arch_logs/$i.`date +%Y-%m-%d`echo ""> $isleep 1doneif [[ $(ls -A arch_logs) ]]thenfind arch_logs/*  -mtime 15 -deleteelseecho "dir is empty"fiexit 0

先手动执行此脚本,验证其正确性及有效性,确保可以到达目的以后,再将其加入到crontab计划任务中。

第二天,查验计划任务完成情况,经多次验证,最终达到系统盘及归档盘不被塞满的目标。

本文标签: 用shell脚本巧解日志文件塞满磁盘导致系统挂起的困惑