一、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造成什么影响。故，不清楚作用的，也不要乱改参数，特别是工作中的生产环境。
