作者：田逸（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计划任务中。
第二天，查验计划任务完成情况，经多次验证，最终达到系统盘及归档盘不被塞满的目标。