Elasticsearch在華泰證券內部的應用實踐

建設背景及現狀

背景

在過去，華泰證券具有系統運維繁瑣、日誌不能長期儲存、日誌資料價值沒有挖掘、大資料領的一角的四個特點。所謂的系統運維繁瑣是指系統多、獨立建設、服務產生大量日誌、運維時需要登陸伺服器才能檢視日誌等，遇到複雜問題時需要一臺臺地登陸伺服器搜尋相關日誌檔案才能定位問題。日誌沒有長期儲存是指根據證券行業相關的法律法規，日誌數需要儲存一定年限並支援隨時調取。日誌資料價值沒有挖掘是指日誌中包含非常有價值的資訊，但並沒有深入挖掘。大資料領域的一角是指Hadoop主要面向的是結構化資料的儲存和分析，而不是非結構化資料的儲存和分析。

現狀

2016年6月，華泰證券開始建設Elasticsearch叢集，由於機房透過專線進行聯網，當資料量太大時機房會被佔用，所以機房不一樣會導致需要許多個叢集，因此叢集需要單獨建設。

Elasticsearch建設容量為120T，每天資料量會佔用 600G甚至800G的空間，由於Elasticsearch容量比較小，所以日誌儲存時間非常短，有些只能儲存兩個月甚至幾個星期，只有非常重要的資訊才能儲存三個月。在未來計劃將Elasticsearch容量進行擴充套件，預期日誌儲存時間能夠達到一年甚至兩年以上。

華泰證券支援的應用包括支撐漲樂、理財平臺、監控資料分析、日誌分析等。例如理財平臺，Elasticsearch能夠發現使用者的行為，並給出使用者建議方案。展望未來，中國證券市場已發生根本性轉變，現在正面臨著歷史性的發展機遇。面對新的形勢，華泰證券將繼續堅持規範化、集團化、國際化發展戰略，進一步加快公司做大做強步伐，力爭儘快使公司成為具有核心競爭力的、業務規模和綜合實力進入行業前列的證券控股集團。

應用實踐

日誌搜尋

在日誌搜尋中，日誌源是整個ES上的第一部分，跟ELK的採集與展示基本一致，它主要分為日誌採集模組、採集代理、日誌儲存模組、日誌檢索模型、前臺展示模組、採集管理模組。其中，日誌採集模組又分為採集代理和日誌處理兩部分。採集處理主要用來做資料的快取，日誌處理是把日誌消費成兩份，一份消費進入到ES，另一份消費日誌進行實時報警。日誌檢索模組是對日誌進行展示，它主要有三個功能，即統一的日誌檢索、實時監控報警、統一許可權管理功能。

日誌分析

資料來源不僅包括日誌，還包括網頁和資料庫。資料來源透過morphling將資料採集放置三個庫中，三個庫包含ES、HDFS和Hbase。ES最終進行日誌檢索，HDFS和Hbase最終透過Hve和Kylin進行展現。

鏈路管理系統

在鏈路管理系統中，由資料質量分析、統一採集框架、自動化部署、應用監控構成一個內迴圈系統。

對於資料質量的分析而言，使用者要求資料一條不能多一條不能少，但在實際上對於分支系統來講，由於鏈路比較長，所以幾乎是不可能實現資料不多不失的。但是鏈路管理系統可以做到的是去輔助鏈路發現是否有質量問題，並在這個系統裡及時對資料質量進行分析。例如，一個節點傳送1000萬條資料，透過鏈路管理最終進入到ES。在這個過程中可能會出現資料延遲的現象，若傳送的曲線和對應傳送的最終曲線一致，那麼就說明資料質量是完好的，即最終資料是一致的。若兩條曲線不能擬合，那就說明有資料已丟失。

對於統一採集框架而言，即在採集的日誌檔案中對日誌進行標準化，比如，日誌應該包含什麼等等。

自動化部署即對部署過程的每一個步驟自動化，目前部署過程涉及到應用、環境和部署流程等。要實現自動化首先要做的是將需要部署的應用、環境和流程進行建模，並需要一個自動化部署系統來支撐。

應用監控，即每天巡檢只需要透過應用監控系統就能夠知道每個鏈路上的節點是否正常，如果異常則會報警。

使用經驗

華泰證券Elasticsearch的使用有六點注意事項。

第一，磁碟目錄不易過多，建議做Raid5，便於管理;

第二，索引分片根據實際需求分配;

第三，冷熱分離策略;

第四，根據業務特點進行叢集部署，透過TrieNode連線;

第五，後設資料不易過多，過多會導致叢集效能降低，觸發BUG;

第六，設定節點離開時的分片延遲分配策略。

其中，對於磁碟目錄不易過多問題而言，需採取官網建議，即採取裸盤。由於單臺機器有24塊盤，長期執行當某些分片都落在某個磁碟上時，會造成單盤的讀寫熱點問題，且這些分片的資料量較大時，這個磁碟的空間很容易爆滿，ES也不會進行資料均衡，一旦磁碟超過閾值，整個節點都不會再分配分片，造成空間利用率不足的情況。可以透過新購機器的磁碟做Raid5和統一管理來解決這個問題，這樣既不會出現某一塊盤爆滿，還能提升整體I/O吞吐，將老機器逐漸替換。

Jstat發現Master持續GC時，CPU使用率會非常高。可能存在有記憶體洩露問題，這就需要把Jmap記憶體dump出來分析，接著進一步分析漏點，最後修改原始碼並驗證。

對於使用經驗中的第六點， 叢集執行很久後，叢集分片就會越來越多，後設資料就會多，當叢集分片個數超過1.5萬時，效能將出現問題，執行一段時間後叢集執行不正常，節點就會無法連線Master。在叢集實際運轉過程中，往往會出現節點由於網路或GC等原因從叢集中離開、日常運維時節點下線的情況。叢集為避免資料丟失，必須保證每個分片都有足夠的副本，所以會產生大量的網路I/O，而這時如果節點重新加入叢集，Elasticsearch會為該節點再次分配資料分片，這將再次導致大量的網路I/O操作。在這種情況下，叢集長期處於Yellow狀態，恢復非常緩慢，透過監控可看到分片處於遷移狀態。這就需要透過設定引數index.unassigned.nod_left.delayed_timeout來延遲分片平衡的時間，為運維和節點異常恢復提供緩衝時間。

【本文轉自 雲棲社群  作者：雲跡九州  原文連結：】