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 定时任务。按下面步骤进行：

1. 首先判断 crontab 运行状态 service crond status ，确保 crontab 是“ is running" 状态。

2. 而后编辑 crontab 文件 vi /etc/crontab，在文件末尾增长下面指令：

   0 5 * * * root sh /home/hsip-monitor/deletelogs.sh >> /home/hsip-monitor/deletelogs.log

其配置说明以下：

- crontab定时配置说明： *（分）  *（时）   *（天）  *（月）  *（星期）
- root 指定用户，后面则是须要执行的 .sh 文件。此处咱们还将执行日志输出到 log 文件中，以便备查。

好了，设置完毕，观察几天看看运行状况吧。

问题与优化

crontab 任务没执行

1. 在设置清除日志的 crontab 定时任务以后，次日观察日志和文件，发现定时任务并无被执行。网上查找了不少资料不得其要旨。如下几点能够明确：

   • 使用 crontab -l 命令发现系统没有显示任何定时任务列表；
   • 使用 crontab -e 建立任务文件后，在文件中写入第2条中所示定时任务后，再次查看定时任务列表，有上述增长的任务；
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 思否 ）。好吧，将正式机器先这么设置吧，再保险下吧。

【完】