☰

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

tag-icon • tag-icon logs monitoring tail
在大型日志文件上使用 tail -f 可以吗

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

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

答案1

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

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

这意味着跟踪文件的大小无论如何都不重要。

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

—
1.我还尝试禁用 inotify 支持与 undocumented ---disable-inotify，以防万一。

答案2

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

答案3

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

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

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

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

相关内容