踩到的坑
除了开发工作之外,本人还有一项琐碎的工作,就是每天定时查看网站相关的Linux机器运行情况。
刚开始时,Linux机器都运行正常,本人就松散了很多,从每天的检查,到后来的一周检查一两次。
后来,网站受到不明来源频繁攻击,导致某些后台组件崩溃(这个问题有时间再另写博文述之),但是网站服务器仍然运行良好。
但是糟糕的事还是来了,然后就在一个月之前,老大突然收到有关Linux服务器磁盘使用率达到90%以上!这下有些慌了,赶紧巡检机器的运行情况。发现正式环境机器的磁盘tomcat安装目录就占了30多个G(总共44G)。
du -sh /home/tomcat # -s 表示统计总和,单位为G;-h 表示统计各文件大小
du -bs /home/tomcat # -b 表示统计单位为bite
df -h # 统计查看系统磁盘利用情况,分为物理利用率和逻辑利用率
老大提醒我跟日志文件有关,进去一看logs文件夹,果然是,估计有几百个日志文件吧,其大小不一。好吧,就是你啦!
填坑
措施一:rm -rf filepath
刚开始,为了赶紧解决这个问题,就直接简单粗暴的使用 rm 命令将其删除,只保留一个月之内的日志。
rm -rf logs/*2017*.log && rm -rf logs/*201801*.log && rm -rf logs/*201802*.log
重新使用 df -h
查下磁盘,降到了70%左右,嗯嗯,还可以,然后就如法炮制将其他几台机器也删除旧日志。
呵呵,就这几下子,也太小瞧坑我的威名
进行上述操作之后,以为可以安静的休息一个礼拜吧。
但是没想到第二天又收到告警信息,我了去,要了老命啊,前段时间攻击已经够折腾了,我这里不能出事啊!
仔细查看所剩不多日志文件,其大小都还可以接收。对比来对比去,发现原来是 catalina.out 文件惹得祸,查下大小,尼玛20多个G。好吧,算你狠!
措施二:分割 catalina 日志
网上查找资料后,有网友推荐使用 logrotate 日志轮询进行日志分割。好的说干就干。
现在 /etc/logrotate.d/
下面创建自己的轮询任务文件 tomcat 吧:
cat >/etc/logrotate.d/tomcat << EOF
/home/tomcat-hsip/logs/catalina.out{
copytruncate
daily
rotate 7
missingok
compress
size 16M
}
EOF
这里我们设置每天进行 Catalina.out 文件轮转(daily),至多保存7个副本(rotate 7),同时压缩分割后的日志文件(compress),当日志文件大于16MB时,就轮转(size 16M)。
这里需要明白一下几点:
- 每天晚上 crond 守护进程会运行在 /etc/cron.daily 目录中的任务列表;
- 与 logrotate 相关的脚本也在 /etc/cron.daily 目录中。运行的方式为 /usr/bin/logrotate /etc/logrotate.conf;
- /etc/logrotate.conf 文件 include 了 /etc/logrotate.d/ 目录下的所有文件。还包括我们上面刚创建的 tomcat 文件;
- /etc/logrotate.d/tomcat 文件会触发 /home/tomcat-hsip/logs/catalina.out 文件的轮转。
为了尽快解决问题,设置好了轮询配置之后,我们马上运行上述配置文件:
logrotate --force /etc/logrotate.d/tomcat # --force 或 -f 表示强制执行轮询操作
手动执行之后,过了一会儿,Catalina被分割掉了一大半,其文件格式为 catalina.out.1.gz ,其中1是执行次序。若我们再次执行上述命令,catalina.out.1.gz 将会更名为 catalina.out.2.gz ,最新执行生成的分割文件将会成为 catalina.out.1.gz。
接着执行措施一中的命令,将分割出来的日志删掉,磁盘顿时安静啦。^v^
措施三:定时清除日志
想着也不能我每次都手动来清除这个日志和分割出来的 Catalina 日志文件吧。弄个定时任务自己跑呗!
既然 logrotate 需要用到 crond ,那本人将上述命令写入脚本 deletelogs.sh,让 crond 自动执行不就OK吗!
#!/bin/bash
#可填写多个路径
workdir=("/home/tomcat-hsip/logs")
for wdir in ${workdir[@]}; do
echo -e "filepath is ${wdir} .\n"
# .log 文件和包含 log 标记的 .txt文件,以及分割的 catalina.out.1.gz 等压缩文件
find $wdir -regex "^.*\(log.*\.txt\|\.log\|catalina.*\.gz\)$" -and -mtime +5 -type f -exec rm -rf {} \;
if [ $? -eq 0 ]; then
echo -e `date`" delete logs successfully! \n"
else
echo -e `date`" delete logs failed! \n"
fi
done
这里我们用到了 find 命令找到对应的文件,简要说明下:
-
-regex
此参数表示后面的输入使用正则表达式进行书写。若为 -name 则后面使用一般字符串书写,此时可以使用通配符,但正则相关的符号将会被保留。 - shell正则:^ 表示正则匹配字符串开头,$ 表示正则匹配字符串的结尾,其他一些和正则使用的非字母的符号需要进行转义;. 表示匹配任意字符;所以文件路径中出现的 . 需要进行转义。
-
-and
表示再次同等使用命令的相关参数,如此处的 -mtime ; -
-mtime
表示使用修改时间属性,后面的 +7 表示满足超过7天,即修改时间在7天以上的文件或文件夹;而 -7 表示满足不足7天, 7 表示刚好7天; -
-type
表示查找的文件属性,后面 f 表示查找文件,而 d 表示查找文件夹; -
-exec
表示后面要对前面匹配的文件或文件夹执行后面的命令。注意后面的命令需要一对儿{},一个空格和一个,最后是一个分号来结束;
接着,我们配置 crontab 定时任务。按下面步骤进行:
- 首先判断 crontab 运行状态
service crond status
,确保 crontab 是“ is running" 状态。 -
然后编辑 crontab 文件
vi /etc/crontab
,在文件末尾增加下面指令:0 5 * * * root sh /home/hsip-monitor/deletelogs.sh >> /home/hsip-monitor/deletelogs.log
其配置说明如下:
- crontab定时配置说明: *(分) *(时) *(天) *(月) *(星期)
- root 指定用户,后面则是需要执行的 .sh 文件。此处我们还将执行日志输出到 log 文件中,以便备查。
好了,设置完毕,观察几天看看运行情况吧。
问题与优化
crontab 任务没执行
-
在设置清除日志的 crontab 定时任务之后,第二天观察日志和文件,发现定时任务并没有被执行。网上查找了很多资料不得其要旨。以下几点可以明确:
- 使用
crontab -l
命令发现系统没有显示任何定时任务列表; - 使用
crontab -e
创建任务文件后,在文件中写入第2条中所示定时任务后,再次查看定时任务列表,有上述增加的任务;
- 使用
- 在上面所述解决方案并没有将问题解决之后,仔细查看 crontab 定时任务发现,原来是参看的博文定时任务命令中缺少
sh
这个执行命令,虽然看了很多博文,执行sh脚本前面没有加命令sh
。不清楚为什么别人可以执行,但是我这里不加不行,加了sh
之后,定时任务就好使了;
Catalina 自动轮转没有执行
分割日志配置在正式环境的机器上没有被执行,而一台不经常用的测试机器能却很好地分割 catalina 日志,找了很多解决方案都没有解决。
在解决了 crontab 定时任务不能解决之后的问题后,突然灵机一动,为什么不能将 logrotate --force /etc/logrotate.d/tomcat
写到 crontab 的定时任务中呢?
说干就干,创建文件 cutoffCatalina.sh 只等明天的执行结果。
#!/bin/bash
/usr/sbin/logrotate --force /etc/logrotate.d/tomcat
if [ $? -eq 0 ]; then
echo -e `date`" cut catalina.out successfully! \\n"
else
echo -e `date`" cut catalina.out failed! \\n"
fi
同时在 /etc/crontab 文件中加入下面配置
50 23 * * * root sh /home/hsip-monitor/cutoffCatalina.sh >> /home/hsip-monitor/cutoffCatalina.log
然而,很遗憾的说,写入到脚本中执行,同样执行失败,怀疑是日志文件在被操作,从而无法完成分割。后来老大也提醒,是不是和 catalina 正在读写有关?
于是找了一个用户访问量少的时间(凌晨5点左右),重新配置:
30 4 * * * root sh /home/hsip-monitor/cutoffCatalina.sh >> /home/hsip-monitor/cutoffCatalina.log
然后出现一个有意思的情况:
-
正式环境上日志被分割成 catalina.out.1.gz ,而测试机器上则被分割成了 catalina.out-20180314.gz ,也就是说:
- Catalina 正在读写时,我们脚本执行成功,即 --force 参数有效。
- logrotate 轮询机制触发,Catalina在读写时,执行轮询失败,反之则能成功执行,成功后分割的文件以时间戳命令。
其他发现
在搜索解决问题过程中,有网友所述方法不知道行不行,网友没说为什么linux - logrotate管理分割nginx日志无效 - SegmentFault 思否 )。好吧,将正式机器先这么设置吧,再保险下吧。
【完】