linux 每天清空日志内容,Linux定时清除日志与Catalina日志分割

踩到的坑

除了开发工作之外,本人还有一项琐碎的工作,就是每天定时查看网站相关的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 思否 )。好吧,将正式机器先这么设置吧,再保险下吧。

【完】

你可能感兴趣的:(linux,每天清空日志内容)