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群集的性能。