☰

日志文件轮换和压缩间隔

tag-icon • tag-icon rhel logrotate
日志文件轮换和压缩间隔

我们的服务的 logrotate 配置如下：

{
    rotate 30
    create 644 root syslog
    missingok
    notifempty
    daily
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript }

即使compress配置中没有提及，日志文件也会在每次轮换后进行 gzip 压缩。我相信这是因为该compress行在 /etc/logrotate.conf 文件中未注释，通过全局启用它。问题是：

  1. 日志文件轮换之间是否存在时间延迟或间隔，（从 debug.log 到 debug.log-20190315）并且当它被压缩时（从 debug.log-20190315 到 debug.log-20190315.gz）？

  2. 如果存在延迟，compress在服务的特定日志旋转配置文件中提及是否会在将日志文件从 debug.log 旋转到 debug.log-20190315 后立即压缩该日志文件？

我没有delaycompress在任何 logrotate 配置文件中看到提及。

（背景：我们的 Splunk 索引器似乎正在从此服务中索引 debug.log-2019xxxx 文件。我们已将*.gz$和列入黑名单debug.log$，禁止转到 Splunk，但文件 debug.log-2019xxxx 似乎存在几秒钟或几分钟，因此它被转发到 Splunk，因为在此期间它与列入黑名单的正则表达式 -*.gz$和不匹配debug.log$。我知道我可以通过添加debug.log-[0-9]*到黑名单来解决此问题，但想知道是什么原因导致 xxxxxx.debug.log-20190315 的存在）

答案1

压缩步骤gzip将花费有限的时间，因此您有可能在压缩过程正在进行时看到原始文件。如果原始文件的大小足够大，则在压缩完成之前它可以存在相当长的时间。压缩所需的时间将根据传递给 gzip 的设置（压缩速度和级别）以及文件的可压缩性而有所不同。gzip仅在压缩过程完成后才会删除原始文件。

作为验证的小测试，我创建了一个大小为 1 GiB 的文件/dev/urandom和另一个大小为 1 GiB 的文件/dev/zero，并测试了压缩它们所需的时间。

包含随机数据的文件大约需要 2 分 23 秒：

[root@testvm1 ~]# time gzip testfile-random.txt

real    2m27.417s
user    2m22.172s
sys     0m2.839s

而零文件大约花费了29秒：

[root@testvm1 ~]# time gzip testfile-zero.txt

real    0m28.930s
user    0m27.453s
sys     0m0.989s

进行压缩时，原始文件在两种情况下都是可见的：

[root@testvm1 ~]# ls -lh testfile-random.txt*
-rw-r--r--. 1 root root 1.0G Mar 15 17:49 testfile-random.txt
-rw-------. 1 root root  75M Mar 15 17:59 testfile-random.txt.gz

[root@testvm1 ~]# ls -lh testfile-zero.txt*
-rw-r--r--. 1 root root 1.0G Mar 15 18:04 testfile-zero.txt
-rw-------. 1 root root 992K Mar 15 18:05 testfile-zero.txt.gz

相关内容