qualname python WatchedFileHandler仍然在旋转后写入旧文件



python timedrotatingfilehandler backupcount (2)

使用logrotate的copytruncate选项。 从文档

copytruncate

在创建副本之后,原位截断原始日志文件,而不是移动旧的日志文件,也可以创建一个新的日志文件,可以在某些程序无法关闭其日志文件时使用,因此可能会继续写入(附加)到以前的日志文件永远。 请注意,复制文件和截断文件之间的时间片非常短,因此可能会丢失一些日志记录数据。 当使用此选项时,创建选项将不起作用,因为旧的日志文件保留在原位。

我一直在使用WatchedFileHandler作为我的python日志文件处理程序,所以我可以使用logrotate (在Ubuntu 14.04上)来旋转我的日志,你知道这是文档所说的。 我的logrotate配置文件看起来像

/path_to_logs/*.log {
        daily
        rotate 365
        size 10M
        compress
        delaycompress
        missingok
        notifempty
        su root root
}

一切似乎都工作得很好。 我使用logstash将我的日志发送到我的elasticsearch集群,一切都很好。 我为我的调试日志添加了第二个日志文件,这个日志文件被旋转了但是没有被logstash监视。 我注意到,当这个文件被旋转时,python只是继续写入/path_to_debug_logs/*.log.1并从不开始写入新文件。 如果手动/path_to_debug_logs/*.log.1 ,则会立即切换并开始写入/path_to_debug_logs/*.log

这对我来说似乎很奇怪。

我相信发生了什么事是logstash总是拖尾我的非调试日志,这些触发logrotate后如何触发切换到新文件。 如果logrotate在没有切换的情况下被调用两次,则log.1文件被移动并压缩到log.2.gz,而python不能再登录并且日志丢失。

很明显,这里有一些hacky的解决方案(比如一个cronjob,它会把我所有的日志记录下来),但是我觉得我一定是做错了。

我使用WatchedFileHandlerlogrotate而不是RotatingFileHandler的原因有很多,但主要是因为它会在旋转后很好地压缩我的日志。

更新:

我尝试了在我的日志旋转配置脚本的末尾添加一个手动尾巴的可怕的黑客攻击。

sharedscripts
postrotate
    /usr/bin/tail -n 1 path_to_logs/*.log.1
endscript

果然,大多数情况下,这种方法是有效的,但是有时候没有任何明确的理由随机失败,所以不是一个解决方案 我也尝试了一些不太冒进的解决方案,我修改了WatchFileHandler检查文件是否改变的方式,但没有运气。

我很确定我的问题的根源是日志存储在网络驱动器,这是在某种程度上混淆了文件系统。

我正在使用RotatingFileHandler将我的旋转移动到python,但是如果有人知道处理这个问题的正确方法,我很想知道。


Answer #1

WatchedFileHandler会在写入日志文件之前检测到设备和/或inode更改时执行翻转。 也许没有被logstash监视的文件在其设备/ inode logstash不到变化? 这将解释为什么处理程序不断写入它。





rotation