前情提要:
小弟對ELK仍舊是自己摸索階段,對於硬體需求、提升效能上概念上觀念仍舊不清楚,所以想上來請益,聊聊一些觀念上的想法也好
正題:
虛擬機 機器規格是這樣的,Kafka接收Log,然後透過Logstash轉發到Elasticsearch這樣
172.16.16.1 Kafka+logstash
* CPU:2cores
* RAM:4GB
* SSD:80GB
172.16.16.2 Elasticsearch+Kibana
* CPU:8cores
* RAM:24GB
* SSD:180GB
目前Elasticsearch 分配內存
# Xms represents the initial size of total heap space
# Xmx represents the maximum size of total heap space
-Xms12g
-Xmx12g
-Xss128m
################################################################
## Expert settings
################################################################
##
## All settings below this section are considered
## expert settings. Don't tamper with them unless
## you understand what you are doing
##
################################################################
查看Kibana統計,一天大約有120萬~200萬筆Log
看起來是相當大的一個量,我也清楚單單RAM24GB是遠遠不夠的,但如前面所說
因為對這方面也很沒有概念跟想法,所以想藉此討論,大約多少的硬體配置是合理的,然後再合理的配置情況下,該如何去優化Elasticsearch
你應該要建 ELK Cluster, 而不是讓單台 ES 去扛所有的 search 作業....
一般人沒管過 infra 的話, 常誤解效能只來自: CPU/RAM/Disk/Network 這幾個硬體因素, 但其實 OS Kernel 本身內部還有諸多限制, 即便你將 CPU 加到幾百 Core, RAM 加到幾 TB, 效能也不會線性上升, 因為內部被 Kernel 本身卡住....這有許多參數可以調整, 也有許多參數不能調整....
例如, 網路 TCP/UDP Port 最多只能有六萬多個, 你怎麼調都不可能超過這個限制....TCP Windows 的大小? ulimit 的大小? disk queue 的 strategy? NPROC 數量? fs.nr_open? fs.file-max? pid 數量? backlog?....
ELK 是用 Java 開發的, 所以 Java 參數也緊密影響的你的效能: Heap size 怎麼訂才是合理? 開到最大一定最快嗎? xms, xss, xmx 參數要怎麼組合才是最佳化?....
相對來說, 利用 ELK Cluster 做橫向的 Scale-out 擴展, 比較不需要那麼深入去了解單機裡面的 tuning 技術, 對背後沒有 Infra 團隊支援的應用或資料工程師來說, ELK Cluster 只要加機器, 通常效能就會上去...(當然這裏面還有 indices 放置的問題, sharding 的問題, load balance 等等...不過這些比較接近資料工程師能夠自行理解和控制的領域)
調效能也不能只看 log 總數, 還要看你每秒鐘進來的量, 200萬筆是1小時內倒進來? 還是分10小時倒進來? EPS 是多少? 對效能的需求有很大差別....
官方也有效能調校的文件可參考:
Performance Troubleshooting
或是有很多人貢獻他們的經驗:
Tuning of ELK stack for the expected throughput
ELK 調校通常是不斷 Try & Error 的往復迭代過程, 不會是一個固定數字比例 (像是多少 EPS 用多少 CPU/RAM 這樣) 就能套用在全部的場景.