ELK堆栈和缩放

Question

在这里忍受我。 我花了最后一周的时间来熟悉ELK Stack。

我有一个运行ELK堆栈的有效的单盒解决方案，并且对如何转发不止一种类型的日志以及如何将它们放入不同的ES索引有基本的了解。

一切工作都很好，我想扩大规模。

我的问题是更多如何扩展解决方案以涵盖更多数据需求/要求。

目前的解决办法是处理数据的一个较小的子集，并且工作正常，但我想聚集了很多数据。 例如，我目前正在推送来自4个邮箱服务器的邮件跟踪日志，我想这样做，但要配置40个邮箱服务器，还有很多繁忙的服务器。

我还想从客户端访问服务器推送IIS日志文件，有18台CAS服务器，并且在高峰时间每台服务器大约30分钟的IIS日志大小为120MB，有近100万条记录。

这种数据量很可能会使运行ELK的单个框崩溃。

我还没有真正研究过它，但是我读到ES允许某种形式的集群来添加更多实例，Logstash也一样吗？ Kibana是否应在多台服务器上运行？ 还是Logstash和ES的服务器不同？

Answer 1

如果您在记录上进行大量处理（例如黑眼症，条件病等），则将使用logstash达到限制。请注意机器的CPU使用率以获取提示。

对于Elasticsearch本身，它与RAM和磁盘IO有关。 群集中有更多节点应同时提供这两个方面。

使用两个elasticsearch节点，您将获得冗余（两台计算机上都有一个副本）。 添加第三个，您就可以开始实现IO的好处（将两个副本写入三台计算机可扩展IO）。

最终数据节点将在计算机上具有64GB的RAM，其中31GB分配给elasticsearch。

您可能需要添加非数据节点，这些节点将在运行查询时处理要编制索引的数据的路由以及“减少”阶段。 将其中两个放在负载均衡器后面。

Answer 2

如Alain所述，添加更多ES节点将提高性能（并为您提供冗余）。

在logstash方面，我们有两个logstash服务器馈入ES-目前，我们只是将不同的服务器定向到不同的logstash服务器，但是我们可能会在前面添加一个HA-Proxy层来自动执行此操作，并再次提供冗余。

使用Kibana，我不必担心太多-据我所知，大多数处理都是在客户端浏览器中完成的，而这更多地取决于ES群集的性能。