高效的log工具：Logrotate

Logrotate的介绍

显而易见，Logrotate是基于CRON来运行的，其脚本是「/etc/cron.daily/logrotate」：

实际运行时，Logrotate会调用配置文件「/etc/logrotate.conf」：

这里的设置可以理解为Logrotate的缺省值，当然了，可以我们在「/etc/logrotate.d」目录里放置自己的配置文件，用来覆盖Logrotate的缺省值。

Logrotate的演示

按天保存一周的Nginx日志压缩文件，配置文件为「/etc/logrotate.d/nginx」：

如果你等不及CRON，可以通过如下命令来手动执行：

当然，正式执行前最好通过Debug选项来验证一下，这对调试也很重要：

BTW：类似的还有Verbose选项，这里就不多说了。

Logrotate的疑问

大家可能注意到了，我在前面Nginx的例子里声明日志文件的时候用了星号通配符，也就是说这里可能涉及多个日志文件，比如：access.log和error.log。说到这里大家或许就明白了，sharedscripts的作用是在所有的日志文件都轮转完毕后统一执行一次脚本。如果没有配置这条指令，那么每个日志文件轮转完毕后都会执行一次脚本。

它们都是用来控制保存多少日志文件的，区别在于rotate是以个数为单位的，而maxage是以天数为单位的。如果我们是以按天来轮转日志，那么二者的差别就不大了。

前面我们说过，Logrotate是基于CRON运行的，所以这个时间是由CRON控斗枝制的，具体可以查询CRON的配置文件「/etc/crontab」，可以手动改成如23:59等时间执行：

如果使用的是新版CentOS，那么配置文件为：/etc/anacrontab。

以Nginx为例，是通过postrotate指令发送USR1信号来通知Nginx重新打开日志文件的。但是其他的应用程序不一定遵循这样的约定，比如说MySQL是通过flush-logs来重新打开日志文件的。更有甚者，有些应用程序就压根没有提供类似的方法，此时如果想重新打开日志文件，就必须重启服务，但为了高可用性，这往往不能接受。还好Logrotate提供了一个名为copytruncate的指令，此方法采用的是先拷贝再清空的方式，整个过程中日志文件的 *** 作句柄没有发生改变，所以不需要通知应用程序重新打开日志文件，但是需蚂销亏要注意的是，在拷贝和清空之间有一个时间差，所以可能会丢失部分日志数据。

BTW：MySQL本身在support-files目录已经包含了一个名为mysql-log-rotate的脚本，不过它比较简单，更详细的日志轮转详见「 Rotating MySQL Slow Logs Safely 」。

…

熟悉Apache的朋友闷神可能会记得 cronolog ，不过Nginx并不支持它，有人通过mkfifo命令曲线救国，先给日志文件创建管道，再搭配cronolog轮转，虽然理论上没有问题，但效率上有折扣。另外，Debian/Ubuntu下有一个简化版工具savelog，有兴趣可以看看。

这个问题用crond做不了，因为他的检测间隔就是一分钟，你如散配果想在两次cron执行的间隔中，log文件的大小达到或超过指定大小就自动转的姿芹话，就需要自己写一个脚本，使用sleep这个程序，让她在指定的时间内执行，你可以指定为1秒执行一次logrotate或迹掘毕者其他时间间隔

        在golang的gin项目中使用supervisor守护进程，用子进程配置将标准输出日志转移到指定目录下，然后使用阿里云的日志服务将标准输出日志转移到线上做一些分析和预警。

      项目上线之后一切正常，可是周日夜里三点左右阿里云的日志服务采集不到日志，一顿pv为0的告警过来，赶紧打开电脑，线上服务正常，松一口气，supervisor状态也正常，观察了一会业务数据正常就安然入睡了，心想可能是因为配置项有缺陷吧，回头好好整整supervisor的配置再观察一波。

       早上起来打开服务器，cd /var/log/supervisor/，发现存在两个日志文件，分别是xxxx.log-20201223和xxxx.log，xxxx.log的大小为0，xxxx.log-20201223还在继续写入请求日志，权限问题？chmod 777之后发现新的文件还是不写入日志，重启 supervisor之后发现日志能正常写入了。。。一开始怀疑是supervisor日志切割备份有问题，将配置stdout日志文件大小的stdout_logfile_maxbytes配置项，默认 50MB改成0，代表无限大，stdout日志文件备份数的stdout_logfile_backups配置项，默认10改为0，代表不备份，重启supervisor，心想不切割总不会再出现切割之后不往新文件写内容的问题了，真乃明智之选。：）

        一周过去，0pv的告警如期而至，虽然不影响线上业务，如鲠在喉让我久久不能释怀。全网翻，百度谷歌，中文英文，去github上翻issue等等，看到一个历史issue1090，Better support for logrotate，感觉和日志转储相关，于是查了下logrotate相关资料，logrotate程厅皮序是一个日志文件管理工具。用于分割日志文件，删除旧的日志文件，并创棚蠢建新的日志文件，起到“转储”作用。centos系统默认安装，于是找到对应的配置文件，果不其然里面就有supervisor，默认配置如下：

/var/log/supervisor/*.log {

      missingok

      weekly

      notifempty

      nocompress

}，看到weekly感觉离这个问题的答案不远了，于是去查找linux的logrotate往旧文件写入的问题，在一篇logrotate writing to old app.log.1 instead of app.log的文章中找到需要配置参数copytruncate，是用于还在打开中的日志文件，把当前日志备份并截断；是先拷贝再清空的方式，拷贝和清空之间有一个时间差，可能会丢失部分日志数据。增加完配置之扮和差后，为了快速验证结果，修改weekly为daily，第二天日志正常切割了，新的文件也正常写入了标准日志。至此问题解决。

        linux的logrotate对于运维来说可能是常识，作为开发刚接触运维，只能慢慢积累了，工作之余看看相关的运维知识，尽量少采坑。

---