rsyslog与log转速:重新加载rsyslog与复制

Question

我正在使用默认的rsyslog和log转速实用程序开发Ubuntu 14。

在默认的rsyslog日志/etc/logrotate.d/rsyslog配置中，我看到以下内容：

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

据我所知，建议在所有日志旋转场景中使用copytruncate，因为它不移动当前日志，而是截断日志，以便任何具有打开文件处理程序的进程都能够继续写入日志。

那么，为什么使用rsyslog重新加载特性来代替默认配置呢？

Answer 1

要回答您的问题，您首先需要了解重新加载和复制截断的不同权衡：

• 重新加载:重新命名旧日志文件，并通知写入该日志的进程(通过Unix信号)重新创建其日志文件。这是最快/较低开销的方法:重命名/移动操作非常快，且执行时间恒定。此外，它几乎是一个原子操作:这意味着(几乎)在移动/重新加载过程中不会丢失日志条目。另一方面，您需要一个能够重新加载和重新打开其日志文件的进程。Rsyslog就是这样一个进程，因此默认的log旋转式配置使用重新加载方法。rsyslog上游强烈推荐使用此模式。
• 复制:将旧日志文件复制到存档文件中，然后将其截断为“删除”旧日志行。虽然截断操作非常快，但副本可能很长(取决于日志文件的大小)。此外，在复制操作(请记住，它可能很慢)和截断之间的时间内，可能会丢失一些日志条目。由于这些原因，默认情况下，对能够重新加载和重新创建其日志文件的服务不使用复制截断。另一方面，如果服务器无法重新加载/重新创建日志文件，则复制截断是您最安全的选择。换句话说，它不需要任何服务级别的支持。rsyslog上游项目强烈建议不要使用这种模式。

Answer 2

作为rsyslog作者来说，抄写实际上是一个非常糟糕的选择。它本质上是动态的，使用它几乎可以保证您将丢失日志数据。文件写入的频率越高，丢失的就越多。这不仅是最后一行的一部分，而且可以是几百个，取决于旋转发生时系统的精确时间和状态。

当文件被移动并创建一个新的inode (文件)时，rsyslog会跟踪上一个文件并完成处理。所以在这种情况下你不会有任何损失。保证(除非卸载文件系统.)。

关于" reopenOnTruncate "：我个人认为reopenOnTruncate在其他方面也很活跃，特别是在NFS等方面。一段时间前，我完全删除了这个功能，但后来被说服重新合并了类似的功能。它将保持“实验性”--很可能永远如此，因为我真的知道，在负载非常重的系统上，人们会遇到麻烦。“复制截断”只是没有合适的模式来处理日志文件。

我目前致力于重构imfile (ETA 8.34或8.35)。重构版本可能能够防止由于API争用而意外重新发送，但也不能防止数据丢失--因为这在概念上是不可能的。

Answer 3

这完全取决于流程如何编写日志。

只有当日志消息被附加到文件(例如，copytruncate )时，whatever >> logfile才能工作。

而不是当它重定向输出时(例如whatever > logfile)。