Logstash 执行模型

以下简要介绍 Logstash 如何在内部处理事件。

并发处理事件

您可以配置 Logstash，使其拥有多个输入侦听事件。每个输入都在自己的线程中运行，以避免输入相互阻塞。如果同时有两个传入事件，Logstash 会并发处理这两个事件。

接收事件并可能应用输入编解码器后，Logstash 将事件发送到工作队列。管道工作器或批处理器执行其余的工作，包括过滤器和输出以及输出中使用的任何编解码器。每个管道工作器也在自己的线程中运行，这意味着 Logstash 可以同时处理多个事件。

批量处理事件

管道工作器以批处理方式从工作队列中消费事件，以优化整个管道的吞吐量。

Logstash 批量工作的一个原因是，无论管道工作器一次处理多少事件，某些代码都需要执行。与其为 100 个事件执行该代码 100 次，不如为 100 个事件的批次运行一次更高效。

另一个原因是，一些输出插件将事件分组为批次。例如，如果您向 OpenSearch 发送 100 个请求，OpenSearch 输出插件会使用批量 API 发送一个将 100 个请求分组的单个请求。

Logstash 通过两个配置选项确定批次大小——一个表示最大批次大小的数字和批次延迟。批次延迟是 Logstash 在处理未处理的事件批次之前等待的时间。如果将最大批次大小设置为 50，批次延迟设置为 100 毫秒，那么当工作队列中有 50 个未处理的事件，或者已经过去 100 毫秒时，Logstash 就会处理一个批次。

即使未达到最大批次大小也处理批次的原因是为了减少处理延迟并及时继续处理事件。这对于处理少量事件的管道非常有效。

假设您有一个管道，它处理来自 Web 服务器的错误日志并将其推送到 OpenSearch。您正在使用 OpenSearch Dashboards 分析错误日志。因为您可能正在处理相当少的事件，所以可能需要很长时间才能达到 50 个事件。Logstash 会在达到此阈值之前处理事件，否则，错误出现在 OpenSearch Dashboards 中将会出现长时间的延迟。

默认的批次大小和批次延迟适用于大多数情况。除非您需要精确优化性能，否则无需更改默认值。

基于 CPU 核优化

管道工作器的数量与节点上的 CPU 核数成正比。如果您在具有 2 个 CPU 核的服务器上运行 5 个工作器，则这 5 个工作器将无法并发处理事件。另一方面，在具有 10 个 CPU 核的服务器上运行 5 个工作器会限制 Logstash 实例的吞吐量。

Logstash 不会运行固定数量的工作器（这在某些情况下会导致性能不佳），而是检查实例的 CPU 核数，并选择管道工作器的数量，以优化其在运行平台上的性能。例如，您的本地开发机器可能不具备生产服务器的相同处理能力。因此，您无需为不同的机器手动配置 Logstash。