在大型日志文件上使用tail -f很好吗

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

如果可能的话，我的文件甚至会翻转并且我还有一个其他问题需要整理:)。对我来说，不能使用tail -F（--follow=name），因为-F我要在其上运行的服务器不支持。我的计划是使用一个脚本来启动此尾部并进行轮询以查找文件是否已翻转。如果是，则杀死尾巴并重新启动。有更好的方法吗？

logs monitoring tail

— 马诺吉内华达州
source

您的意思是“杀死tail”，对不对？

— 斯特凡Gimenez的

是的，“杀死尾巴”，找不到。谢谢，编辑了问题

— Manoj NV

如果2 GB大小的文件不包含换行符，tail如何工作？

Answers:

在我的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.我还尝试禁用未记录的inotify支持---disable-inotify，以防万一。}

— 斯特凡·吉梅内斯（StéphaneGimenez）
source

真正的男人读了源（：

— 吉尔斯'SO-停止成为邪恶

@吉尔斯。如果OP（或读者）还不知道如何阅读源代码，我将无法教他。告诉他使用起来容易strace

— 得多

事实上，在一个系统上tail -F不支持，机会是strace不可用......

— 斯特凡希门尼斯

truss是Solaris上的相应实用程序。

— 吉尔（Gilles）“所以，别再邪恶了”，

它显示了类似的寻道电话。llseek（0，0，SEEK_CUR）= 0，llseek（0，0xFFFFFFFFFFF5FFF6

— SEEK_END

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

— 吉尔斯（Gillles）
source

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

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

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

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

— 弓箭
source