【最佳實踐】實踐總結阿里雲Elasticsearch 智能化運維思路

作者：
梵寞—阿里雲 Elasticsearch 團隊高級開發工程師

阿里雲 Elasticsearch 作為一個開箱即用的搜索引擎，其豐富的功能和極低的使用門檻吸引著越來越多的公司和用戶選擇它作為搜索和數據分析的工具。用戶在運維 Elasticsearch 集群時往往會遇到很多難題，具體來說有下面列舉的幾點：

使用方式往往比較粗糙，默認的設置並不適合每一個集群和業務，非精細化的設計將會極大的增加集群隱患；
集群出現問題，無法及時定位原因、尋找解決方案，低效的溝通或者解決問題的方式可能會使得問題變得愈發嚴重；
Elasticsearch 提供的監控指標繁雜，指標多，意義不明確，需要一定的專業知識才可以理解，缺乏全局視角；
此外，集群潛在的異常無法發現，更不能及時規避風險。

隨著越來越多的用戶選擇使用阿里雲 Elasticsearch 服務來支持搜索和分析業務，上述這些問題越發明顯，用戶和實例數量的快速增長，讓我們沒有太多的精力去逐一對接所有用戶的問題，這無形中大大降低了我們和用戶雙方的效率。

基於阿里雲 Elasticsearch 的智能運維繫統 EYou 正是為了解決上面問題才出現的，它用來幫助用戶自主診斷阿里雲 Elasticsearch 實例健康狀況，探測潛在風險並提供解決方案。本文將從產品設計思路、系統架構、核心痛點等剖析 Elasticsearch 智能化運維產品化的實踐經驗。

EYou

總體概述

首先以醫院作為類比可能會更容易理解 EYou 的設計思路。

當病人生病就醫時，會去醫院找到對應科室的醫生，醫生通過詢問，化驗等手段收集信息後然後根據自己的專業知識去診斷病因，並尋求治療方案。而當病情嚴重的時候則可能需要多個科室的醫生來綜合治療。而人們在日常並未感覺身體不適的時候，同樣可以去體檢中心體檢，以便及時發現可能存在的問題，通過保持良好的生活習慣來預防病情或者儘早治療以免病情嚴重。

EYou 的核心思想和上述就醫流程類似，通過專家經驗和集群數據的雙重驅動來診斷集群狀況，先收集數據（化驗，詢問）然後使用專業知識（經驗）來找到問題的原因或者提前發現問題（體檢），給出合理的解決方案。

希望成為最瞭解 Elasticsearch 集群的存在，可以在全局視角判斷集群的運行狀況，也可以在日常的時候引導用戶使用規範；可以在集群出現問題時查找原因，也可以發現集群的潛在風險。

系統架構

EYou 整體上分為5個部分：

1.數據採集，數據採集模塊是專門收集 EYou 系統所需要的各類信息。

目標 Elasticsearch 集群的基本配置信息，包括settings，mapping，status，shard，segment等等；
Shuttle，shuttle 是阿里雲ES集群的調度服務，EYou 在這裡獲得集群的資源和生命週期等信息；
Log，我們有一個專門用於收集ES各類日誌的logcenter，它可以提供集群的異常日誌，gc日誌等，另外 EYou 會使用 logcenter 做一部分的機器學習任務以及全局統計信息；
Metric，metric 包括機器指標（CPU使用率，load大小等）和ES服務指標（latency，QPS等）。

2.數據處理，數據處理模塊用於對採集到的數據加工整理。由於採集到的原始數據多且零散，所以很多無法被上層模塊直接使用，為了屏蔽數據的複雜性，數據處理模塊會對數據加工以提供更友好的數據。包括查詢語句的模板歸一，機器學習結果的輸出，QPS，latency等指標的二次聚合計算。

3.診斷分析層，按照規則判斷某類指標是否有異常。這裡最核心的是診斷規則，結合積累經驗和集群數據利用 Hawkeye 平臺逐項檢測集群狀況，發現異常點並給出解決方案。按照數據和 Action（解決方案），在大類上分為5類：

容量管理，這裡的容量管理包括磁盤，內存，CPU，網絡等幾乎所有與硬件資源相關的診斷；
集群配置管理，細分為全局配置（clusterSettings，集群拓撲等）和節點配置（與yml相關的全部）；
索引管理，索引的 mapping，settings（包括索引切分，冷熱索引，無效字段）等一切與索引操作相關的診斷；
查詢優化；
版本管理，Elasticsearch 的版本迭代很快，每個版本都會解決老的 bug 並引入新的特性，一些特定問題可以通過版本升級解決，比如 6.x 版本 failover 的效率提升。

4.診斷層，診斷層面向用戶問題，如果說診斷分析層是醫院的科室，那麼診斷層就是導診臺，根據病情提供科室建議，即管理用戶問題和診斷分析之間的映射。

5.接入層，提供 EYou 診斷結果，目前可通過 web 控制檯和釘釘機器人接入，並且提供了 API 供其他系統調用。

上述架構是經過數次演進而來的，可以看到將診斷分析和實際問題區分開，使得它們各自都可以更方便的擴展。而面向問題出發對用戶而言也會更加直接友好，也便於我們形成效果反饋的閉環驅動 EYou 的優化。

診斷分析

EYou的核心是診斷分析模塊，而診斷分析則是以“診斷項”為核心來幫助用戶運維其集群。診斷項由數據輸入和診斷規則組成，是可以直接反饋 Elasticsearch 集群某一個狀態或行為是否合理的指標。通過收集雲上用戶的問題，尋找普遍存在或影響最大的問題，重點解決。不停的更新迭代逐步完善 EYou 的診斷範圍和問題，豐富其診斷項。目前，EYou 已經覆蓋到集群、節點、索引三個維度超過20個診斷項，可幫助用戶發現集群異常、資源以及使用規範、日常運維等多個方面的問題。

每一個診斷項都有其特定的邏輯策略，這裡以集群顏色異常診斷，shard 合理性診斷，存儲資源診斷這3個出現頻率較高的診斷項為例介紹一下。

1. 集群顏色異常診斷

Elasticsearch 會通過紅黃綠3種顏色來表示其數據分片是否丟失。Elasticsearch 內部的 decider 模塊決定了數據分片是否可以被加載到某個節點上，共包含如下所示的14種 decider。顏色診斷就是通過 decider 的結果來找到異常原因和解決方案。EYou 通過 Elasticsearch 提供的 _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%])"
                }
            ]
        },
        {...}
    ]
}

比如當 decider 觸發 disk_threshold 時，診斷策略將會分析用戶的磁盤容量和實際數據量，計算出合適的磁盤容量；當觸發 enable，shards_limt 等配置相關的 decider 時，將會檢查集群配置，並給出正常的配置方式。通過這種方式用戶可以更直觀的瞭解到集群異常原因，也可以輕鬆的找到解決方案。

2. shard 合理性診斷

計算索引 shard 的個數是創建索引時最重要的一個環節，shard 的合理性不僅僅會影響索引讀寫的性能，還可能會對系統負載造成較大的影響。然而很多用戶在創建索引會直接選擇ES的默認配置，這種方式固然簡單，但默認的設置並不適合每一個集群和業務，不合理的 shard 將大大增加集群隱患。

比如以下3種常見的 case：

一個4節點的集群，Elasticsearch 默認的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 會根據日常支持的客戶情況，不停的改進上述模型，調整其閾值和策略。

在節點層面，會去診斷節點間的數據負載是否一致。Elasticsearch 自身的平衡策略主要從磁盤空間，主副 shard 分佈，全局 shard 個數，分配意識等維度去決定 shard 的分佈，這個策略在大部分情況已經可以做到很好了。但是它並沒有意識到不同索引不同shard的實際請求流量和計算資源的消耗是不同的，那麼勢必會出現節點間負載不同的情況，尤其是索引較多的集群中。當數據節點負載偏差較大時，一方面會影響到集群的穩定性，另一方面會極大的浪費集群資源。EYou 在發現集群數據節點負載偏差較大時，會通過索引 QPS、query/fetch/index/refresh/flush 等指標計算出資源消耗最大和最小的 shard，然後使用Elasticsearch 的_cluster/reroute 去調整 shard 分佈。當然這裡後續可以繼續改進的是從全局層面上使用 Elasticsearch 平衡策略來改造裝箱算法，從而在整個集群層面更大範圍和精細的調整優化。

3. 存儲資源診斷

存儲資源是否充足是影響 Elasticsearch 集群的重要因素之一。由於 Elasticsearch 的自動平衡策略，各個節點上的數據分佈大體是均勻的，這意味著當一個節點空間不足時很難有其它空閒節點供其選擇。所以提前發現容量問題及時擴容是可以大大降低分片丟失風險的。

EYou 會根據當前集群中索引的主 shard 大小，並利用容量管理模型計算出集群安全的磁盤容量。容量管理模型是通過對線上集群的統計分析以及實際經驗構建的，在後面 EYou 會引入索引的分詞方式，編碼壓縮方式，mapping 設置等因子進行更精確的計算。

事實上擴磁盤時可以選擇加節點，也可以在單節點上擴容，那麼如何抉擇成為了需要考慮的事情。EYou 會通過對集群規格，使用場景，集群負載，磁盤大小等指標的計算，給出最終擴容建議，包括單節點擴容，增加新節點，同時增加節點和單節點容量等3種方案。在上面的一些計算環節，EYou 會簡化某些因素，這樣在大大降低我們的決策和計算成本的同時也可以保證至少會得到一個次優結果。

其實可以看到，不同的診斷項之間是存在一定的關聯性的，比如集群顏色診斷是可以和存儲資源診斷建立聯繫的。最初我們也嘗試去尋找一種辦法去建立診斷項之間的 DAG，但事實上這張圖會很複雜，畢竟任何一個系統內部的指標，配置等都不是孤立的。所以後面我們改變了思路，診斷項之間相互獨立，並不試圖去作為其它項的輸入因子，而是在最上層通過具體的問題去建立關係，這也是我們後面設計調整的主要思想之一。

總結&展望

EYou 目前已經解決了用戶的一部分問題，尤其是在容量管理方面取得了一個不錯的開端。但可以看到對於整個 Elasticsearch 運維來說也只是剛剛起步，在未來有更多的事情要做。Elasticsearch 作為一個分佈式的搜索系統，從硬件（磁盤性能，網絡開銷，計算資源）到軟件（搜索引擎），從架構（分佈式系統）到使用方式（參數調優）等很多方面都會影響到其使用，而持續不斷的探索優化 Elasticsearch 集群，幫助用戶更高效的解決問題正是 EYou 的本能。