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

作者：田逸（formyz）

出事了，十万火急

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

 

故障排查及临时措施

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

 

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

终极办法

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

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

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

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

#!/bin/bash

source /etc/profile

cd /logs

list_src_logs=`ls -f  | grep log$`

for i in  $list_src_logs

  do

  #echo $i

  cp  $i arch_logs/$i.`date +%Y-%m-%d`

  echo ""> $i

  sleep 1

  done

if [[ $(ls -A arch_logs) ]]

  then

  find arch_logs/*  -mtime 15 -delete

  else

  echo "dir is empty"

fi

exit 0

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

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