前陣子剛建完公司的 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 只是資料蒐集，後續能否把這些資料商業化才是重點。
