背景

??Elasticsearch作為一個(gè)開箱即用的搜索引擎，其豐富的功能和極低的使用門檻吸引著越來越多的公司和用戶選擇它作為搜索和數(shù)據(jù)分析的工具。用戶在運(yùn)維Elasticsearch集群時(shí)往往會(huì)遇到很多難題，具體來說有下面列舉的幾點(diǎn)：

• 使用方式往往比較粗糙，默認(rèn)的設(shè)置并不適合每一個(gè)集群和業(yè)務(wù)，非精細(xì)化的設(shè)計(jì)將會(huì)極大的增加集群隱患；
• 集群出現(xiàn)問題，無法及時(shí)定位原因、尋找解決方案，低效的溝通或者解決問題的方式可能會(huì)使得問題變得愈發(fā)嚴(yán)重；
• ES提供的監(jiān)控指標(biāo)繁雜，指標(biāo)多，意義不明確，需要一定的專業(yè)知識(shí)才可以理解，缺乏全局視角；
• 此外，集群潛在的異常無法發(fā)現(xiàn)，更不能及時(shí)規(guī)避風(fēng)險(xiǎn)。

??隨著越來越多的用戶選擇使用阿里云ES服務(wù)來支持搜索和分析業(yè)務(wù)，上述這些問題越發(fā)明顯，用戶和實(shí)例數(shù)量的快速增長(zhǎng)，讓我們沒有太多的精力去逐一對(duì)接所有用戶的問題，這無形中大大降低了我們和用戶雙方的效率。基于阿里云ES的智能運(yùn)維系統(tǒng)EYou正是為了解決上面問題才出現(xiàn)的，它用來幫助用戶自主診斷阿里云ES實(shí)例健康狀況，探測(cè)潛在風(fēng)險(xiǎn)并提供解決方案。

EYou

總體概述

??首先以醫(yī)院作為類比可能會(huì)更容易理解EYou的設(shè)計(jì)思路。
當(dāng)病人生病就醫(yī)時(shí)，會(huì)去醫(yī)院找到對(duì)應(yīng)科室的醫(yī)生，醫(yī)生通過詢問，化驗(yàn)等手段收集信息后然后根據(jù)自己的專業(yè)知識(shí)去診斷病因，并尋求治療方案。而當(dāng)病情嚴(yán)重的時(shí)候則可能需要多個(gè)科室的醫(yī)生來綜合治療。而人們?cè)谌粘２⑽锤杏X身體不適的時(shí)候，同樣可以去體檢中心體檢，以便及時(shí)發(fā)現(xiàn)可能存在的問題，通過保持良好的生活習(xí)慣來預(yù)防病情或者盡早治療以免病情嚴(yán)重。
EYou的核心思想和上述就醫(yī)流程類似，通過專家經(jīng)驗(yàn)和集群數(shù)據(jù)的雙重驅(qū)動(dòng)來診斷集群狀況，先收集數(shù)據(jù)（化驗(yàn)，詢問）然后使用專業(yè)知識(shí)（經(jīng)驗(yàn)）來找到問題的原因或者提前發(fā)現(xiàn)問題（體檢），給出合理的解決方案。希望成為最了解ES集群的存在，可以在全局視角判斷集群的運(yùn)行狀況，也可以在日常的時(shí)候引導(dǎo)用戶使用規(guī)范；可以在集群出現(xiàn)問題時(shí)查找原因，也可以發(fā)現(xiàn)集群的潛在風(fēng)險(xiǎn)。

系統(tǒng)架構(gòu)

EYou整體上分為5個(gè)部分：

數(shù)據(jù)采集，數(shù)據(jù)采集模塊是專門收集EYou系統(tǒng)所需要的各類信息。

• 目標(biāo)ES集群的基本配置信息，包括settings，mapping，status，shard，segment等等；
• Shuttle，shuttle是阿里云ES集群的調(diào)度服務(wù)，EYou在這里獲得集群的資源和生命周期等信息；
• Log，我們有一個(gè)專門用于收集ES各類日志的logcenter，它可以提供集群的異常日志，gc日志等，另外EYou會(huì)使用logcenter做一部分的機(jī)器學(xué)習(xí)任務(wù)以及全局統(tǒng)計(jì)信息；
• Metric，metric包括機(jī)器指標(biāo)（CPU使用率，load大小等）和ES服務(wù)指標(biāo)（latency，QPS等）。

數(shù)據(jù)處理，數(shù)據(jù)處理模塊用于對(duì)采集到的數(shù)據(jù)加工整理。由于采集到的原始數(shù)據(jù)多且零散，所以很多無法被上層模塊直接使用，為了屏蔽數(shù)據(jù)的復(fù)雜性，數(shù)據(jù)處理模塊會(huì)對(duì)數(shù)據(jù)加工以提供更友好的數(shù)據(jù)。包括查詢語句的模板歸一，機(jī)器學(xué)習(xí)結(jié)果的輸出，QPS，latency等指標(biāo)的二次聚合計(jì)算。

診斷分析層，按照規(guī)則判斷某類指標(biāo)是否有異常。這里最核心的是診斷規(guī)則，結(jié)合積累經(jīng)驗(yàn)和集群數(shù)據(jù)利用Hawkeye平臺(tái)逐項(xiàng)檢測(cè)集群狀況，發(fā)現(xiàn)異常點(diǎn)并給出解決方案。按照數(shù)據(jù)和Action（解決方案），在大類上分為5類：

• 容量管理，這里的容量管理包括磁盤，內(nèi)存，CPU，網(wǎng)絡(luò)等幾乎所有與硬件資源相關(guān)的診斷；
• 集群配置管理，細(xì)分為全局配置（clusterSettings，集群拓?fù)涞?#xff09;和節(jié)點(diǎn)配置（與yml相關(guān)的全部）；
• 索引管理，索引的mapping，settings（包括索引切分，冷熱索引，無效字段）等一切與索引操作相關(guān)的診斷
• 查詢優(yōu)化，~
• 版本管理，ES的版本迭代很快，每個(gè)版本都會(huì)解決老的bug并引入新的特性，一些特定問題可以通過版本升級(jí)解決，比如6.x版本failover的效率提升。

診斷層，診斷層面向用戶問題，如果說診斷分析層是醫(yī)院的科室，那么診斷層就是導(dǎo)診臺(tái)，根據(jù)病情提供科室建議，即管理用戶問題和診斷分析之間的映射。

接入層，提供EYou診斷結(jié)果，目前可通過web控制臺(tái)和釘釘機(jī)器人接入，并且提供了API供其他系統(tǒng)調(diào)用。

??上述架構(gòu)是經(jīng)過數(shù)次演進(jìn)而來的，可以看到將診斷分析和實(shí)際問題區(qū)分開，使得它們各自都可以更方便的擴(kuò)展。而面向問題出發(fā)對(duì)用戶而言也會(huì)更加直接友好，也便于我們形成效果反饋的閉環(huán)驅(qū)動(dòng)EYou的優(yōu)化。

診斷分析

??EYou的核心是診斷分析模塊，而診斷分析則是以“診斷項(xiàng)”為核心來幫助用戶運(yùn)維其集群。診斷項(xiàng)由數(shù)據(jù)輸入和診斷規(guī)則組成，是可以直接反饋ES集群某一個(gè)狀態(tài)或行為是否合理的指標(biāo)。通過收集云上用戶的問題，尋找普遍存在或影響最大的問題，重點(diǎn)解決。不停的更新迭代逐步完善EYou的診斷范圍和問題，豐富其診斷項(xiàng)。目前，EYou已經(jīng)覆蓋到集群、節(jié)點(diǎn)、索引三個(gè)維度超過20個(gè)診斷項(xiàng)，可幫助用戶發(fā)現(xiàn)集群異常、資源以及使用規(guī)范、日常運(yùn)維等多個(gè)方面的問題。

??每一個(gè)診斷項(xiàng)都有其特定的邏輯策略，這里以集群顏色異常診斷，shard合理性診斷，存儲(chǔ)資源診斷這3個(gè)出現(xiàn)頻率較高的診斷項(xiàng)為例介紹一下。
1. 集群顏色異常診斷
ES會(huì)通過紅黃綠3種顏色來表示其數(shù)據(jù)分片是否丟失。ES內(nèi)部的decider模塊決定了數(shù)據(jù)分片是否可以被加載到某個(gè)節(jié)點(diǎn)上，共包含如下所示的14種decider。顏色診斷就是通過decider的結(jié)果來找到異常原因和解決方案。EYou通過ES提供的 _cluster/allocation/explain API 獲得類似于下面的decider信息。

// decider awareness cluster_rebalance concurrent_rebalance disk_threshold enable filter max_retry node_version rebalance_only_when_active replica_after_primary_active same_shard shards_limit snapshot_in_progress throttling // 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%])"}]},{...}] }

??比如當(dāng)decider觸發(fā)disk_threshold時(shí)，診斷策略將會(huì)分析用戶的磁盤容量和實(shí)際數(shù)據(jù)量，計(jì)算出合適的磁盤容量；當(dāng)觸發(fā)enable，shards_limt等配置相關(guān)的decider時(shí)，將會(huì)檢查集群配置，并給出正常的配置方式。通過這種方式用戶可以更直觀的了解到集群異常原因，也可以輕松的找到解決方案。

2. shard合理性診斷
計(jì)算索引shard的個(gè)數(shù)是創(chuàng)建索引時(shí)最重要的一個(gè)環(huán)節(jié)，shard的合理性不僅僅會(huì)影響索引讀寫的性能，還可能會(huì)對(duì)系統(tǒng)負(fù)載造成較大的影響。然而很多用戶在創(chuàng)建索引會(huì)直接選擇ES的默認(rèn)配置，這種方式固然簡(jiǎn)單，但默認(rèn)的設(shè)置并不適合每一個(gè)集群和業(yè)務(wù)，不合理的shard將大大增加集群隱患。比如以下3種常見的case：

• 一個(gè)4節(jié)點(diǎn)的集群，ES默認(rèn)的5個(gè)shard勢(shì)必會(huì)導(dǎo)致其中一個(gè)節(jié)點(diǎn)會(huì)比其它3個(gè)節(jié)點(diǎn)多出一倍的數(shù)據(jù)量和訪問流量，當(dāng)請(qǐng)求增加時(shí)，該集群會(huì)大概率出現(xiàn)單點(diǎn)瓶頸。
• 一個(gè)1TB大小的索引，分配了5個(gè)shard，單shard數(shù)據(jù)達(dá)到200G，這絕對(duì)會(huì)大大降低讀寫性能，并且在集群管理上會(huì)更加麻煩，比如后續(xù)可能無法通過添加節(jié)點(diǎn)的方式來提高性能。
• 一個(gè)1GB大小的索引，分配了5個(gè)shard，這在一定程度上就是資源浪費(fèi)，會(huì)增加ES對(duì)meta信息的維護(hù)，monitor的監(jiān)控讀寫的成本。

??shard合理性診斷就是為了解決上述這些問題。它會(huì)從索引的shard個(gè)數(shù)和節(jié)點(diǎn)的shard平衡兩個(gè)方面去診斷。
在索引層面，會(huì)去診斷單個(gè)索引的shard個(gè)數(shù)和大小是否合理。為了簡(jiǎn)化模型，它遵循一個(gè)原則，數(shù)據(jù)量才能真正決定shard個(gè)數(shù)的合理范圍，而節(jié)點(diǎn)資源僅僅是對(duì)結(jié)果進(jìn)行微調(diào)。根據(jù)索引的數(shù)據(jù)大小，EYou將索引分為小索引，中索引，大索引，超大索引4類，每一個(gè)分類的索引都設(shè)置了單shard大小的上下限和少量的溢出閾值。在計(jì)算出合理shard的區(qū)間后，首先會(huì)判斷索引當(dāng)前shard個(gè)數(shù)是否需要調(diào)整，然后會(huì)根據(jù)當(dāng)前集群的節(jié)點(diǎn)資源（規(guī)格，節(jié)點(diǎn)數(shù)）來縮小選擇區(qū)間，盡可能去匹配節(jié)點(diǎn)數(shù)并減少成本和資源的浪費(fèi)。同時(shí)EYou會(huì)根據(jù)日常支持的客戶情況，不停的改進(jìn)上述模型，調(diào)整其閾值和策略。
在節(jié)點(diǎn)層面，會(huì)去診斷節(jié)點(diǎn)間的數(shù)據(jù)負(fù)載是否一致。ES自身的平衡策略主要從磁盤空間，主副shard分布，全局shard個(gè)數(shù)，分配意識(shí)等維度去決定shard的分布，這個(gè)策略在大部分情況已經(jīng)可以做到很好了。但是它并沒有意識(shí)到不同索引不同shard的實(shí)際請(qǐng)求流量和計(jì)算資源的消耗是不同的，那么勢(shì)必會(huì)出現(xiàn)節(jié)點(diǎn)間負(fù)載不同的情況，尤其是索引較多的集群中。當(dāng)數(shù)據(jù)節(jié)點(diǎn)負(fù)載偏差較大時(shí)，一方面會(huì)影響到集群的穩(wěn)定性，另一方面會(huì)極大的浪費(fèi)集群資源。EYou在發(fā)現(xiàn)集群數(shù)據(jù)節(jié)點(diǎn)負(fù)載偏差較大時(shí)，會(huì)通過索引QPS、query/fetch/index/refresh/flush等指標(biāo)計(jì)算出資源消耗最大和最小的shard，然后使用ES 的_cluster/reroute 去調(diào)整shard分布。當(dāng)然這里后續(xù)可以繼續(xù)改進(jìn)的是從全局層面上使用ES平衡策略來改造裝箱算法，從而在整個(gè)集群層面更大范圍和精細(xì)的調(diào)整優(yōu)化。

3. 存儲(chǔ)資源診斷
存儲(chǔ)資源是否充足是影響ES集群的重要因素之一。由于ES的自動(dòng)平衡策略，各個(gè)節(jié)點(diǎn)上的數(shù)據(jù)分布大體是均勻的，這意味著當(dāng)一個(gè)節(jié)點(diǎn)空間不足時(shí)很難有其它空閑節(jié)點(diǎn)供其選擇。所以提前發(fā)現(xiàn)容量問題及時(shí)擴(kuò)容是可以大大降低分片丟失風(fēng)險(xiǎn)的。
EYou會(huì)根據(jù)當(dāng)前集群中索引的主shard大小，并利用容量管理模型計(jì)算出集群安全的磁盤容量。容量管理模型是通過對(duì)線上集群的統(tǒng)計(jì)分析以及實(shí)際經(jīng)驗(yàn)構(gòu)建的，在后面EYou會(huì)引入索引的分詞方式，編碼壓縮方式，mapping設(shè)置等因子進(jìn)行更精確的計(jì)算。
事實(shí)上擴(kuò)磁盤時(shí)可以選擇加節(jié)點(diǎn)，也可以在單節(jié)點(diǎn)上擴(kuò)容，那么如何抉擇成為了需要考慮的事情。EYou會(huì)通過對(duì)集群規(guī)格，使用場(chǎng)景，集群負(fù)載，磁盤大小等指標(biāo)的計(jì)算，給出最終擴(kuò)容建議，包括單節(jié)點(diǎn)擴(kuò)容，增加新節(jié)點(diǎn)，同時(shí)增加節(jié)點(diǎn)和單節(jié)點(diǎn)容量等3種方案。在上面的一些計(jì)算環(huán)節(jié)，EYou會(huì)簡(jiǎn)化某些因素，這樣在大大降低我們的決策和計(jì)算成本的同時(shí)也可以保證至少會(huì)得到一個(gè)次優(yōu)結(jié)果。

??其實(shí)可以看到，不同的診斷項(xiàng)之間是存在一定的關(guān)聯(lián)性的，比如集群顏色診斷是可以和存儲(chǔ)資源診斷建立聯(lián)系的。最初我們也嘗試去尋找一種辦法去建立診斷項(xiàng)之間的DAG，但事實(shí)上這張圖會(huì)很復(fù)雜，畢竟任何一個(gè)系統(tǒng)內(nèi)部的指標(biāo)，配置等都不是孤立的。所以后面我們改變了思路，診斷項(xiàng)之間相互獨(dú)立，并不試圖去作為其它項(xiàng)的輸入因子，而是在最上層通過具體的問題去建立關(guān)系，這也是我們后面設(shè)計(jì)調(diào)整的主要思想之一。

實(shí)際案例

??目前EYou已經(jīng)提供給技術(shù)支持和值班同學(xué)使用，并即將產(chǎn)品化提供給更多的用戶使用。它通過報(bào)告的方式將結(jié)果告知用戶，可以通過控制臺(tái)和釘釘機(jī)器人接入。

??上述報(bào)告截圖是一個(gè)實(shí)際的值班問題。用戶集群異常變成紅色，那么通過EYou值班同學(xué)可以很直接的看到，是因?yàn)榇疟P容量不足導(dǎo)致了數(shù)據(jù)分片丟失，并且建議用戶增加集群的磁盤總?cè)萘康?000G，具體的擴(kuò)容策略是增加數(shù)據(jù)節(jié)點(diǎn)到5個(gè)，并且單機(jī)擴(kuò)容到1.8T。下面的這組截圖是在用戶的集群負(fù)載較高時(shí)EYou得出的結(jié)論，發(fā)現(xiàn)了其頻繁變更狀態(tài)，shard不合理，負(fù)載不均衡等問題，并分別給出了修改建議。

總結(jié)&展望

??EYou目前已經(jīng)解決了用戶的一部分問題，尤其是在容量管理方面取得了一個(gè)不錯(cuò)的開端。但可以看到對(duì)于整個(gè)ES運(yùn)維來說也只是剛剛起步，在未來有更多的事情要做。ES作為一個(gè)分布式的搜索系統(tǒng)，從硬件（磁盤性能，網(wǎng)絡(luò)開銷，計(jì)算資源）到軟件（搜索引擎），從架構(gòu)（分布式系統(tǒng)）到使用方式（參數(shù)調(diào)優(yōu)）等很多方面都會(huì)影響到其使用，而持續(xù)不斷的探索優(yōu)化ES集群，幫助用戶更高效的解決問題正是EYou的本能。在未來我們將會(huì)做以下方面的嘗試：

• 首先我們會(huì)持續(xù)優(yōu)化每一個(gè)診斷策略，使結(jié)果更精確，引入更多的輸入因子，做到集群的“千人千面”。
• 其次我們會(huì)重點(diǎn)解決查詢優(yōu)化這類問題，這是我們目前在支持大客戶時(shí)投入較多精力也是比較棘手的問題。
• 然后我們希望可以將診斷結(jié)果賦能給其它更多的系統(tǒng)和場(chǎng)景，比如集群調(diào)度和生命周期的管理。
• 最后一點(diǎn)也是我們正在規(guī)劃中的事情，除了從內(nèi)部技術(shù)支持同學(xué)獲取EYou的使用反饋外，還要從用戶側(cè)直接得到效果評(píng)測(cè)數(shù)據(jù)。一個(gè)系統(tǒng)的，閉環(huán)的效果反饋機(jī)制可以幫助我們查漏補(bǔ)缺和持續(xù)優(yōu)化演進(jìn)EYou自身
  
  

申請(qǐng)EYOU試用：https://survey.aliyun.com/apps/zhiliao/FBEa5yTy4

阿里云Elasticsearch技術(shù)釘釘交流群

2017年9月，阿里云基于開源Elasticsearch及商業(yè)版X-Pack插件，提供云上ELK服務(wù)，同時(shí)阿里云ES技術(shù)人員會(huì)分享解決云上業(yè)務(wù)痛點(diǎn)的案例實(shí)踐，敬請(qǐng)期待！了解產(chǎn)品更多詳情 https://data.aliyun.com/product/elasticsearch

阿里云Elasticsearch?1核2G首月免費(fèi)試用，開始云上實(shí)踐吧

總結(jié)

以上是生活随笔為你收集整理的阿里云Elasticsearch 智能化运维实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。