您好，我在通过filebeat将日志发送到logstash时遇到问题： 简而言之 - 无法看到kibana中的日志 - 当拖尾文件日志时我看到了很多这些： 错误logstash / async.go：235无法发布由以下原因引起的事件：read tcp xxxx：36246-＆gt; yy，yy：5045：i / o timeout（yy，yy是logstash地址，5045是开放端口）< / p>
更多细节： 我有~60台安装了filebeat 6.1.1的机器和一台安装了logstash 6.2.3的logstash机器。 一些文件节点成功发送其日志，而一些文件节点抛出我上面提到的错误。 那些非错误的文件标记发送旧日志 - 意味着我可以在logstash调试日志中看到一些日志时间戳是2或3天前
Logstash使用内存为35％，峰值时cpu使用率接近75％， 在filebeat机器的netstat -tupn输出中，我可以看到已建立的与filebeat的logstash连接。
有人可以帮我找到问题吗？
答案 0 :(得分：0)
它看起来像logstash性能问题。 CPU使用率可能太高内存可能更多。将最小（Xms）和最大（Xmx）堆分配大小增加到= [主机中的总数 - 1]，（将1 G加到Os）并将其设置为等于（xms = xmx）
此外，您可以运行另一个logstash实例并将filebeat输出平衡到这些2，看看会发生什么。
需要考虑的更多事项：
效果清单
检查输入源和输出目的地的性能：
Logstash的速度与其连接的服务一样快。 Logstash只能以其输入和输出目的地的速度消耗和生成数据！ 检查系统统计信息：
<强> CPU
请注意CPU是否被大量使用。在Linux / Unix上，您可以运行top -H来查看由线程分解的进程统计信息以及总CPU统计信息。 如果CPU使用率很高，请跳到有关检查JVM堆的部分，然后阅读有关调整Logstash工作程序设置的部分。
<强>内存
请注意Logstash在Java VM上运行。这意味着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）堆分配大小设置为相同的值，以防止堆在运行时调整大小，这是一个非常昂贵的过程。 调整Logstash工作人员设置：
首先使用-w标志扩展管道工作者的数量。这将增加可用于过滤器和输出的线程数。如果需要，可以安全地将其扩展到多个CPU内核，因为线程可能在I / O上变为空闲。 您还可以调整输出批量大小。对于许多输出，例如Elasticsearch输出，此设置将对应于I / O操作的大小。对于Elasticsearch输出，此设置对应于批量大小。