使用logrotate做nginx日志分割

发布时间 2023-04-02 17:07:51作者: gaowen_wenwen

一、logrotate介绍

logrotate是centos自带命令,其他linux操作系统可能需要自行安装,用来进行日志切割和定期删除,简单来说就是将某个日志文件按照时间或大小分割成多份,删除时间久远的日志。

日志用来帮助我们了解程序运行情况,定位程序bug,如果不对日志及时进行清理就会占据磁盘空间,尤其对于服务器类型的项目,需要长期运行,日志量更大,一年前的日志大部分情况下对我们是无用的也无需保留,并且如果我们的日志记录频率很高,全部存储在一个文件中,文件是很大的,当需要查看时,使用vim或者其他软件打开也会很卡。

 

二、配置讲解

logrotate是基于crond服务(定时任务)来运行的,

有几个重要的配置:

1、/etc/logrotate.conf(主配置)和/etc/logrotate.d/*(子配置)

/etc/logrotate.conf是全局配置,logrotate.conf里面包含include /etc/logrotate.d这句,加载子配置文件的意思,说明/etc/logrotate.d/目录下是具体的配置,一般是以服务名称命名,比如yum等配置。主配置和子配置有冲突时,以子配置的规则为准。

logrotate配置文件及常用参数解释如下:

常见配置参数:

daily :指定转储周期为天天
weekly :指定转储周期为每周
monthly :指定转储周期为每个月
rotate count :指定日志文件删除以前转储的次数,0指没有备份,5 指保留5 个备份
tabooext [+] list:让logrotate不转储指定扩展名的文件,缺省的扩展名是:.rpm-orig, .rpmsave,v, 和 ~
missingok:在日志轮循期间,任何错误将被忽略,例如“文件没法找到”之类的错误。
size size:当日志文件到达指定的大小时才转储,bytes(缺省)及KB(sizek)或MB(sizem)
compress: 经过gzip压缩转储之后的日志
nocompress: 不压缩
copytruncate:用于还在打开中的日志文件,把当前日志备份并截断
nocopytruncate: 备份日志文件可是不截断
create mode owner group : 转储文件,使用指定的文件模式建立新的日志文件
nocreate: 不创建新的日志文件
delaycompress: 和 compress 一块儿使用时,转储的日志文件到下一次转储时才压缩
nodelaycompress: 覆盖 delaycompress选项,转储同时压缩。
errors address : 专储时的错误信息发送到指定的Email 地址
ifempty :即便是空文件也转储,这个是logrotate 的缺省选项。
notifempty :若是是空文件的话,不转储
mail address : 把转储的日志文件发送到指定的E-mail地址
nomail : 转储时不发送日志文件
olddir directory:储后的日志文件放入指定的目录,必须和当前日志文件在同一个文件系统
noolddir: 转储后的日志文件和当前日志文件放在同一个目录下
prerotate/endscript: 在转储之前须要执行的命令能够放入这个对,这两个关键字必须单独成行
2、/var/lib/logrotate.status,是logrotate自己的日志文件
记录logrotate的运行情况,可以查看被logrotate管理的日志文件的最后备份时间
3、logrotete 命令参数
加-d运行该命令,只是测试此时是否满足日志分割的条件,实际上并没有进行分割备份文件
如logrotate -vfd /etc/logrotate.d/nginx
如果去掉 d 关键字,则进行实际运行,-f 参数,强制执行日志分割清理的功能,我觉得加上更好,因为执行logrotate命令要检查很多(比如系统时间等),导致执行失败,所以直接 -f 强制执行,简单粗暴
logrotate -vf /etc/logrotate.d/nginx
不是root用户执行的话,则选择有能获取root权限的用户,加sudo

 

三、实现

实现方式有两种
方案1:是在原有的配置下新增(在主配置或子配置新增),依旧被原来的cron管理,系统的cron管理一般是每天执行一次,基于计划任务/etc/cron.daily/logrotate
方案2:是在自己在任意位置新建配置文件,然后自己写定时任务来管理,自己写定时任务更灵活,可以每小时,每天23:59:00,每周等任何时刻执行logrotate命令,但两者原理是一样的,都是logrotate命令被执行时就按照logrotate配置文件来切割清理日志
案例:方案2,每天23:59:00执行logrotate命令,按天清理,保留5天
step1,任意位置写配置文件,权限改成644
step2,写定时任务,定时执行logrotate
crontab -e写入,内容为“ 59 23 * * * /usr/sbin/logrotate -f /home/zmq/daily_logrotate ”
step3,修改系统时间,测试效果
调整系统时间为23:58:30,等待30s
切割成功,logrotate本身的日志也记录在/var/lib/logrotate.status里了

 

四、注意事项

1、如果像我这样,自己新增一个配置文件,需要给配置文件的权限设置成644及以下,否则logrotate不生效
2、如果切割日志的文件所在目录权限大于755,则logrotate不生效,解决办法是修改父目录,如logs的目录权限小于等于755
error: skipping "/usr/local/nginx/logs/access.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.

 3,配置文件/etc/logrotate.d/nginx中,如执行通知nginx进行重新打开新日志文件的地方,nginx.pid的路径要写正确,不然就出现,正常的日志文件是空的,而新的日志数据写入到了旧的已经改名的文件中。如下,故意将进程号路径写错,查看access.log的inode,

 然后执行logrotate -vf /etc/logrotate.d/nginx

查看logs下的文件列表,已经切割了,但查看access.log-20230402文件的inode和之前access.log的inode一样。这是因为nginx进程号并未查到,未通知nginx重新打开日志文件,nginx还用以前access.log文件名的inode,就写入了access.log-20230402文件中,所以出现此意想不到的状况。当nginx重启,或者reload,再或者reopen,都会再次重新打开新的access.log文件,也即正常了。

 

 将进程号路径写对后,两个文件的inode就不一样了。

 注意: /bin/kill -USR1 `cat /usr/local/nginx/logs/nginx.pid` 由于加入了-USR1参数,所以并不是杀死nginx进程,而是通知nginx执行相应级别的操作,-USR1相当于nginx 的reopen, -USR2相当于reload,所以不用担心这个操作会对nginx造成什么影响。故,不清楚作用的,也不要乱改参数,特别是工作中的生产环境。