監控，是服務可用性保障的關鍵之一。本文從運維角度，對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黑盒監控和白盒監控進行分類：

 

黑盒監控

 

• 叢集功能

索引建立、刪除、文件寫入、查詢等基本功能。實際監控中，建立索引時，需要控制好頻率以及分片的分配情況。實戰中，由於索引建立頻率較高，並且分片數量設定不合理，導致叢集pending任務堆積，導致正常業務建立索引出現大量延遲或失敗。

 

• 叢集整體狀態

理論上，叢集正常狀態為green，出現red時，叢集肯定存在部分索引主備分片全部丟失情況。叢集狀態為yellow時，也不能完全代表叢集沒有問題。比如，建立索引時，如果分片沒有完全分配完成，也會出現yellow狀態。因此，叢集出現yellow時，也需要重點關注或排查叢集可能存在的問題。

 

• 活躍分片數百分比

 

• Pending任務數

Pending任務數99%時間均為0，如果出現長時間為非0情況，叢集肯定出現了異常。

 

白盒監控

 

容量

作為儲存元件，對於儲存容量的監控至關重要。

 

• 總儲存空間

ES本身沒有提供此方面監控資料，需要自行進行計算。

 

• 已用儲存空間

總儲存空間是不能全部使用完，需要預留一部分空間。

 

• 最大分割槽使用

在ES中，如果某資料節點單塊資料目錄使用率超過90%（預設值，可以通過cluster.routing.allocation.disk.watermark相關配置來調整），則會進行分片資料遷移。因此，在資料盤存在異構的叢集中，為避免分片遷移，監控此值，至關重要。

 

• 機器（或例項）資源（CPU、Load、Disk、JVM）

 

• 分片數量

最好不超過一萬個分片。官方推薦，單個例項JVM記憶體不超過30GB，不超過600個分片。另外，分片是由Master來維護其狀態的，而Master在任何叢集規模下，有且僅有一個節點在工作，其餘均為候選主節點，因此分片數量越高，Master常態的壓力越大，故障後恢復的耗時也越長。合理的分片數量與叢集節點數、寫入資料量、磁碟讀寫效能等存在一定關係，具體可以參考官方說明。

 

• 執行緒池佇列長度

 

流量

 

• 索引、搜尋速率

需要監控總量，但是需要採集主要index的資料，便於問題定位。例如哪個索引突增流量將叢集壓垮了？如果沒有細化的index的相關資料採集，就只能通過index的體積來進行間接判斷，延時也類似。

 

• 叢集網路IO

 

• 叢集資料節點IO

實際部署中，會區分攝取（ingest）、主（master）、資料（data）等節點，這裡重點監控資料節點IO。

 

延遲

 

• 索引、搜尋延遲

   

• 慢查詢

 

錯誤

 

• 叢集異常節點數

   

• 索引、搜尋拒絕數量

   

• 主節點錯誤日誌

 

藉助監控發現的問題

 

場景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