调整和分析 Logstash 管道性能
编辑调整和分析 Logstash 管道性能编辑
Logstash 监控 API 中的流量指标可以深入了解事件在管道中的流动方式。它们可以揭示管道是否受到资源限制、管道的哪些部分消耗的资源最多，并在调整时提供有用的反馈。
工作线程利用率编辑
当管道的 worker_utilization 流量指标持续接近 100 时，其所有工作线程都在忙于处理管道的过滤器和输出。我们可以通过查看插件级别的 worker_utilization 和 worker_millis_per_event 流量指标来查看管道中*哪些*插件正在消耗可用的工作线程容量。利用这些信息，我们可以直观地了解如何调整管道设置以添加资源、如何查找和消除浪费的计算，或者意识到需要扩展下游目标的容量。
一般来说，插件分为两类
-
CPU 密集型：在*不*使用网络或磁盘 IO 的情况下对事件内容执行计算的插件往往会受益于逐步增加
pipeline.workers，只要进程有可用的 CPU；一旦 CPU 耗尽，额外的并发性会导致吞吐量*降低*，因为管道工作线程会争夺资源，并且上下文切换所花费的时间会增加。 -
IO 密集型：使用网络来丰富事件或传输事件的插件往往会受益于逐步增加
pipeline.workers和/或调整下面描述的pipeline.batch.*参数。这使得它们能够更好地利用网络资源，只要这些外部服务没有施加反向压力（即使 Logstash 正在使用几乎所有可用的 CPU）。
管道的 worker_utilization 距离 100 越远，其工作线程等待事件到达队列的时间就越多。由于大多数管道中的数据量通常不一致，因此目标应该是调整管道，使其拥有足够的资源，以避免在高峰期将反向压力传播到其输入。
队列反压编辑
当管道接收事件的速度快于其处理速度时，输入最终会遇到反压，这会阻止它们接收其他事件。根据所使用的输入插件，反压可以向上游传播，也可以导致数据丢失。
管道的 queue_backpressure 流量指标反映了输入尝试将事件推送到队列中所花费的时间。该指标在不同管道之间无法精确比较，而是允许您将单个管道当前的行为与其自身在一段时间内的行为进行比较。当此指标不断增长时，请查看管道下游的过滤器和输出，以查看它们是否有效地使用了资源、是否分配了足够的资源，或者是否遇到了自身的反压。
持久队列提供持久性保证，并且可以比默认的内存队列吸收更长时间的反压，但是一旦队列已满，它也会传播反压。queue_persisted_growth_events 流量指标可以有效地衡量持久队列正在积极吸收多少反压，并且在管道的生命周期内应该趋向于零（或更低）。负数表示队列正在*缩小*，并且工作线程正在赶上之前出现的延迟。
与调整相关的设置编辑
Logstash 默认值的选择是为了为大多数用户提供快速、安全的性能。但是，如果您发现性能问题，则可能需要修改某些默认值。Logstash 提供以下可配置选项来调整管道性能：pipeline.workers、pipeline.batch.size 和 pipeline.batch.delay。
有关设置这些选项的更多信息，请参阅logstash.yml。
在修改这些选项之前，请确保您已阅读性能故障排除。
pipeline.workers设置确定为过滤器和输出处理运行多少个线程。如果您发现事件正在积压，或者 CPU 未饱和，请考虑增加此参数的值，以便更好地利用可用的处理能力。即使将此数字增加到超过可用处理器数量，也可以获得良好的结果，因为这些线程在写入外部系统时可能会在 I/O 等待状态下花费大量时间。pipeline.batch.size设置定义单个工作线程在尝试执行过滤器和输出之前从队列中收集的最大事件数。较大的批处理大小通常效率更高，但会增加内存开销。输出插件可以将每个批处理作为一个逻辑单元进行处理。例如，Elasticsearch 输出会尝试为接收到的每个批处理发送单个批量请求。调整pipeline.batch.size设置可以调整发送到 Elasticsearch 的批量请求的大小。pipeline.batch.delay设置很少需要调整。此设置调整 Logstash 管道的延迟。管道批处理延迟是指管道工作线程在其当前批处理尚未满时等待每个新事件的最长时间（以毫秒为单位）。在此时间过后，如果没有更多事件可用，则工作线程开始执行过滤器和输出。工作线程在接收事件和在过滤器中处理该事件之间等待的最长时间是pipeline.batch.delay和pipeline.batch.size设置的乘积。
关于管道配置和性能的说明编辑
如果您计划修改默认管道设置，请考虑以下建议
- 正在处理的事件总数由
pipeline.workers和pipeline.batch.size设置的乘积确定。此乘积称为*正在处理的事件数*。在调整pipeline.workers和pipeline.batch.size设置时，请记住正在处理的事件数的值。以不规则间隔间歇性接收大量事件的管道需要足够的内存来处理这些峰值。在jvm.options配置文件中相应地设置 JVM 堆空间（有关详细信息，请参阅Logstash 配置文件）。 - 衡量每次更改，以确保它提高而不是降低性能。
- 确保您留有足够的可用内存来应对事件大小的突然增加。例如，生成表示为大型文本块的异常的应用程序。
- 工作线程的数量可以设置为高于 CPU 内核的数量，因为输出通常会在 I/O 等待条件下花费空闲时间。
- Java 中的线程都有名称，您可以使用
jstack、top和 VisualVM 图形工具来确定给定线程使用哪些资源。 - 在 Linux 平台上，Logstash 使用描述性名称标记其线程。例如，输入显示为
[base]<inputname，管道工作线程显示为[base]>workerN，其中 N 是一个整数。在可能的情况下，其他线程也会被标记，以帮助您识别其用途。
分析堆编辑
调整 Logstash 时，您可能需要调整堆大小。您可以使用VisualVM工具来分析堆。特别是监视器窗格，可用于检查您的堆分配是否足以满足当前工作负载。以下屏幕截图显示了示例监视器窗格。第一个窗格检查配置了太多正在处理的事件的 Logstash 实例。第二个窗格检查配置了适当数量的正在处理的事件的 Logstash 实例。请注意，此处使用的特定批处理大小很可能不适用于您的特定工作负载，因为 Logstash 的内存需求在很大程度上取决于您发送的消息类型。
在第一个示例中，我们看到 CPU 没有得到非常有效的利用。事实上，JVM 经常不得不停止 VM 进行“完全 GC”。完全垃圾回收是内存压力过大的常见症状。这在 CPU 图表的尖峰模式中可见。在配置更有效的示例中，GC 图形模式更加平滑，并且 CPU 的使用方式更加均匀。您还可以看到，在分配的堆大小和允许的最大值之间有充足的净空，这为 JVM GC 提供了很大的工作空间。
使用类似于优秀的VisualGC插件的工具检查详细的 GC 统计信息表明，与在资源密集型 Old Gen“完全”GC 中花费的时间相比，过度分配的 VM 在高效的 Eden GC 中花费的时间非常少。