阿里云Elasticsearch 智能化运维实践
背景
??Elasticsearch作為一個開箱即用的搜索引擎，其豐富的功能和極低的使用門檻吸引著越來越多的公司和用戶選擇它作為搜索和數據分析的工具。用戶在運維Elasticsearch集群時往往會遇到很多難題，具體來說有下面列舉的幾點：
- 使用方式往往比較粗糙，默認的設置并不適合每一個集群和業務，非精細化的設計將會極大的增加集群隱患；
- 集群出現問題，無法及時定位原因、尋找解決方案，低效的溝通或者解決問題的方式可能會使得問題變得愈發嚴重；
- ES提供的監控指標繁雜，指標多，意義不明確，需要一定的專業知識才可以理解，缺乏全局視角；
- 此外，集群潛在的異常無法發現，更不能及時規避風險。
??隨著越來越多的用戶選擇使用阿里云ES服務來支持搜索和分析業務，上述這些問題越發明顯，用戶和實例數量的快速增長，讓我們沒有太多的精力去逐一對接所有用戶的問題，這無形中大大降低了我們和用戶雙方的效率。基于阿里云ES的智能運維系統EYou正是為了解決上面問題才出現的，它用來幫助用戶自主診斷阿里云ES實例健康狀況，探測潛在風險并提供解決方案。
EYou
總體概述
??首先以醫院作為類比可能會更容易理解EYou的設計思路。
當病人生病就醫時，會去醫院找到對應科室的醫生，醫生通過詢問，化驗等手段收集信息后然后根據自己的專業知識去診斷病因，并尋求治療方案。而當病情嚴重的時候則可能需要多個科室的醫生來綜合治療。而人們在日常并未感覺身體不適的時候，同樣可以去體檢中心體檢，以便及時發現可能存在的問題，通過保持良好的生活習慣來預防病情或者盡早治療以免病情嚴重。
EYou的核心思想和上述就醫流程類似，通過專家經驗和集群數據的雙重驅動來診斷集群狀況，先收集數據（化驗，詢問）然后使用專業知識（經驗）來找到問題的原因或者提前發現問題（體檢），給出合理的解決方案。希望成為最了解ES集群的存在，可以在全局視角判斷集群的運行狀況，也可以在日常的時候引導用戶使用規范；可以在集群出現問題時查找原因，也可以發現集群的潛在風險。
系統架構
EYou整體上分為5個部分：
數據采集，數據采集模塊是專門收集EYou系統所需要的各類信息。
- 目標ES集群的基本配置信息，包括settings，mapping，status，shard，segment等等；
- Shuttle，shuttle是阿里云ES集群的調度服務，EYou在這里獲得集群的資源和生命周期等信息；
- Log，我們有一個專門用于收集ES各類日志的logcenter，它可以提供集群的異常日志，gc日志等，另外EYou會使用logcenter做一部分的機器學習任務以及全局統計信息；
- Metric，metric包括機器指標（CPU使用率，load大小等）和ES服務指標（latency，QPS等）。
數據處理，數據處理模塊用于對采集到的數據加工整理。由于采集到的原始數據多且零散，所以很多無法被上層模塊直接使用，為了屏蔽數據的復雜性，數據處理模塊會對數據加工以提供更友好的數據。包括查詢語句的模板歸一，機器學習結果的輸出，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觸發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自身
阿里云Elasticsearch技術釘釘交流群
2017年9月，阿里云基于開源Elasticsearch及商業版X-Pack插件，提供云上ELK服務，同時阿里云ES技術人員會分享解決云上業務痛點的案例實踐，敬請期待！了解產品更多詳情 https://data.aliyun.com/product/elasticsearch
阿里云Elasticsearch?1核2G首月免費試用，開始云上實踐吧
總結
以上是生活随笔為你收集整理的阿里云Elasticsearch 智能化运维实践的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： java调用dll
- 下一篇： Netty 源码（ChannelHand