Python2：如何可靠地解析另一个进程中打开的日志文件？

Question

我试图编写一个Python脚本来解析另一个守护进程生成的日志文件。这是在Linux上完成的。我希望能够可靠地解析日志文件。在

换句话说，我们定期运行一个脚本，逐行读取日志文件，并对每一行执行一些操作。日志记录脚本需要查看日志文件中可能结束的每一行。它可以通过cron每分钟运行一次。在

这是一个我不确定如何解决的问题。因为另一个进程对文件有一个写句柄，所以它可以在我从同一日志文件中读取的同一时间写入while。在

另外，我们经常希望清除这个日志文件，这样它的大小就不会失控。但是生成日志文件的进程除了定期停止、截断或删除文件，然后重新启动之外，没有办法清除该文件。（我觉得logrotate有一些方法可以做到这一点，但我不知道logrotate是否依赖于守护进程的感知，或者它是否真的关闭并重新启动守护进程等等。更不用说我不想让其他日志轮换，只需要这一个特定的日志；我不希望这个脚本要求其他可能的用户设置logrotate。）

问题是：

1. 由于记录器进程可以在我已经有一个打开的文件句柄时写入文件，所以我觉得我很容易错过日志文件中的记录。在
2. 如果记录器进程决定停止、清除日志文件并重新启动，而日志分析器没有在同一时间运行，则日志条目将丢失。类似地，如果日志分析器导致日志记录器在分析时停止日志记录，那么由于日志记录器守护进程没有侦听而丢弃的信息也可能丢失。在
3. 如果我要使用类似“注意上次以来文件的大小，如果文件更大，则在那里查找”这样的方法，那么如果出于某种原因，在两次运行之间，记录器重置了日志文件，但后来又有理由记录比上次包含的还要多的日志，会发生什么？E、 我们执行一个日志分析循环。我们得到了50个日志条目，所以我们设置了一个标记，我们已经读取了50个条目。下次运行时，会看到60个条目。但是，这60个文件都是全新的；自上次运行日志以来，该文件已被清除并重新启动。相反，我们最终找到了51个条目，却漏掉了50个条目！不管怎样，它都不能解决需要定期清除日志的问题。在

我无法控制记录器守护程序。（假设我们在这里讨论的是类似syslog的东西。这不是syslog而是相同的想法-一个非常关键的进程会打开一个日志文件。）所以我没有办法更改它的日志记录方法。它在初始化时启动，打开一个日志文件，然后写入其中。我们希望能够清除日志文件并对其进行分析，以确保在某个时刻通过Python脚本获取每个日志条目。在

理想的情况是：

1. 日志守护进程在系统初始化时运行。在
2. 通过cron，Python日志分析器每分钟运行一次（或者每5分钟运行一次或者其他认为合适的方法）
3. 日志分析器从当前日志文件中收集每一行，并立即将其截断，导致日志文件被清空。Python维护列表中的原始内容。在
4. 然后，记录器继续使用现在为空的文件继续进行其业务。同时，Python可以在空闲时继续解析内存中的Python列表中的条目。在

我已经非常，非常模糊地研究了先进先出，但不确定这是否合适。在这种情况下，日志分析器将作为守护进程本身运行，而原始记录器将写入FIFO。我对这个领域知之甚少，也不知道这是否是一个解决方案。在

所以我想问题有两个：

1. 如何从Python可靠地读取写入日志的每个条目？包括日志是否增长、是否重置等
2. 如果可能，如何截断具有打开写句柄的文件？（理想情况下，这将是我可以从Python中做的事情；我可以做类似logfile.readlines(); logfile.truncate这样就不会丢失任何条目。但这看起来好像除非logger进程很清楚地意识到这一点，否则最终导致的问题会比解决的问题更多。）

谢谢！在

Answer 1

我看不出有什么特别的原因使您不能读取syslogd创建的日志文件。您是说您正在使用一个类似于syslog的进程，并且该进程保持您的日志文件处于打开状态？既然您是在征求意见，我建议您使用syslog！http://pic.dhe.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=%2Fcom.ibm.ztpf-ztpfdf.doc_put.cur%2Fgtpc1%2Fhsyslog.html

不管怎样，它是有效的-使用它。写入日志的一些简单方法是使用logger命令：

logger “MYAP: hello”

在python脚本中，您可以这样做：

^{pr2}$

还要记住，您可以实际配置syslogd。http://pic.dhe.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=%2Fcom.ibm.ztpf-ztpfdf.doc_put.cur%2Fgtpc1%2Fconstmt.html

另外，关于空日志的问题，sysclog没有清除日志。还有其他的工具，比如在debian上使用logrotate。在这种情况下，如果您的日志是空的，您可以检查logrotate创建的备份文件。在

既然您的问题似乎出在日志工具中，我的建议是使用syslog进行日志记录。以及其他旋转原木的工具。然后您可以轻松地解析日志。如果通过任何方式（我甚至不知道syslog是否可能）丢失了一些数据，请记住，无论如何，您将在下一次迭代中获得这些数据；）

另一个想法是复制你的日志文件并使用复制。。。在