我目前正在合理弱硬件上运行ELK集群（四个 虚拟机，分配4 GB内存，每个内核两个核心。这将在几个月内发生变化，但是现在我们仍然需要摄取并提供日志。
获取一个服务的所有服务器发送日志后 Logstash通过nxlog，收集工作相当好几天。 不久之后，logstash经常开始楔入。该 logstash线程'filterworker.0'将跳转到93然后99％ 服务器的CPU。 Logstash本身不会终止;相反它会继续下去 on，hung，从不向Elasticsearch发送任何新的日志。调试日志会 表明logstash不断按间隔调用flush。它会 永远不会从这种状态恢复;它整个周末都只挂了一个 重新启动它时恢复正常操作。 Logstash将开始 赶上周末的日志然后再快速释放（通常 在五到十分钟内，需要再次重启服务。 一旦日志能够大部分赶上（许多重新启动后来和 一些关闭复杂的grok过滤器），logstash返回到它 以前习惯每隔五到三十分钟打开一次。
我试图将其缩小到特定的配置 将我的日志过滤器换入和换出conf.d目录。少了 配置，logstash将运行更长的时间（长达一个小时 一半）但最终它会再次冻结。
将jstack连接到冻结的filterworker.0线程的PID 返回主要是'get_thread_regs失败的lwp'调试器异常 没有找到死锁。
在调试时运行时，logstash的日志中没有实际的故障 冗长;只是那些缓冲日志。
磁盘未满。
我们当前的配置是三个弹性搜索节点，全部接收 从logstash服务器输入（使用logstash的内部负载 平衡器）。我们有一个logstash服务器。这些都是CentOS 7 机器。 logstash机器运行的是2.1.3版本，源自 Elastic的yum存储库。
我已经玩过改变堆大小，但似乎什么都没有 帮助，所以我目前正在开箱即用的默认值下运行它。我们 只使用一个工作线程，因为它是一个单核虚拟机。我们 曾经使用多线，但这是我注意到的第一件事 这开始发生了。
我不确定下一步该去哪儿。我的理论是logstash的缓冲区是 只是无法处理当前的日志流量;但没有任何 日志中的确凿错误，我不知道如何证明它。我觉得像 可能值得在nxlog和。之间放置redis或rabbit队列 使用logstash缓冲洪水;这看起来是合理的下一步吗？
非常感谢人们可能提出的任何建议。
答案 0 :(得分：0)
你可能会尝试重置Java环境，当我启动我的logstash时，它将高达99％的cpu使用率，但是当JVM重新开始时，cpu的使用率将下降到3％，所以我想，也许你的java环境有问题。 希望得到帮助。
答案 1 :(得分：0)
我使用monit监视服务并检查高CPU使用率，然后根据调查结果重新启动Logstash。一点办法，而不是一个长期的解决方案。 排队系统可能会成功，查看Kafka，Redis或RabbitMQ。您需要测量队列写入与读取队列的差异率。
答案 2 :(得分：0)
听起来你需要更多的Logstash节点。当日志吞吐量由于各种原因而上升时，我们遇到了由CPU引起的类似中断。我们正在进行一次攻击。每秒6K行，有6个节点（仅供参考）。
此外，将Redis管道放在Logstash节点前面允许我们配置Logstash节点以进行相应的拉取和处理。 Redis允许我们的Logstash节点现在过度配置，因为它们不会承受流量的冲击。他们提取日志条目，它们的利用率更加一致（不再崩溃）。