中通在2015年的時候已經開始預研並在生產環境使用Elasticsearch集羣，隨後在科技中心開始大規模實踐。隨着業務的快速發展，ES集羣數量和規模也愈來愈大，版本的跨度也逐漸拉大，統一管理這些es集羣逐漸變成了首要問題。
在這種狀況下，咱們研發了中通ES運維監控平臺--ESPaaS，提供了ES集羣的自動化部署，統一監控，實時告警和索引管理等一系列運維管理功能。網絡
截止2020年7月底，中通生產上運行的es集羣數量已經有40+個，節點數量500+個，單個集羣的節點數從3個到100多個，單日新增文檔數量近600億，單日數據增量超過100tb，數據總量已經超6PB。架構
不一樣的階段，關注和解決的問題也不同，ESPaaS平臺的版本迭代主要分爲如下幾個階段：運維
本文主要介紹的是中通ESPaaS運維平臺在統一監控告警上的實踐，主要關注如下內容：jvm
-
集羣實時監控；分佈式
-
告警輸出；性能
-
集羣診斷。優化
架構設計
prometheus做爲如今最流行的監控解決方案之一，通過一番調研，決定以prometheus爲核心，搭建監控體系，監控告警的總體架構以下圖所示：spa
整個監控模塊圍繞prometheus進行展開，主要的功能有：線程
-
自研exporter獲取線上ES集羣的關鍵指標信息，暴露的rest接口能根據請求中的集羣名稱返回不一樣集羣的監控信息；架構設計
-
prometheus採起pull模式，按期請求exporter以獲取ES集羣的監控信息；
-
grafana配置監控大盤對監控數據進行可視化；
-
告警應用給予promQL按期計算是否有指標異常，指標細化到各個ES集羣；
-
告警渠道目前主要採用釘釘，及時發送告警信息到釘釘羣，快速定位問題集羣、節點信息；
-
告警設立優先級，同時觸發優先級高的先行發送，直指問題本質；
-
延遲告警避免偶發抖動形成的頻繁告警與告警恢復；
-
診斷模塊整合實時信息和歷史監控趨勢，發現潛在問題，消滅問題於萌芽狀態。
集羣監控與告警
爲了保證ES集羣的穩定運行，咱們須要從多個維度對ES集羣進行監控，主要的維度信息以下：
-
資源類，包含部署ES機器的cpu、內存、網絡、磁盤等信息；
-
集羣級，ES集羣自己是否處於健康狀態，從一個較大的維度確認集羣是否正常；
-
節點級，ES做爲一個分佈式的應用，每一個節點的狀態會最終影響集羣的狀態，須要對節點的jvm、線程池等進行監控。
最終造成的監控大盤以下：
告警配置：
告警信息：
集羣診斷
上面的監控告警能幫助咱們快速定位集羣的現有的問題，可是從長遠角度來看，咱們須要在問題出現以前提早發現、提早解決，儘量避免生產故障。帶着這樣的思考，咱們決定提供ES集羣的診斷能力--將對問題的排查手段和實踐經驗進行復用，將其標準化，最終沉澱在咱們的集羣診斷模塊中。
診斷模塊的設計思想是核心指標量化，利用量化的指標來幫助咱們明確優化方向和快速定位問題，總結平常的問題排查和解決經驗，咱們將診斷分爲五個維度：
集羣診斷基本涵蓋了平常處理ES集羣問題的大部分場景，經過集羣診斷，咱們可以提早發現集羣的潛在問題，經過提早擴容，更改索引設計與使用方式等行爲來規避可能的生產問題。在集羣監控和診斷的保駕護航下，2020年至今ESPaaS運維平臺管理的ES集羣沒有發生生產故障。
診斷建議的界面：
實踐經驗
在監控告警和集羣診斷的實際開發與使用過程當中，咱們也積累了不少的經驗。
一、ES集羣忽然沒法寫入了，應用日誌中所有都是寫入失敗的記錄？
在實際的問題排查中，發現大部分狀況下都是集羣部分節點磁盤超過90%觸發當前節點的索引read_only，致使沒法寫入。
解決措施：
# 解除索引只讀
PUT _all/_settings
{
"index.blocks.read_only_allow_delete":"false"
}
發生磁盤超過水位線的問題，一方面是對索引或者集羣的容量規劃作的不到位，另外一方面也是監控告警的缺少致使問題最終發生了。
在引入監控告警後，咱們對各個ES集羣的磁盤設置了告警水位線，80%是告警的閾值，在集羣的磁盤超標前，可以發送告警信息，讓咱們有時間和業務方提早溝通清理數據釋放部分磁盤空間。
在集羣診斷中，咱們依據磁盤過去一段時間的使用比例線性預測一天、七天後的使用量，提早和業務方進行溝通，對可能出現問題的集羣提早進行擴容，避免出現資源瓶頸。
二、監控大盤的信息解讀
監控大盤的引入，將監控指標以圖表的形式展現出來，讓咱們可以直觀的看到監控指標的當前數值和變化趨勢，能幫助咱們快速對ES集羣的資源利用率，性能瓶頸有一個大體的認知。經過下面的監控信息能夠看出：
-
集羣當前是green狀態，節點分佈是 1master+13data節點；
-
主分片數量197，分片數量較少，不會出現單個節點數千個分片的狀況；
-
多數節點節點在7:00-8:00gc較爲頻繁，此時段可能爲業務高峯期，可能會有大量的寫入或者查詢等操做；
-
總體堆內存佔用在50-70%之間，證實集羣總體資源暫時沒有瓶頸；
-
gc次數和gc耗時的面板發現有節點出現毛刺，能夠經過分片監控查看是否分片分配不均勻致使了熱節點。
三、頻繁告警的處理
在告警功能初次上線時，有些集羣的資源使用率比較高，部分節點內存佔用超標了，當時的告警策略是一分鐘檢測一次，若是有異常就產生告警。這會帶來頻繁告警的問題，若是問題修復的時間較長，那每分鐘都會產生一次告警信息，形成告警信息轟炸，告警羣的告警信息所有都是同一條，不只讓人厭煩，還會致使開發小夥伴忽略其餘的告警內容。
面對這種狀況，參考一些業界的告警設計，在初次告警後，再次觸發的告警再也不立馬發出，而是給予不一樣的時間間隔，若是在告警半小時後，問題沒有解決，指標依舊異常，則產生第二次釘釘告警，告警間隔逐級順延直至恢復，大大減小了重複的告警數量。
四、延遲告警的設計
內部的日誌ES集羣，會存儲近2月的日誌索引，可是7天前的默認會關閉，因爲常常有同窗須要排查歷史問題須要開啓已經closed掉的索引，在索引開啓的過程當中，會形成日誌ES集羣的短暫red/yellow狀態，致使觸發告警後又當即恢復，在釘釘告警羣中大量刷消息。
面對這種可以自恢復的問題，咱們決定設置延遲告警的策略，若是在告警觸發的數分鐘內(可配置)，告警指標恢復正常則再也不進行告警，將這類偶發的抖動問題變成靜默狀態，再也不干擾正常的告警。
腳踏實地，展望將來
一、ES容器化
kubernetes的應用愈來愈普遍，ES+k8s將是中通在有狀態服務上的探索與嘗試。
二、ES-Proxy--提供搜索服務
將來但願將ES提供的搜索能力標準化，用戶經過proxy使用ES，沒必要關心具體ES集羣部署和索引分佈。
做者丨 祝萬強 來源丨 科技中通（ID：gh_2b0467268990） dbaplus社羣歡迎廣大技術人員投稿，投稿郵箱： editor@dbaplus.cn