日志轮转如何处理抄写？

Question

我知道抄袭不是一个理想的设置，但那是我要处理的牌.

我有一个服务，它跟踪日志中的数据并将其流到一个文件中。

旋转文件的设置是..。

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

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

我的问题是，主xxxxxx.log不应该是100 8GB吗?为什么它是8GB？另外，如果是8GB，这会导致日志旋转规则的触发，这是否意味着它也在不断地尝试处理该8GB文件，所以实际上是在白白消耗资源呢？

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

运行logrotate -v /etc/logrotate.d/xxxxxx日志时表示它截断了文件，但实际上没有。我停止了服务，并再次手动运行它，它成功了。

运行: CentOS Linux7.5.1804版(核心)

Answer 1

尝试运行像wc这样的工具来查看文件中有多少数据。您可能会得到一个稀疏的文件，在文件位置的下一个记录就在文件被截断时的位置之后，而在此之前没有任何记录。一些服务保留其文件位置并在该位置写入。当使用copytruncate旋转日志文件时，这种方法不能很好地工作。

一些应用程序在发送信号时会重新打开它们的文件，通常允许日志旋转移动和重新创建该文件，因为日志数据将继续写入日志文件，直到重新打开。使用此方法时使用delaycompress。syslog守护进程的日志旋转规范就是一个很好的例子。

有关旋转日志的讨论，请参见日志旋转手册页。

Answer 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

有一个>失踪的。从那以后，他们的医生就被更正了。但是自从我第一次安装时做了这个步骤，问题就被隐藏起来，直到我们注意到日志在增长而不是截断.