導語
Elasticsearch（文中簡稱 ES）是分佈式全文搜索引擎，產品提供高可用、易擴展以及近實時的搜索能力，廣泛應用於數據存儲、搜索和實時分析。很多服務的可用性對 ES 重度依賴。因此，保障 ES 自身可用性，是實現服務高可用的重中之重。
基於京東雲豐富的運維實戰經驗，接下來我們將陸續推出 ES 運維乾貨，歡迎小夥伴們持續關注。今天帶來第一篇內容——Elasticsearch監控實戰。
↓↓↓
監控，是服務可用性保障的關鍵之一。本文從運維角度，對 ES 服務監控進行了系統性總結，涵蓋監控工具選型、監控採集項篩選介紹，最後列舉了幾個藉助監控發現的ES線上問題。
ES監控概覽
針對 ES 進行監控，主要期望解決這幾種場景：
- ES 日常服務巡檢，幫助運維開發人員及時發現隱患
- ES 服務異常後，幫助運維開發人員及時發現故障
- 採集的 ES 監控指標，幫助運維開發人員迅速定位問題根因
能夠及時發現ES服務異常，這是最主要目標。
監控工具選型
藉助運維工具，在 ES 實際運維工作中能極大提升運維開發人員的工作效率。目前 ES 可用的監控工具或插件很多，對多種監控工具進行評測分析後，我們最終的監控工具選型爲：
- X-Pack+kibana
索引信息、集羣整體信息很有幫助，尤其是各索引的索引、搜索速率，索引延遲數據等。其中，X-Pack 是官方給出的插件（Monitoring 爲開放特性），需要注意的是，ES 集羣上線前就需要安裝 X-Pack 插件。圖一展現了在 Kibana 中，Monitoring 的部分功能。
圖一 Monitoring部分功能
- Jmxtrans-ES+influxdb
主要進行核心數據採集、監控。ES 本身提供的 jmx 信息有限，這裏使用了Jmxtrans-ES（自研）工具，通過 http 接口獲取信息後，寫入到 influxdb。ES 與 influxdb 的結合，官方給出的方案是讀取 X-Pack 中的索引信息，考慮到 X-pack 索引是存儲在 ES，保留時間有限，以及與京東雲內部監控系統的對接，我們自研了 Jmxtrans-ES 工具進行核心信息採集，也自研了 ES-Monitor功能監控工具，儀表盤通過 Grafana 進行展現。圖二展現了 ES 集羣部分核心數據。
圖二 ES集羣部分核心數據
- Elasticsearch-HQ
這款工具屬於清新風格。之前使用的 head 插件，在集羣規模達到一定程度後，head 插件信息展現不理想，因此使用了 HQ 代替 head 部分功能。如果很難記住管理 API，可以藉助 ES-command 工具。圖三展現了 ElasticHQ 管理界面。
圖三 ElasticHQ管理界面
告警對接京東雲內部告警平臺。
採集項篩選
實戰中，ES 集羣部署使用 5.x 版本，區分協調（coordinating）、攝取（ingest）、主（master）、數據（data）等節點，獨立部署，數據節點機器異構。
按照 SRE 黑盒監控和白盒監控進行分類：
1、黑盒監控
- 集羣功能
索引創建、刪除、文檔寫入、查詢等基本功能。實際監控中，創建索引時，需要控制好頻率以及分片的分配情況。實戰中，由於索引創建頻率較高，並且分片數量設置不合理，導致集羣 pending 任務堆積，導致正常業務創建索引出現大量延遲或失敗。
- 集羣整體狀態
理論上，集羣正常狀態爲 green，出現 red 時，集羣肯定存在部分索引主備分片全部丟失情況。集羣狀態爲 yellow 時，也不能完全代表集羣沒有問題。比如，創建索引時，如果分片沒有完全分配完成，也會出現 yellow 狀態。因此，集羣出現 yellow 時，也需要重點關注或排查集羣可能存在的問題。
- 活躍分片數百分比
- Pending任務數
Pending任務數99%時間均爲0，如果出現長時間爲非0情況，集羣肯定出現了異常。
2、白盒監控
1）容量
作爲存儲組件，對於存儲容量的監控至關重要。
- 總存儲空間：ES 本身沒有提供此方面監控數據，需要自行進行計算。
- 已用存儲空間：總存儲空間是不能全部使用完，需要預留一部分空間。
- 最大分區使用：在 ES 中，如果某數據節點單塊數據目錄使用率超過90%（默認值，可以通過 cluster.routing.allocation.disk.watermark 相關配置來調整），則會進行分片數據遷移。因此，在數據盤存在異構的集羣中，爲避免分片遷移，監控此值，至關重要。
- 機器（或實例）資源（CPU、Load、Disk、JVM）
- 分片數量：最好不超過一萬個分片。官方推薦，單個實例 JVM 內存不超過30GB，不超過600個分片。另外，分片是由 Master 來維護其狀態的，而 Master 在任何集羣規模下，有且僅有一個節點在工作，其餘均爲候選主節點，因此分片數量越高，Master 常態的壓力越大，故障後恢復的耗時也越長。合理的分片數量與集羣節點數、寫入數據量、磁盤讀寫性能等存在一定關係，具體可以參考官方說明。
- 線程池隊列長度
2）流量
- 索引、搜索速率：需要監控總量，但是需要採集主要 index 的數據，便於問題定位。例如哪個索引突增流量將集羣壓垮了？如果沒有細化的 index 的相關數據採集，就只能通過 index 的體積來進行間接判斷，延時也類似。
- 集羣網絡IO
- 集羣數據節點IO：實際部署中，會區分攝取（ingest）、主（master）、數據（data）等節點，這裏重點監控數據節點IO。
3）延遲
- 索引、搜索延遲
- 慢查詢
4）錯誤
- 集羣異常節點數
- 索引、搜索拒絕數量
- 主節點錯誤日誌
藉助監控發現的問題
場景1：
如果 Elasticsearch 集羣出現問題，通過 ES 接口獲取到的監控數據可能出現響應超時，無法響應情況，造成監控工具不可用。
發現方式：功能監控響應超時告警
優化建議：1）避免該場景出現：需要在日常巡檢排查中，發現集羣隱患，優化集羣配置項，消除隱患；2）如果出現此問題：那麼針對各實例的存活性，錯誤日誌監控不可缺失，通過此監控信息快速定位。
場景2：
如果某數據節點任何一個數據目錄不可用（比如磁盤故障，其他應用佔滿數據目錄）則新建索引若有分片分配到上面之後，則會出現創建索引失敗。
發現方式：功能監控告警、pending 任務堆積告警
優化建議：爲避免此問題出現，數據盤可以做 raid5 或 raid10，避免多個服務共用同一數據目錄等。當然數據目錄的可用性，也需要有方法能夠知道。
場景3：
某索引因程序問題，出現大量創建 type，導致集羣異常。
發現方式：pending 任務堆積告警，之後排查各索引寫入速率，找到異常索引
優化建議：定期排查重點索引的數據寫入合理性，以及服務巡檢。
附：
涉及的部分開源軟件，Git地址
- ElasticHQ：https://github.com/ElasticHQ/elasticsearch-HQ
部分運維腳本，Git地址
- Elasticsearch Monitor：https://github.com/cloud-op/monitor
------------------END------------------