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 命令将其删除，只保留一个月之内的日志。

rm -rf logs/*2017*.log && rm -rf logs/*201801*.log && rm -rf logs/*201802*.log 

重新使用 df -h 查下磁盘，降到了70%左右，嗯嗯，还可以，然后就如法炮制将其他几台机器也删除旧日志。

进行上述操作之后，以为可以安静的休息一个礼拜吧。
但是没想到第二天又收到告警信息，我了去，要了老命啊，前段时间攻击已经够折腾了，我这里不能出事啊！
仔细查看所剩不多日志文件，其大小都还可以接收。对比来对比去，发现原来是 catalina.out 文件惹得祸，查下大小，尼玛20多个G。好吧，算你狠！

网上查找资料后，有网友推荐使用 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} .
"
  # .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! 
"
  else
    echo -e `date`" delete logs failed! 
"
  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 -l 命令发现系统没有显示任何定时任务列表；

使用 crontab -e 创建任务文件后，在文件中写入第2条中所示定时任务后，再次查看定时任务列表，有上述增加的任务；

在上面所述解决方案并没有将问题解决之后，仔细查看 crontab 定时任务发现，原来是参看的博文定时任务命令中缺少 sh 这个执行命令，虽然看了很多博文，执行sh脚本前面没有加命令 sh 。不清楚为什么别人可以执行，但是我这里不加不行，加了 sh 之后，定时任务就好使了；

分割日志配置在正式环境的机器上没有被执行，而一台不经常用的测试机器能却很好地分割 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! 
"
else
echo -e `date`" cut catalina.out failed! 
"
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 思否 ）。好吧，将正式机器先这么设置吧，再保险下吧。

【完】