在这里忍受我。我花了大约一个星期左右熟悉ELK Stack。
我有一个运行ELK堆栈的工作单盒解决方案，我已经了解了如何转发多种类型的日志，以及如何将它们放入不同的ES索引。
这一切都运作良好，我想扩展运营。
我的问题是如何扩展解决方案以满足更多数据需求/需求。
当前的解决方案是处理较小的数据子集，并且工作正常，但我想聚合批次更多数据。例如，我目前正在推送来自4个邮箱服务器的邮件跟踪日志，我想做同样的事情，但是对于40个邮箱服务器，以及更多更繁忙的邮箱服务器。
我还希望从客户端访问服务器推送IIS日志文件，有18个CAS服务器，在高峰时间每个服务器大约30分钟的IIS日志大小为120MB，有近100万条记录。
这一数据量最有可能会破坏运行ELK的单个框。
我还没有真正研究过它，但我读到ES允许某种形式的集群添加更多实例，同样适用于Logstash吗？ Kibana应该在多个服务器上运行吗？还是与Logstash和ES不同的服务器？
答案 0 :(得分：4)
如果你正在对记录进行大量处理 - groks，conditions等，你将使用logstash达到限制。观察机器的cpu利用率以获取提示。
对于elasticsearch本身，它是关于RAM和磁盘IO的。群集中有更多节点应该同时提供这两个节点。
使用两个elasticsearch节点，您将获得冗余（两台计算机上的副本）。添加第三个，您就可以开始实现IO好处（将两个副本写入三台机器扩展IO）。
最终数据节点将在机器上具有64GB的RAM，其中31GB分配给elasticsearch。
您可能希望添加非数据节点，这些节点处理要编制索引的数据的路由以及运行查询时的“减少”阶段。将其中两个置于负载均衡器后面。
答案 1 :(得分：0)
正如Alain所说，添加更多ES节点将提高性能（并为您提供冗余）。
在logstash方面，我们有两个logstash服务器加入ES - 目前我们只是指示不同的服务器登录到不同的logstash服务器，但我们可能会在前面添加一个HA-Proxy层来做这是自动的，并再次提供冗余。
对于Kibana，我不会太担心 - 据我所知，大多数处理都是在客户端浏览器中完成的，而这并不是更依赖于ES集群的性能。 / p>