ElasticSearch / Logstash / Kibana如何處理日志流量中的峰值

Question

處理標准ELK設置中寫入ElasticSearch集群的日志消息激增的最佳方法是什么？

我們在AWS中使用標准ELK（ElasticSearch / Logstash / Kibana）設置來滿足我們網站的日志記錄需求。

我們在負載均衡器后面有一個自動縮放的Logstash實例組，該組記錄到另一個負載均衡器后面的ElasticSearch實例的自動縮放組。 然后我們有一個服務Kibana的實例。

對於日常業務，我們運行2個Logstash實例和2個ElasticSearch實例。

我們的網站在活動期間經歷短時間的高流量 - 在這些活動期間，我們的流量增加了約2000％。 我們提前知道這些事件。

目前，我們只是在事件期間臨時增加ElasticSearch實例的數量。 然而，我們遇到的問題是我們隨后縮減得太快，這意味着我們丟失了碎片並損壞了我們的索引。

我一直在考慮將auto_expand_replicas設置為"1-all"以確保每個節點都擁有所有數據的副本，因此我們無需擔心擴展或縮小的速度。 將所有數據傳輸到新節點的開銷有多大？ 我們目前只保留大約2周的日志數據 - 總共大約50gb。

我還看到人們提到使用單獨的自動縮放組的非數據節點來處理搜索流量的增加，同時保持數據節點的數量相同。 這有助於處理繁重的情況，例如我之前提到過的事件嗎？

Answer 1

我的建議

您最好的選擇是使用Redis作為Logstash和Elasticsearch之間的代理：

這在一些舊的Logstash文檔中有所描述，但仍然非常相關。

是的，您將看到正在生成的日志與最終登陸Elasticsearch之間的最小延遲，但它應該是最小的，因為Redis和Logstash之間的延遲相對較小。 根據我的經驗，Logstash很快就可以通過Redis的積壓工作。

這種設置還為您提供了更強大的設置，即使Logstash發生故障，您仍然可以通過Redis接受這些事件。

只是縮放Elasticsearch

至於你的問題是關於額外的非數據節點是否會有助於寫入繁重的時期：我不相信，不。 當您看到正在執行大量搜索（讀取）時，非數據節點很棒，因為它們將搜索委托給所有數據節點，然后在將結果發送回客戶端之前聚合結果。 它們消除了聚合數據節點結果的負擔。

寫入將始終涉及您的數據節點。

我不認為添加和刪除節點是一個很好的方式來迎合這一點。

您可以嘗試在高峰期調整線程池和隊列 。 我們通常說你有以下幾點：

threadpool:
  index:
    type: fixed
    size: 30
    queue_size: 1000
  search
    type: fixed
    size: 30
    queue_size: 1000

因此，您可以獲得均勻的搜索和索引線程。 在高峰時間之前，您可以將設置（ 在運行中 ）更改為以下內容：

threadpool:
  index:
    type: fixed
    size: 50
    queue_size: 2000
  search
    type: fixed
    size: 10
    queue_size: 500

現在你有更多的線程正在進行索引，允許更快的索引吞吐量，而搜索則放在backburner上。 為了更好的衡量，我還增加了queue_size以允許更多的積壓來建立。 但是，這可能無法按預期工作，建議進行實驗和調整。