logrotate日志转储
1. 运行环境
CentOS7.6 x86_64
2. linux日志转储功能
举例：对/var/log/testlog.log文件配置logrotate规则，可以使该文件在指定周期（比如一天或一周）内当文件达到指定大小（比如100MB）后进行转储，并可以指定转储文件的数量。系统常见的日志文件如/var/log/message、/var/log/boot.log、/var/log/syslog均已配置了日志转储。在/var/log目录经常可以看到类似syslog.3.gz这样的日志转储文件。
3. 如何转储自己的日志
假设我们要转储的日志文件为/var/log/testlog.log。
将下述内容保存成shell脚本文件并执行
#!/bin/bash
#logrotate rule file
LOG_PATH=/var/log/testlog.log
LOG_ROTATE_NUM=4 # how many log files to keep
LOG_ROTATE_SIZE=1M # rotate when log file reached to 1MB
RULE_FILE=/etc/logrotate.d/testlog
RULE_CONTENT="${LOG_PATH} {\n daily\n missingok\n compress\n notifempty\n create 0644 root root\n rotate ${LOG_ROTATE_NUM}\n size ${LOG_ROTATE_SIZE}\n}"
echo -e "$RULE_CONTENT" > ${RULE_FILE}
chmod 0644 ${RULE_FILE}
执行完上述脚本，/etc/logrotate.d/testlog文件内容如下：
/var/log/testlog.log {
daily
missingok
compress
notifempty
create 0644 root root
rotate 4
size 1M
}
上述脚本文件作用：
a) 在/etc/logrotate.d/目录下创建testlog.log日志转储规则文件
b) 将/var/log/testlog.log调试日志配置成每隔1天检查一次，当文件大于1MB时进行转储并压缩，转储文件最多保留4个（自身文件不算转储文件）
4. 效果
每天（具体时间，见下面分析），如果/var/log/testlog.log大于1MB，则该文件会被压缩转储到当前目录，压缩包名为testlog.log-YYYYMMDD.gz
# ll |grep test
-rw-r--r-- 1 root root 0 9月 17 05:45 testlog.log
-rw-r--r-- 1 root root 297K 9月 17 05:45 testlog.log-20220917.gz
-rw-r--r-- 1 root root 509K 9月 16 04:27 testlog.log-20220916.gz
5. 相关文件及目录
/etc/cron.daily/logrotate
/etc/logrotate.conf
/etc/logrotate.d/
/var/lib/logrotate/status
/var/log/cron
/var/log/messages
/var/log/syslog
6. 原理
logrotate依赖crond服务，通过/etc/cron.daily/logrotate文件可以得知，logrotate每天进行一次检查。logrotate会根据/etc/logrotate.conf配置文件指定的转储规则对相应日志执行转储操作。/etc/logrotate.conf内有一行include /etc/logrotate.d，加载该目录下的所有规则文件。/etc/logrotate.conf对转储规则进行了统一配置，不同系统上不尽相同，一般都会有weekly、rotate、create、dateext等参数，如果不想使用该默认参数，则可以在
/etc/logrotate.d下自己的转储配置文件内重写该参数。以testlog为例：
/var/log/testlog.log {
daily
missingok
compress
notifempty
create 0644 root root
rotate 4
size 1M
}
第一个参数daily表示转储日期为天，这与/etc/logrotate.conf的weekly不同，logrotate执行时以我们的配置文件参数daily为准。
参数及含义见下：
compress 通过gzip压缩转储以后的日志
nocompress 不做gzip压缩处理
copytruncate 用于还在打开中的日志文件，把当前日志备份并截断；是先拷贝再清空的方式，拷贝和清空之间有一个时间差，可能会丢失部分日志数据。
nocopytruncate 备份日志文件不过不截断
create mode owner group 轮转时指定创建新文件的属性，如create 0777 nobody nobody
nocreate 不建立新的日志文件
delaycompress 和compress 一起使用时，转储的日志文件到下一次转储时才压缩
nodelaycompress 覆盖 delaycompress 选项，转储同时压缩。
missingok 如果日志丢失，不报错继续滚动下一个日志
errors address 专储时的错误信息发送到指定的Email 地址
ifempty 即使日志文件为空文件也做轮转，这个是logrotate的缺省选项。
notifempty 当日志文件为空时，不进行轮转
mail address 把转储的日志文件发送到指定的E-mail 地址
nomail 转储时不发送日志文件
olddir directory 转储后的日志文件放入指定的目录，必须和当前日志文件在同一个文件系统
noolddir 转储后的日志文件和当前日志文件放在同一个目录下
sharedscripts 运行postrotate脚本，作用是在所有日志都轮转后统一执行一次脚本。如果没有配置这个，那么每个日志轮转后都会执行一次脚本
prerotate 在logrotate转储之前需要执行的指令，例如修改文件的属性等动作；必须独立成行
postrotate 在logrotate转储之后需要执行的指令，例如重新启动 (kill -HUP) 某个服务！必须独立成行
daily 指定转储周期为每天
weekly 指定转储周期为每周
monthly 指定转储周期为每月
rotate count 指定日志文件删除之前转储的次数，0 指没有备份，5 指保留5 个备份
dateext 使用当期日期作为命名格式
dateformat .%s 配合dateext使用，紧跟在下一行出现，定义文件切割后的文件名，必须配合dateext使用，只支持 %Y %m %d %s 这四个参数
size(或minsize) log-size 当日志文件到达指定的大小时才转储，log-size能指定bytes(缺省)及KB (sizek)或MB(sizem).当日志文件 >= log-size 的时候就转储。
7. 调试和错误排查
由于logrotate的计划任务是每天执行检查（当然将/etc/cron.daily/logrotate文件移动到/etc/cron.hourly/目录可以减小等待时间，但等待1小时仍被认为是无法接受的），我们需要采取辅助方法对该功能进行调试。手动执行logrotate命令或修改系统时间都可以快速验证自己写的转储配置规则是否符合需求。
在真正执行前，最好先检查一下自己写的配置规则是否有效。logrotate的-d参数可以检查规则有效性。
#logrotate -d /etc/logrotate.d/testlog
下述命令将会按照testlog配置的转储规则立即对日志文件执行转储操作。
#logrotate -f /etc/logrotate.d/testlog
但这里有个问题，/etc/logrotate.d/testlog是被/etc/logrotate.conf包含进去的，logrotate.conf的参数配置和testlog的参数配置有可能不同，这将会影响结果。
我们最好直接执行下面的命令：
#logrotate -f /etc/logrotate.conf
这时得到的结果和系统自动转储得到的结果是相同的。
执行完上述命令，查看/var/log/目录，发现testlog.log并未被转储，这是因为该文件没有任何内容导致的。
我们向该文件写入一些内容，直到该文件大于1M
#cat /var/log/messages >> /var/log/testlog.log
# ls -lh /var/log/testlog.log
-rw-r--r-- 1 root root 3.2M 9月 17 00:57 /var/log/testlog.log
再次执行下述命令：
#logrotate -f /etc/logrotate.conf
# ls -lh /var/log/testlog*
-rw-r--r-- 1 root root 0 9月 16 20:01 /var/log/testlog.log
-rw-r--r-- 1 root root 509K 9月 16 20:01 /var/log/testlog.log-20220916.gz
再向/var/log/testlog.log写入大于1M的内容，然后修改系统时间：
#date -s "23:59:59"
一分钟后，查看/var/log目录，发现并没有转储成功！
难道/etc/cron.daily和/etc/cron.hourly不应该是相同的效果吗，都是延迟1分钟执行？
这就引申出来另一个问题，每日计划任务到底是何时执行的？
通过查看/etc/cron.d/0hourly，可以发现，原来hourly延迟1分钟执行是在这里设置的。
# cat /etc/cron.d/0hourly
# Run the hourly jobs
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
01 * * * * root run-parts /etc/cron.hourly
但当前目录并没有一个叫01daily的配置文件，我们当然可以手动添加一个，但最好不要随便修改系统的配置文件。在/etc目录搜索0hourly里出现的run-parts字段，发现一个叫做/etc/anacrontab的文件对daily计划任务执行时间进行了描述，通过查找资料得知，
daily计划任务会在每天的3-22点之间执行，执行工作时强制延迟时间为5分钟，再随机延迟0-45分钟。
以上结论是在CentOS7.6上得到的。对于debian系的操作系统，直接通过查看/etc/crontab即可知道daily计划任务的执行时间。
# cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DISPLAY=:0.0
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
5 9 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
- hourly计划任务执行时间是每小时的第17分钟
- daily计划任务执行时间是每天的09:05
/var/lib/logrotate/status文件记录了logrotate执行文件转储的时间。
如果转储配置文件经检查没有错误，但无法生成正确的转储文件，我们可以通过查看系统日志对问题进行分析。
对于centos系统，可以查看下面两个文件：
#cat /var/log/cron | grep cron
#cat /var/log/messages | grep cron
对于debian系统，可以查看下面文件：
#cat /var/log/syslog | grep cron