Logstash Filebeat-未能发布事件，原因是：读取tcp x.x.x.x:36196->；x、 x.x.x:5045:i/o超时

嗨，我在通过filebeat向logstash发送日志时遇到问题： 简而言之-在kibana中看不到日志-在跟踪filebeat日志时，我看到了很多这样的内容： 错误logstash/async.go:235未能发布事件，原因是：读取tcp x.x.x:36246->y.y，y.y:5045:i/o超时（y.y，y.y是logstash地址，5045是开放端口）

更多详情： 我有约60台安装了filebeat 6.1.1的机器和一台安装了logstash 6.2.3的logstash机器。 有些filebeats成功地发送了日志，而有些则抛出了我上面提到的错误。 这些非错误filebeats发送旧日志-意味着我可以在logstash调试日志中看到一些日志的时间戳是2或3天前的

在峰值时，Logstash内存使用率为35%，cpu使用率接近75%， 在filebeat机器的netstat-tupn输出中，我可以看到从filebeat到logstash的已建立连接

---

有人能帮我找到问题吗？

看起来像是logstash性能问题。Cpu使用率可能太高，内存可能会更多。将最小（Xms）和最大（Xmx）堆分配大小增加到=[主机中的总量-1]，（对操作系统而言为1 G），并将其设置为等于（Xms=Xmx）

此外，您还可以运行另一个logstash实例，并将filebeat输出平衡到这两个实例，看看会发生什么

需要考虑的更多事项：

绩效检查表

检查输入源和输出目标的性能：

Logstash的速度与它所连接的服务的速度一样快。Logstash只能以输入和输出目的地的速度消耗和生成数据！ 检查系统统计信息：

CPU

注意CPU是否被大量使用。在Linux/Unix上，您可以运行top-H来查看按线程划分的进程统计信息，以及总CPU统计信息。 如果CPU使用率很高，请跳到关于检查JVM堆的部分，然后阅读关于调优Logstash worker设置的部分

内存

请注意，Logstash在Java虚拟机上运行。这意味着Logstash将始终使用您分配给它的最大内存量。 寻找其他使用大量内存并可能导致Logstash交换到磁盘的应用程序。如果应用程序使用的总内存超过物理内存，则可能发生这种情况。 I/O利用率

监视磁盘I/O以检查磁盘饱和。

如果您使用的是可能会使存储饱和的Logstash插件（如文件输出），则可能会发生磁盘饱和。 如果遇到大量错误，迫使Logstash生成大量错误日志，也可能发生磁盘饱和。 在Linux上，您可以使用iostat、dstat或类似于监视磁盘I/O的东西

监控网络I/O是否饱和。

如果使用执行大量网络操作的输入/输出，则可能发生网络饱和。 在Linux上，您可以使用dstat或iftop之类的工具来监视网络。 检查JVM堆：

通常情况下，如果堆大小太小，CPU利用率会急剧上升，导致JVM不断地进行垃圾收集。 检查此问题的一种快速方法是将堆大小增加一倍，并查看性能是否有所提高。不要将堆大小增加到超过物理内存量。为操作系统和其他进程留出至少1GB的空闲空间。 通过使用随Java分发的jmap命令行实用程序或使用VisualVM，可以对JVM堆进行更精确的测量。有关更多信息，请参阅分析Heapedit

始终确保将最小（Xms）和最大（Xmx）堆分配大小设置为相同的值，以防止堆在运行时调整大小，这是一个非常昂贵的过程。 调整日志存储工作程序设置：

首先，通过使用-w标志来增加管道工人的数量。这将增加过滤器和输出可用的线程数。如果需要，可以安全地将其扩展到多个CPU核，因为线程在I/O上可能会变得空闲。 您还可以调整输出批次大小。对于许多输出，例如Elasticsearch输出，此设置将对应于I/O操作的大小。对于Elasticsearch输出，此设置对应于批次大小