轉發自：https://blog.csdn.net/majianxiong_lzu/article/details/90437559
主要指標梳理
- Cluster Health – Nodes and Shards
- Search Performance – Request Latency and
- Search Performance – Request Rate
- Indexing Performance – Refresh Times
- Indexing Performance – Merge Times
- Node Health – Memory Usage
- Node Health – Disk I/O
- Node Health – CPU
- JVM Health – Heap Usage and Garbage Collection
- JVM health – JVM Pool Size
Elasticsearch具有通用性、可擴展性和實用性的特點，集群的基礎架構必須滿足如上特性。合理的集群架構能支撐其數據存儲及並發響應需求。相反，不合理的集群基礎架構和錯誤配置可能導致集群性能下降、集群無法響應甚至集群崩潰。監控系統的節點運行情況、集群健康、JVM性能狀況、索引性能、檢索性能等，實時發現問題，防患於未然。
監控工具
實際業務場景中，如果公司條件允許，X-pack是首選，具備數據安全和監控告警等功能，用的放心。
免費工具推薦使用：Elastic-HQ， cerebro監控。
1、節點運行狀況維度：內存，磁盤和CPU指標
每個節點都運行物理硬件上，需要訪問系統內存，磁盤存儲和CPU周期，以便管理其控制下的數據並響應對集群的請求。
Elasticsearch是一個嚴重依賴內存 以實現性能的系統，因此密切關注內存使用情況與每個節點的運行狀況和性能相關。改進指標的相關配置更改也可能會對內存分配和使用產生負面影響，因此記住從整體上查看系統運行狀況非常重要。
監視節點的CPU使用情況並查找峰值有助於識別節點中的低效進程或潛在問題。CPU性能與Java虛擬機（JVM）的垃圾收集過程密切相關。
磁盤高讀寫可能導致系統性能問題。由於訪問磁盤在時間上是一個“昂貴”的過程，因此應盡可能減少磁盤I/O。
通過如下命令行可以實現節點級別度量指標，並反映運行它的實例或計算機的性能。
GET _cat/nodes?v&h=id,disk.total,disk.used,disk.avail,disk.used_percent,ram.current,ram.percent,ram.max,cpu&format=json&pretty [ { "id" : "yrVc", "disk.avail" : "17.7gb", "ram.current" : "2.6gb", "ram.percent" : "56", "ram.max" : "4.6gb", "cpu" : "0" } ]注意：本文驗證時采用的版本為ES 5.4.0，有些指標與原文不同，根據不同版本返回結果會有變化。
節點運行的重要指標：
- disk.total ：總磁盤容量。節點主機上的總磁盤容量。
- disk.used：總磁盤使用量。節點主機上的磁盤使用總量。
- avail disk：可用磁盤空間總量。
- disk.avail disk.used_percent：使用的磁盤百分比。已使用的磁盤百分比。
- ram：當前的RAM使用情況。當前內存使用量（測量單位）。
- percent ram：RAM百分比。正在使用的內存百分比。
- max : 最大RAM。 節點主機上的內存總量
- cpu：中央處理器。正在使用的CPU百分比。
2、JVM運行狀況維度：堆，GC和池大小
作為基於Java的應用程序，Elasticsearch在Java虛擬機（JVM）中運行。JVM在其“堆”分配中管理其內存，並通過garbage collection進行垃圾回收處理。
如果應用程序的需求超過堆的容量，則應用程序開始強制使用連接的存儲介質上的交換空間。雖然這可以防止系統崩潰，但它可能會對集群的性能造成嚴重破壞。監視可用堆空間以確保系統具有足夠的容量對於集群的健康至關重要。
JVM內存分配給不同的內存池。您需要密切注意這些池中的每個池，以確保它們得到充分利用並且沒有被超限利用的風險。
垃圾收集器（GC）很像物理垃圾收集服務。我們希望讓它定期運行，並確保系統不會讓它過載。理想情況下，GC性能視圖應類似均衡波浪線大小的常規執行。尖峰和異常可以成為更深層次問題的指標。
可以通過GET /_nodes/stats 命令檢索JVM度量標准。
GET /_nodes/stats "jvm" : { "timestamp" : 1557588707194, "uptime_in_millis" : 22970151, "mem" : { "heap_used_in_bytes" : 843509048, "heap_used_percent" : 40, "heap_committed_in_bytes" : 2077753344, "heap_max_in_bytes" : 2077753344, "non_heap_used_in_bytes" : 156752056, "non_heap_committed_in_bytes" : 167890944, "pools" : { "young" : { "used_in_bytes" : 415298464, "max_in_bytes" : 558432256, "peak_used_in_bytes" : 558432256, "peak_max_in_bytes" : 558432256 }, "survivor" : { "used_in_bytes" : 12178632, "max_in_bytes" : 69730304, "peak_used_in_bytes" : 69730304, "peak_max_in_bytes" : 69730304 }, "old" : { "used_in_bytes" : 416031952, "max_in_bytes" : 1449590784, "peak_used_in_bytes" : 416031952, "peak_max_in_bytes" : 1449590784 } } }, "threads" : { "count" : 116, "peak_count" : 119 }, "gc" : { "collectors" : { "young" : { "collection_count" : 260, "collection_time_in_millis" : 3463 }, "old" : { "collection_count" : 2, "collection_time_in_millis" : 125 } } },JVM運行的重要指標如下：
- mem：內存使用情況。堆和非堆進程和池的使用情況統計信息。
- threads：當前使用的線程和最大數量。
- gc：垃圾收集。算和垃圾收集所花費的總時間。
3、集群健康維度：分片和節點
分片數的多少對集群性能的影響至關重要。分片數量設置過多或過低都會引發一些問題。
分片數量過多，則批量寫入/查詢請求被分割為過多的子寫入/查詢，導致該索引的寫入、查詢拒絕率上升；
對於數據量較大的索引，當分片數量過小時，無法充分利用節點資源，造成機器資源利用率不高或不均衡，影響寫入/查詢的效率。
通過GET _cluster/health監視群集時，可以查詢集群的狀態、節點數和活動分片計數的信息。還可以查看重新定位分片，初始化分片和未分配分片的計數。
GET _cluster/health { "cluster_name" : "elasticsearch", "status" : "yellow", "timed_out" : false, "number_of_nodes" : 1, "number_of_data_nodes" : 1, "active_primary_shards" : 127, "active_shards" : 127, "relocating_shards" : 0, "initializing_shards" : 0, "unassigned_shards" : 120, "delayed_unassigned_shards" : 0, "number_of_pending_tasks" : 0, "number_of_in_flight_fetch" : 0, "task_max_waiting_in_queue_millis" : 0, "active_shards_percent_as_number" : 51.417004048582996 }集群運行的重要指標：
- Status：狀態群集的狀態。紅色：部分主分片未分配。黃色：部分副本分片未分配。綠色：所有分片分配ok。
- Nodes：節點。包括群集中的節點總數，並包括成功和失敗節點的計數。 Count of Active
- Shards：活動分片計數。集群中活動分片的數量。 Relocating - Shards：重定位分片。由於節點丟失而移動的分片計數。
- Initializing Shards：初始化分片。由於添加索引而初始化的分片計數。 - Unassigned Shards。未分配的分片。尚未創建或分配副本的分片計數。
4、搜索性能維度：請求率和延遲
我們可以通過測量系統處理請求的速率和每個請求的使用時間來衡量集群的有效性。
當集群收到請求時，可能需要跨多個節點訪問多個分片中的數據。系統處理和返回請求的速率、當前正在進行的請求數以及請求的持續時間等核心指標是衡量集群健康重要因素。
請求過程本身分為兩個階段：
- 第一是查詢階段（query phase），集群將請求分發到索引中的每個分片（主分片或副本分片）。
- 第二個是獲取階段（fetch phrase），查詢結果被收集，處理並返回給用戶。
通過GET {index}/_stats查看對應目標索引狀態。
GET {index}/_stats "search" : { "open_contexts" : 0, "query_total" : 10, "query_time_in_millis" : 0, "query_current" : 0, "fetch_total" : 1, "fetch_time_in_millis" : 0, "fetch_current" : 0, "scroll_total" : 5, "scroll_time_in_millis" : 15850, "scroll_current" : 0, "suggest_total" : 0, "suggest_time_in_millis" : 0, "suggest_current" : 0 },請求檢索性能相關的重要指標如下：
- query_current：當前正在進行的查詢數。集群當前正在處理的查詢計數。
- fetch_current：當前正在進行的fetch次數。集群中正在進行的fetch計數。
- query_total：查詢總數。集群處理的所有查詢的聚合數。
- query_time_in_millis：查詢總耗時。所有查詢消耗的總時間（以毫秒為單位）。
f- etch_total：提取總數。集群處理的所有fetch的聚合數。
f- etch_time_in_millis：fetch所花費的總時間。所有fetch消耗的總時間（以毫秒為單位）。
5、索引性能維度：刷新(refresh)和合並(Merge)時間
文檔的增、刪、改操作，集群需要不斷更新其索引，然后在所有節點上刷新它們。所有這些都由集群負責，作為用戶，除了配置 refresh interval 之外，我們對此過程的控制有限。
增、刪、改批處理操作，會形成新段（segment）並刷新到磁盤，並且由於每個段消耗資源，因此將較小的段合並為更大的段對於性能非常重要。同上類似，這由集群本身管理。
監視文檔的索引速率（ indexing rate ）和合並時間（merge time）有助於在開始影響集群性能之前提前識別異常和相關問題。將這些指標與每個節點的運行狀況並行考慮，這些指標為系統內的潛問題提供重要線索，為性能優化提供重要參考。
可以通過GET /_nodes/stats 獲取索引性能指標，並可以在節點，索引或分片級別進行匯總。
GET /_nodes/stats "merges" : { "current" : 0, "current_docs" : 0, "current_size_in_bytes" : 0, "total" : 245, "total_time_in_millis" : 58332, "total_docs" : 1351279, "total_size_in_bytes" : 640703378, "total_stopped_time_in_millis" : 0, "total_throttled_time_in_millis" : 0, "total_auto_throttle_in_bytes" : 2663383040 }, "refresh" : { "total" : 2955, "total_time_in_millis" : 244217, "listeners" : 0 }, "flush" : { "total" : 127, "periodic" : 0, "total_time_in_millis" : 13137 },索引性能維度相關重要指標：
- refresh.total：總刷新計數。刷新總數的計數。
- refresh.total_time_in_millis：刷新總時間。匯總所有花在刷新的時間（以毫秒為單位進行測量）。
- merges.current_docs：目前的合並。合並目前正在處理中。
- merges.total_docs：合並總數。合並總數的計數。
- merges.total_stopped_time_in_millis。合並花費的總時間。合並段的所有時間的聚合。