ElasticSearch 該注意的幾個設計方法

2019-09-06 Log

前陣子剛建完公司的 ELK 環境,該是來整理過程中遇到的一些瓶頸跟注意事項,在這之前有先談過架構面「elastic 現代化的 ELK/EFK Log 架構大補帖」,現在這邊來談談有哪些設計重點應該要小心的。

ElasticSearch 是吃效能怪獸

如果要玩 ElasticSearch 勢必一定要有花錢的準備,ElasticSearch 的效能著重在 CPU 運算、RAM (Index Cache)、Disk I/O、Disk Usage ..

目前的環境每天會產出約 1TB 的資料量,基本上需要吃掉 4 台實體設備約 24 CPU Intel X5670、96GB RAM (實際 Elasticsearch 使用 80GB),Disk 則是使用 SSD,要檢測設備可以使用 dstat 檢查幾個面向。

  • 如果有 Write / Read 效能議題,使用 dstat 檢查 Disk I/O 效率,如果有透過 Network 可能也是瓶頸之一,最好的方式是採用 Local disk。
  • 如果有 Read 效能議題,檢查搜尋的條件是否符合最小條件的 index,讓 ElasticSearch 直接找到 index 而不是透過 scan。
  • ElasticSearch 是否太過頻繁 GC,透過 Kibana 的 Monitor 介面可以查到 ElasticSearch GC 的頻率,建議不要太過頻繁,否則 ElasticSearch 光是 GC 就飽了。

Elasticsearch、Logstash 各組件至少要 10GB 網卡

因為會有非常大資料量的傳輸,建議 Elasticsearch、Logstash 這兩個角色一定要 10GB 網卡,否則再好的效能都會被網路瓶頸卡住。

Forwarder 使用 file 採集,而不是由 tcp / udp 拋資料

這邊很建議大家採用 filebeat,本身 filebeat 有 queue 的機制,並且 register 會記錄上次採集到哪一個點,從這個位置往下採集。

透過 tcp / udp 都有可能遇到網路延遲、中斷而導致資料遺失,用 file 的方式除非被 logrotate 掉了,否則資料遺失的機率並不高。

不要使用 Logstash 做為 Forwarder

初期的時候大家都採用 Logstash 做為 Forwarder,雖然 Logstash 很強大,但是也相對很耗費資源,通常 Logstash 會拿來作為中介 ETL 的角色,Forwarder 就由又快又輕的 beat 來擔任吧。

ElasticSearch 的 timestamp 很重要

預設 ElasticSearch 不會處理 timestamp,預設是以丟進去 ElasticSearch 的時間為主,但 Log Date 才是重點,可以參考「Logstash 透過 filter 把 event timestamp 換成 log 日期

總結是 ElasticSearch 的維護是蠻大的一個坑,需要愛心耐心才能把一個 ElasticSearch 調整到 “可用” 的狀態,而 ELK 只是資料蒐集,後續能否把這些資料商業化才是重點。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

彙整

分類

展開全部 | 收合全部

License

訂閱 Mr. 沙先生 的文章

輸入你的 email 用於訂閱

%d 位部落客按了讚: