在日志文件上使用 grep / awk 运行脚本会影响应用程序写入日志文件吗？

Question

多年来，我一直使用脚本监控日志文件并从日志文件中提取数据，并且从未质疑过大多数人认为理所当然的基本工具集。特别是 grep 和 awk 几乎被社区中的每个人使用。

我发现了当前的 grep 错误（有些可以追溯到几年前）： http://savannah.gnu.org/bugs/?group=grep

来自 GNU grep 2.6.3 的手册页：

已知错误

{n,m} 构造中的大量重复计数可能会导致 grep 使用大量内存。此外，某些其他晦涩的正则表达式需要指数级的时间和空间，并可能导致 grep 耗尽内存。

反向引用非常慢，可能需要指数级时间。

还有 GNU Awk 3.1.7 的手册页：

错误

鉴于命令行变量分配功能，不需要 -F 选项；它只是为了向后兼容而保留。

语法上无效的单字符程序往往会溢出解析堆栈，从而产生相当无用的消息。在完全一般的情况下，此类程序非常难以诊断，而且这样做的努力确实不值得。

我对例如限制感兴趣

• 使用复杂的正则表达式时，
• 未旋转的超大文件，
• 每百分之一秒写入数千次的日志

是否只是监视脚本的内存使用情况以确保它没有使用大量内存？

为可能需要很长时间执行的脚本实现超时功能是否是一种好习惯？

人们在使用这些工具构建解决方案时还使用其他良好的标准和结构吗？

我找到了对等价的 findstr 非常有用的答案，可以让我更好地理解 Windows 环境中的脚本： What are the undocumented features and limitations of the Windows FINDSTR command?

Answer 1

awk/grep 命令都以只读模式读取日志文件，因此不会因为应用程序（写入模式）和 awk/grep 程序（读取-唯一模式）。

awk/grep 程序肯定会占用 CPU 和内存，这会影响应用程序写入日志文件。这种影响类似于使用系统资源的任何其他进程。 grep/awk 命令也不例外。根据 grep/awk 脚本正在执行的操作，它们可能会消耗大量 CPU/RAM。任何语言写得不好的代码都可能导致问题。正如 cmets 中所建议的，最好限制监控过程。 ulimit 和cgroups 是可用于限制资源的选项。另一个不错的选择是使用timeout，如果脚本花费的时间超过预期，它会终止脚本。