Elasticsearch 的核心職能就是對外提供搜索服務，所以搜索請求的吞吐和延遲是非常關鍵的，搜索是靠底層的索引實現(xiàn)的，所以索引的性能指標也非常關鍵，Elasticsearch 由一個或多個節(jié)點組成集群，集群自身是否健康也是需要我們監(jiān)控的。
lasticSearch 的架構非常簡單，一個節(jié)點就可以對外提供服務，不過單點的集群顯然有容災問題，如果掛掉了就萬事皆休了。一般生產(chǎn)環(huán)境，至少搭建一個三節(jié)點的集群。
?三個節(jié)點分別部署三個 Elasticsearch 進程，這三個進程把 cluster.name 都設置成相同的值，就可以組成一個集群。Elasticsearch 會自動選出一個 master 節(jié)點，負責管理集群范圍內(nèi)所有的變更，整個選主過程是自動的，不用我們操心。
架構圖里綠色的 P0、P1、P2 表示三個分片，R0、R1、R2 代表分片副本，每個分片有兩個副本，也就是說 P0 對應兩個 R0，P1 對應兩個 R1，P2 對應兩個 R2。這些分片和副本是否成功分配到 Node 上并落盤寫入，也是一個重要的監(jiān)控指標。
索引部分是最關鍵的：
- docs 統(tǒng)計了文檔的數(shù)量，包括還沒有從段（segments）里清除的已刪除文檔數(shù)量。
- shard_stats 統(tǒng)計了分片的數(shù)量。
- store 統(tǒng)計了存儲的情況，包括主分片和副本分片總共耗費了多少物理存儲。
- indexing 是統(tǒng)計索引過程，ES 的架構里，索引是非常關鍵的一個東西，索引的吞吐和耗時都應該密切關注，index_total 和 index_time_in_millis 都是 Counter 類型的指標，單調(diào)遞增。如果要求取最近一分鐘的索引數(shù)量和平均延遲，就需要使用 increase 函數(shù)求增量。
- search 描述在活躍中的搜索（open_contexts）數(shù)量、查詢的總數(shù)量，以及自節(jié)點啟動以來在查詢上消耗的總時間。
- fetch 統(tǒng)計值展示了查詢處理的后一半流程，也就是 query-then-fetch 里的 fetch 部分。如果 fetch 耗時比 query 還多，說明磁盤較慢，可能是獲取了太多文檔，或者搜索請求設置了太大的分頁。
- merges 包括了 Lucene 段合并相關的信息。它會告訴你目前在運行幾個合并，合并涉及的文檔數(shù)量，正在合并的段的總大小，以及在合并操作上消耗的總時間。合并要消耗大量的磁盤 I/O 和 CPU 資源，如果 merge 操作耗費太多資源，也會被限制，即 total_throttled_time_in_millis 指標。
Elasticsearch 暴露指標的方式非常簡單，就是幾個 HTTP 接口，返回 JSON 數(shù)據(jù)，直接拉取解析即可，比 JMX 方式簡單得多。我們要關注的核心是 /_cluster/health 和 /_nodes/stats 這兩個接口，一個用來獲取整個集群的監(jiān)控數(shù)據(jù)，一個用來獲取節(jié)點粒度的監(jiān)控數(shù)據(jù)。 /_nodes/stats 接口返回的數(shù)據(jù)非常豐富，不但有索引類指標，還有 OS、JVM、Process、ThreadPool 指標，重點關注索引相關的指標和 JVM 相關的指標。
?文章來源：http://www.zghlxwxcb.cn/news/detail-636574.html
此文章為8月Day9學習筆記，內(nèi)容來源于極客時間《運維監(jiān)控系統(tǒng)實戰(zhàn)筆記》，推薦該課程。文章來源地址http://www.zghlxwxcb.cn/news/detail-636574.html
到了這里，關于監(jiān)控Elasticsearch的關鍵指標的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
