☰

logrotate 如何处理 copytruncate？

tag-icon • tag-icon logrotate
logrotate 如何处理 copytruncate？

我知道 copytruncate 不是一个理想的设置，但这就是我所处理的卡片......

我有一项服务，它从 journalctl 中提取数据并将其流式传输到文件中。

旋转文件的设置是......

/var/log/xxxxxx/xxxxxx.log {
    size 100M
    copytruncate
    rotate 5
    compress
    compresscmd /bin/xz
}

当我查看位置 /var/log/xxxxxx/ 时，我看到 xxxxxx.log 是 8GB，但我还看到 xxxxxx.log-20181125.gz 等等......这意味着正在发生轮换。

我的问题是主 xxxxxx.log 不应该是 100MB 吗，为什么是 8GB？而且如果是 8GB 导致触发 logrotate 规则，这是否意味着它也在不断尝试处理该 8GB 文件，因此实际上是在无谓地消耗资源？

更新 有一项运行的服务：/bin/sh -c '/bin/journalctl --since="5 minutes ago" --no-tail --follow --unit="xxxxxx*.service" >> /var/log/xxxxxx/xxxxxx.log 2>&1'

运行logrotate时logrotate -v /etc/logrotate.d/xxxxxx提示截断了文件，其实并没有截断，我停掉服务后手动再运行就好了。

运行：CentOS Linux 版本 7.5.1804（核心）

答案1

尝试运行类似工具来查看文件中有多少数据。您可能会得到一个稀疏文件，其中下一条记录位于文件截断时所在位置之后的文件位置，而在此之前则没有任何内容。某些服务会保留其文件位置并在该位置写入。这在用于旋转日志文件wc时效果不佳。copytruncate

某些应用程序在收到信号后会重新打开文件，因此通常允许 logrotate 移动并重新创建文件，因为日志数据将继续写入日志文件，直到重新打开为止。delaycompress使用此方法时使用。syslog 守护程序的 logrotation 规范就是一个很好的例子。

有关轮换日志的讨论，请参阅 logrotate 的手册页。

答案2

发现问题...所以我根据此链接设置了我的系统：https://github.com/dcos/dcos-docs/blob/master/1.9/monitoring/logging/aggregating/elk.md

请注意这里...

...
-u dcos-logrotate-master.service \
> /var/log/dcos/dcos.log 2>&1'
ExecStartPre=/usr/bin/journalctl

缺少一个 >。他们的文档后来被更正了。但由于我在第一次安装时执行过一次此步骤，因此问题一直被隐藏，直到我们注意到日志在增长而不是截断……

相关内容