阿里雲Elasticsearch 智慧化運維實踐
背景
Elasticsearch作為一個開箱即用的搜尋引擎，其豐富的功能和極低的使用門檻吸引著越來越多的公司和使用者選擇它作為搜尋和資料分析的工具。使用者在運維Elasticsearch叢集時往往會遇到很多難題，具體來說有下面列舉的幾點：
- 使用方式往往比較粗糙，預設的設定並不適合每一個叢集和業務，非精細化的設計將會極大的增加叢集隱患；
- 叢集出現問題，無法及時定位原因、尋找解決方案，低效的溝通或者解決問題的方式可能會使得問題變得愈發嚴重；
- ES提供的監控指標繁雜，指標多，意義不明確，需要一定的專業知識才可以理解，缺乏全域性視角；
- 此外，叢集潛在的異常無法發現，更不能及時規避風險。
隨著越來越多的使用者選擇使用阿里雲ES服務來支援搜尋和分析業務，上述這些問題越發明顯，使用者和例項數量的快速增長，讓我們沒有太多的精力去逐一對接所有使用者的問題，這無形中大大降低了我們和使用者雙方的效率。基於阿里雲ES的智慧運維繫統EYou正是為了解決上面問題才出現的，它用來幫助使用者自主診斷阿里雲ES例項健康狀況，探測潛在風險並提供解決方案。
EYou
總體概述
首先以醫院作為類比可能會更容易理解EYou的設計思路。
當病人生病就醫時，會去醫院找到對應科室的醫生，醫生通過詢問，化驗等手段收集資訊後然後根據自己的專業知識去診斷病因，並尋求治療方案。而當病情嚴重的時候則可能需要多個科室的醫生來綜合治療。而人們在日常並未感覺身體不適的時候，同樣可以去體檢中心體檢，以便及時發現可能存在的問題，通過保持良好的生活習慣來預防病情或者儘早治療以免病情嚴重。
EYou的核心思想和上述就醫流程類似，通過專家經驗和叢集資料的雙重驅動來診斷叢集狀況，先收集資料（化驗，詢問）然後使用專業知識（經驗）來找到問題的原因或者提前發現問題（體檢），給出合理的解決方案。希望成為最瞭解ES叢集的存在，可以在全域性視角判斷叢集的執行狀況，也可以在日常的時候引導使用者使用規範；可以在叢集出現問題時查詢原因，也可以發現叢集的潛在風險。
系統架構
EYou整體上分為5個部分：
-
資料採集 ，資料採集模組是專門收集EYou系統所需要的各類資訊。
-
資料處理 ，資料處理模組用於對採集到的資料加工整理。由於採集到的原始資料多且零散，所以很多無法被上層模組直接使用，為了遮蔽資料的複雜性，資料處理模組會對資料加工以提供更友好的資料。包括查詢語句的模板歸一，機器學習結果的輸出，QPS，latency等指標的二次聚合計算。
-
診斷分析層 ，按照規則判斷某類指標是否有異常。這裡最核心的是診斷規則，結合積累經驗和叢集資料利用Hawkeye平臺逐項檢測叢集狀況，發現異常點並給出解決方案。按照資料和Action（解決方案），在大類上分為5類：
- 容量管理，這裡的容量管理包括磁碟，記憶體，CPU，網路等幾乎所有與硬體資源相關的診斷；
- 叢集配置管理，細分為全域性配置（clusterSettings，叢集拓撲等）和節點配置（與yml相關的全部）；
- 索引管理，索引的mapping，settings（包括索引切分，冷熱索引，無效欄位）等一切與索引操作相關的診斷
- 查詢優化，~
- 版本管理，ES的版本迭代很快，每個版本都會解決老的bug並引入新的特性，一些特定問題可以通過版本升級解決，比如6.x版本failover的效率提升。
-
診斷層 ，診斷層面向用戶問題，如果說診斷分析層是醫院的科室，那麼診斷層就是導診臺，根據病情提供科室建議，即管理使用者問題和診斷分析之間的對映。
-
接入層 ，提供EYou診斷結果，目前可通過web控制檯和釘釘機器人接入，並且提供了API供其他系統呼叫。
上述架構是經過數次演進而來的，可以看到將診斷分析和實際問題區分開，使得它們各自都可以更方便的擴充套件。而面向問題出發對使用者而言也會更加直接友好，也便於我們形成效果反饋的閉環驅動EYou的優化。
診斷分析
EYou的核心是診斷分析模組，而診斷分析則是以“ 診斷項 ”為核心來幫助使用者運維其叢集。診斷項由資料輸入和診斷規則組成，是可以直接反饋ES叢集某一個狀態或行為是否合理的指標。通過收集雲上使用者的問題，尋找普遍存在或影響最大的問題，重點解決。不停的更新迭代逐步完善EYou的診斷範圍和問題，豐富其診斷項。目前，EYou已經覆蓋到叢集、節點、索引三個維度超過20個診斷項，可幫助使用者發現叢集異常、資源以及使用規範、日常運維等多個方面的問題。
每一個診斷項都有其特定的邏輯策略，這裡以叢集顏色異常診斷，shard合理性診斷，儲存資源診斷這3個出現頻率較高的診斷項為例介紹一下。
1. 叢集顏色異常診斷
ES會通過紅黃綠3種顏色來表示其資料分片是否丟失。ES內部的decider模組決定了資料分片是否可以被載入到某個節點上，共包含如下所示的14種decider。顏色診斷就是通過decider的結果來找到異常原因和解決方案。EYou通過ES提供的 _cluster/allocation/explain API 獲得類似於下面的decider資訊。
// decider awarenesscluster_rebalanceconcurrent_rebalance disk_thresholdenablefiltermax_retry node_versionrebalance_only_when_active replica_after_primary_activesame_shard shards_limitsnapshot_in_progressthrottling
// node_allocation_decisions.deciders.decider
{
"index": "ft2",
...
"allocate_explanation": "cannot allocate because allocation is not permitted to any of the nodes",
"node_allocation_decisions": [
{...},
{
"node_id": "RgmxR4vXSEuK32Dtnn8dyw",
"node_attributes": {...},
"node_decision": "no",
"deciders": [
{
"decider": "same_shard",
"decision": "NO",
"explanation": "the shard cannot be allocated to the same node on which a copy of the shard already exists [[ft2][4], node[RgmxR4vXSEuK32Dtnn8dyw], [R], s[STARTED], a[id=F5NuAQQhRlCid2PoQu8IdA]]"
},
{
"decider": "disk_threshold",
"decision": "NO",
"explanation": "allocating the shard to this node will bring the node above the high watermark cluster setting [cluster.routing.allocation.disk.watermark.high=90%] and cause it to use more disk space than the maximum allowed [90.0%] (free space after shard added: [8.240863369353132%])"
}
]
},
{...}
]
}
比如當decider觸發disk_threshold時，診斷策略將會分析使用者的磁碟容量和實際資料量，計算出合適的磁碟容量；當觸發enable，shards_limt等配置相關的decider時，將會檢查叢集配置，並給出正常的配置方式。通過這種方式使用者可以更直觀的瞭解到叢集異常原因，也可以輕鬆的找到解決方案。
2. shard合理性診斷
計算索引shard的個數是建立索引時最重要的一個環節，shard的合理性不僅僅會影響索引讀寫的效能，還可能會對系統負載造成較大的影響。然而很多使用者在建立索引會直接選擇ES的預設配置，這種方式固然簡單，但預設的設定並不適合每一個叢集和業務，不合理的shard將大大增加叢集隱患。比如以下3種常見的case：
- 一個4節點的叢集，ES預設的5個shard勢必會導致其中一個節點會比其它3個節點多出一倍的資料量和訪問流量，當請求增加時，該叢集會大概率出現單點瓶頸。
- 一個1TB大小的索引，分配了5個shard，單shard資料達到200G，這絕對會大大降低讀寫效能，並且在叢集管理上會更加麻煩，比如後續可能無法通過新增節點的方式來提高效能。
- 一個1GB大小的索引，分配了5個shard，這在一定程度上就是資源浪費，會增加ES對meta資訊的維護，monitor的監控讀寫的成本。
shard合理性診斷就是為了解決上述這些問題。它會從索引的shard個數和節點的shard平衡兩個方面去診斷。
在索引層面，會去診斷單個索引的shard個數和大小是否合理。為了簡化模型，它遵循一個原則，資料量才能真正決定shard個數的合理範圍，而節點資源僅僅是對結果進行微調。根據索引的資料大小，EYou將索引分為小索引，中索引，大索引，超大索引4類，每一個分類的索引都設定了單shard大小的上下限和少量的溢位閾值。在計算出合理shard的區間後，首先會判斷索引當前shard個數是否需要調整，然後會根據當前叢集的節點資源（規格，節點數）來縮小選擇區間，儘可能去匹配節點數並減少成本和資源的浪費。同時EYou會根據日常支援的客戶情況，不停的改進上述模型，調整其閾值和策略。
在節點層面，會去診斷節點間的資料負載是否一致。ES自身的平衡策略主要從磁碟空間，主副shard分佈，全域性shard個數，分配意識等維度去決定shard的分佈，這個策略在大部分情況已經可以做到很好了。但是它並沒有意識到不同索引不同shard的實際請求流量和計算資源的消耗是不同的，那麼勢必會出現節點間負載不同的情況，尤其是索引較多的叢集中。當資料節點負載偏差較大時，一方面會影響到叢集的穩定性，另一方面會極大的浪費叢集資源。EYou在發現叢集資料節點負載偏差較大時，會通過索引QPS、query/fetch/index/refresh/flush等指標計算出資源消耗最大和最小的shard，然後使用ES 的_cluster/reroute 去調整shard分佈。當然這裡後續可以繼續改進的是從全域性層面上使用ES平衡策略來改造裝箱演算法，從而在整個叢集層面更大範圍和精細的調整優化。
3. 儲存資源診斷
儲存資源是否充足是影響ES叢集的重要因素之一。由於ES的自動平衡策略，各個節點上的資料分佈大體是均勻的，這意味著當一個節點空間不足時很難有其它空閒節點供其選擇。所以提前發現容量問題及時擴容是可以大大降低分片丟失風險的。
EYou會根據當前叢集中索引的主shard大小，並利用容量管理模型計算出叢集安全的磁碟容量。容量管理模型是通過對線上叢集的統計分析以及實際經驗構建的，在後面EYou會引入索引的分詞方式，編碼壓縮方式，mapping設定等因子進行更精確的計算。
事實上擴磁碟時可以選擇加節點，也可以在單節點上擴容，那麼如何抉擇成為了需要考慮的事情。EYou會通過對叢集規格，使用場景，叢集負載，磁碟大小等指標的計算，給出最終擴容建議，包括單節點擴容，增加新節點，同時增加節點和單節點容量等3種方案。在上面的一些計算環節，EYou會簡化某些因素，這樣在大大降低我們的決策和計算成本的同時也可以保證至少會得到一個次優結果。
其實可以看到，不同的診斷項之間是存在一定的關聯性的，比如叢集顏色診斷是可以和儲存資源診斷建立聯絡的。最初我們也嘗試去尋找一種辦法去建立診斷項之間的DAG，但事實上這張圖會很複雜，畢竟任何一個系統內部的指標，配置等都不是孤立的。所以後面我們改變了思路，診斷項之間相互獨立，並不試圖去作為其它項的輸入因子，而是在最上層通過具體的問題去建立關係，這也是我們後面設計調整的主要思想之一。
實際案例
目前EYou已經提供給技術支援和值班同學使用，並即將產品化提供給更多的使用者使用。它通過報告的方式將結果告知使用者，可以通過控制檯和釘釘機器人接入。
上述報告截圖是一個實際的值班問題。使用者叢集異常變成紅色，那麼通過EYou值班同學可以很直接的看到，是因為磁碟容量不足導致了資料分片丟失，並且建議使用者增加叢集的磁碟總容量到9000G，具體的擴容策略是增加資料節點到5個，並且單機擴容到1.8T。下面的這組截圖是在使用者的叢集負載較高時EYou得出的結論，發現了其頻繁變更狀態，shard不合理，負載不均衡等問題，並分別給出了修改建議。
總結&展望
EYou目前已經解決了使用者的一部分問題，尤其是在容量管理方面取得了一個不錯的開端。但可以看到對於整個ES運維來說也只是剛剛起步，在未來有更多的事情要做。ES作為一個分散式的搜尋系統，從硬體（磁碟效能，網路開銷，計算資源）到軟體（搜尋引擎），從架構（分散式系統）到使用方式（引數調優）等很多方面都會影響到其使用，而持續不斷的探索優化ES叢集，幫助使用者更高效的解決問題正是EYou的本能。在未來我們將會做以下方面的嘗試：
- 首先我們會持續優化每一個診斷策略，使結果更精確，引入更多的輸入因子，做到叢集的“千人千面”。
- 其次我們會重點解決查詢優化這類問題，這是我們目前在支援大客戶時投入較多精力也是比較棘手的問題。
- 然後我們希望可以將診斷結果賦能給其它更多的系統和場景，比如叢集排程和生命週期的管理。
- 最後一點也是我們正在規劃中的事情，除了從內部技術支援同學獲取EYou的使用反饋外，還要從使用者側直接得到效果評測資料。一個系統的，閉環的效果反饋機制可以幫助我們查漏補缺和持續優化演進EYou自身