在大型日志文件上使用 tail -f 可以吗

Question

我想监视一个大日志文件（接近 1 GB）是否有错误。我希望这接近实时（几秒钟延迟很好）。我的计划是使用tail -f | grep. 在长时间运行时使用这种方法是否有任何性能问题，比如从零字节到 1 GB？是否有任何用于此类监控的标准做法。请注意，我想使用 Solaris 10 上可用的标准 unix 命令来执行此操作。

如果可能的话，我的文件甚至会翻转，我还有一个问题需要解决:)。使用tail -F( --follow=name) 对我来说不是一个选项，因为-F在我想要运行它的服务器中不支持。我的计划是使用一个脚本来启动这个尾部并轮询以查找文件是否被翻转。如果是，则杀死尾部并重新启动它。有什么更好的方法吗？

Answer 1

在我的 linux 系统（GNU coreutils 8.12）上，我能够检查（使用strace）tail -f¹ 使用lseek系统调用快速跳过大部分文件：

lseek(3, 0, SEEK_CUR)                   = 0
lseek(3, 0, SEEK_END)                   = 194086
lseek(3, 188416, SEEK_SET)              = 188416

这意味着被跟踪文件的大小无论如何都无关紧要。

也许您可以检查是否同样适用于您的系统。（显然，情况应该如此。）

—
^{1.---disable-inotify为了以防万一，我还尝试使用无证文件禁用 inotify 支持。}

Answer 2

如果在常规文件（而不是管道）上调用它，GNU tail 和 OpenBSD tail（除非用 调用-n +N）都会寻找文件的末尾，然后向后工作以找到应该开始打印的行。我不知道 Solaris 是否也这样做，但这是一种合理的方法，所以我希望大多数 unices 也这样做。因此，文件的大小与性能无关。

Answer 3

我每天都这样做。我通常使用 扫描我们的测试和生产服务器上的十几个日志tail -f logs/*.{log,err,out}。初始负载有点多（取决于全局文件的数量），但之后，流式传输是实时的。

我没有发送到 grep，而是使用exec中的功能screen，因为我通常希望查看所有输出（用于与问题相关的完整回溯和消息）。例如，

!:sed -n s/.*Exception.*/\007/p

当发现“异常”一词时，使终端发出蜂鸣声（或闪烁）。