Elasticsearch 填坑記

前言

        技術的發展突飛猛進，傳統企業數據庫Oracle、SqlServer、DB2，Mysql等在今日不斷的被各類大廠自研數據庫取代，固然也有相似Elasticsearch等優秀的知足海量數據所使用的開源數據庫。

       我司多個日誌審計與態勢感知項目中，也沒有免俗，選擇了Elasticsearch做爲咱們的日誌存儲與搜索引擎。關於Elasticsearch基礎知識就不作更多介紹了，隨便搜索下，有大量的介紹和使用文檔。

       本文主要介紹咱們在多個項目中，使用Elasticsearch過程當中，各類填坑記錄。

       在具體的生產環境中，我相信你們不會用Windows做爲Elasticsearch的運行服務器的，因此下文基本都是以Linux（Centos7）爲主要的運行環境。

       如下內容，僅供參考，實際遇到的問題，都須要在運維過程當中，去仔細分析，查閱文檔。解決問題的方法可能很簡單，關鍵是能準確的定位問題，分析問題。

• 安裝

       Elasticsearch安裝就很少闡述了，主要記住：建立非root用戶，修改linux系統參數，修改jvm運行參數，修改Elasticsearch運行參數，這4個主要部分。

       因爲Elasticsearch版本迭代比較快，不一樣的版本個別參數可能已經變動或廢棄，因此修改前必定要認真閱讀對應版本的官方文檔，該參數是否還有效，這個地方是一個坑，須要重點注意。

 

• 運行與系統調優

       Elasticsearch的安裝其實仍是比較簡單的，可是在實際運行中，各類各樣的問題就來了。在實際運行中出現的問題，其實主要仍是數據量的問題，隨着數據量的增加，就會出現各類資源問題，須要隨時解決和調優。

1.內存問題

       官方建議Elasticsearch每一個節點jvm配置內存不要大於系統總內存的一半同時不要大於32G。

       Elasticsearch自己在運行過程當中，隨着數據量的增長，內存的使用會愈來愈多，gc回收會愈來愈慢，最終致使Elasticsearch雖然活着，但不響應任何請求。

       這種狀況下，擴充節點是個選項，可是大多數的狀況，預算是固定的，硬件資源也是固定的，只能採起其餘辦法。

• 數據要根據業務作成多索引的方式，由於每一個索引都是佔用內存的，多索引纔有可能關閉部分歷史數據索引，釋放內存。最好作成定時任務，按照規則關閉不用的索引。

• 定時對索引進行合併（merge segment）

• jvm垃圾回收機制能夠考慮配置爲 UseG1GC 

• 即便按照官方說明配置成32G如下，好比31G，在短期數據量暴增的狀況下，容易帶來linux oom問題，若是存在這種狀況，建議再配置小一點。

2.文件句柄問題

       linux中，全部的一切都與文件有關，實時打開的文件句柄數是有限制的，Elasticsearch能夠看着是基於文件的數據庫，隨着數據量的增長，打開的句柄愈來愈多，就會致使系統中止對外響應，好比ssh登陸不上去等問題。

       這種狀況，首先建議調整linux內核參數，修改系統打開的最大文件句柄數量。

       其次仍是要控制索引的數量，不要無限制的增加下去，想辦法控制同時打開的文件句柄數量。

 3.硬盤問題

       硬盤固然是讀寫速度越快越好，數據量比較大的環境能夠考慮冷熱數據分離。

       須要注意的是當Elasticsearch數據所在的硬盤空間使用超過80%以上時，就可能出現數據再也不寫入該節點的狀況，因此須要定時監測硬盤使用量。

       另外，不太建議使用經過網絡掛載的硬盤空間。

       總的來講硬盤有關的問題相對少點，就很少說了。

 4.其餘問題

       如下的問題，多是在特定的環境下，特定的版本上出現的。

       運行環境，vmware+centos7.4 ， kernel 3.x，3個ES節點，各64G內存。

       問題1：3個節點中，有2個數據節點頻繁宕機，kernel異常日誌提示watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [java:5783]。

       各類搜索，建議升級內核版本，大於4.13.0-1017。

       辛辛苦苦給2個節點升級內核，具體方法，自行百度，升級內核的坑就很少說了。

       問題2：升級內核後，問題1基本解決，可是在短期數據流暴增的狀況下，出現OOM問題。

       分析緣由，應該仍是jvm內存設置爲31G，es索引底層索引內存請求加上jvm內存請求可能超出系統總物理內存（畢竟還有其餘程序也要佔用內存），致使OOM問題。解決辦法，jvm內存適當調小一點。

       固然也能夠調整內核參數，取消OOM特性（不建議在生產環境使用）。

       問題3：最鬱悶的狀況，解決完上述兩個問題後，系統平均10多分鐘就宕機一次，系統日誌無報錯，只在vcenter控制檯上，提示kernel BUG at       drivers/net/vmxnet3/vmxnet3_drv.c:1441!。繼續搜索，發現這是vmware的一個bug，在特定狀況下出現：

       Linux VM is running kernel >= 4.8

       HW version of VM is >=13

       ESXi version is 6.5

       解決辦法：

              修改虛擬機vmx配置文件，添加vmxnet3.rev.30 = FALSE

              或者 設置ethtool -G ethX rx-mini 0，ethX爲網卡名稱