Linux定时清除日志与Catalina日志分割

2024年2月12日 144次阅读 来源: xuweijian

踩到的坑

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

【完】

    原文作者：xuweijian
    原文地址: https://segmentfault.com/a/1190000014217668
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞