1、叢集健康次元：分片和節點
叢集、索引、分片、副本的定義不再贅述。分片數的多少對叢集性能的影響至關重要。分片數量設定過多或過低都會引發一些問題。
分片數量過多，則批量寫入/查詢請求被分割為過多的子寫入/查詢，導緻該索引的寫入、查詢拒絕率上升；
對于資料量較大的索引，當分片數量過小時，無法充分利用節點資源，造成機器資源使用率不高或不均衡，影響寫入/查詢的效率。
通過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
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
叢集運作的重要名額：
Status：狀态群集的狀态。紅色：部分主分片未配置設定。黃色：部分副本分片未配置設定。綠色：所有分片配置設定ok。
Nodes：節點。包括群集中的節點總數，并包括成功和失敗節點的計數。 Count of Active
Shards：活動分片計數。叢集中活動分片的數量。 Relocating Shards：重定位分片。由于節點丢失而移動的分片計數。
Initializing Shards：初始化分片。由于添加索引而初始化的分片計數。 Unassigned
Shards。未配置設定的分片。尚未建立或配置設定副本的分片計數。
2、搜尋性能次元：請求率和延遲
我們可以通過測量系統處理請求的速率和每個請求的使用時間來衡量叢集的有效性。
當叢集收到請求時，可能需要跨多個節點通路多個分片中的資料。系統處理和傳回請求的速率、目前正在進行的請求數以及請求的持續時間等核心名額是衡量叢集健康重要因素。
請求過程本身分為兩個階段：
第一是查詢階段（query phase），叢集将請求分發到索引中的每個分片（主分片或副本分片）。
第二個是擷取階段（fetch phrase），查詢結果被收集，處理并傳回給使用者。
通過GET index_a/_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：查詢總耗時。所有查詢消耗的總時間（以毫秒為機關）。
fetch_total：提取總數。叢集處理的所有fetch的聚合數。
fetch_time_in_millis：fetch所花費的總時間。所有fetch消耗的總時間（以毫秒為機關）。
3、索引性能次元：重新整理(refresh)和合并(Merge)時間
文檔的增、删、改操作，叢集需要不斷更新其索引，然後在所有節點上重新整理它們。所有這些都由叢集負責，作為使用者，除了配置 refresh interval 之外，我們對此過程的控制有限。
增、删、改批處理操作，會形成新段（segment）并重新整理到磁盤，并且由于每個段消耗資源，是以将較小的段合并為更大的段對于性能非常重要。同上類似，這由叢集本身管理。
監視文檔的索引速率（ indexing rate ）和合并時間（merge time）有助于在開始影響叢集性能之前提前識别異常和相關問題。将這些名額與每個節點的運作狀況并行考慮，這些名額為系統内的潛問題提供重要線索，為性能優化提供重要參考。
可以通過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
19
20
21
22
索引性能次元相關重要名額：
refresh.total：總重新整理計數。重新整理總數的計數。
refresh.total_time_in_millis：重新整理總時間。彙總所有花在重新整理的時間（以毫秒為機關進行測量）。
merges.current_docs：目前的合并。合并目前正在進行中。
merges.total_docs：合并總數。合并總數的計數。
merges.total_stopped_time_in_millis。合并花費的總時間。合并段的所有時間的聚合。
4、節點運作狀況次元：記憶體，磁盤和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
id disk.total disk.used disk.avail disk.used_percent ram.current ram.percent ram.max cpu
Hk9w 931.3gb 472.5gb 458.8gb 50.73 6.1gb 78 7.8gb 14
節點運作的重要名額：
disk.total ：總磁盤容量。節點主機上的總磁盤容量。
disk.used：總磁盤使用量。節點主機上的磁盤使用總量。
avail disk：可用磁盤空間總量。
disk.avail disk.used_percent：使用的磁盤百分比。已使用的磁盤百分比。
ram：目前的RAM使用情況。目前記憶體使用量（測量機關）。
percent ram：RAM百分比。正在使用的記憶體百分比。
max : 最大RAM。 節點主機上的記憶體總量
cpu：中央處理器。正在使用的CPU百分比。
實際業務場景中推薦使用：Elastic-HQ， cerebro監控。
5、JVM運作狀況次元：堆，GC和池大小（Pool Size）
作為基于Java的應用程式，Elasticsearch在Java虛拟機（JVM）中運作。JVM在其“堆”配置設定中管理其記憶體，并通過garbage collection進行垃圾回收處理。
如果應用程式的需求超過堆的容量，則應用程式開始強制使用連接配接的存儲媒體上的交換空間。雖然這可以防止系統崩潰，但它可能會對叢集的性能造成嚴重破壞。監視可用堆空間以確定系統具有足夠的容量對于叢集的健康至關重要。
JVM記憶體配置設定給不同的記憶體池。您需要密切注意這些池中的每個池，以確定它們得到充分利用并且沒有被超限利用的風險。
垃圾收集器（GC）很像實體垃圾收集服務。我們希望讓它定期運作，并確定系統不會讓它過載。理想情況下，GC性能視圖應類似均衡波浪線大小的正常執行。尖峰和異常可以成為更深層次問題的名額。
可以通過GET /_nodes/stats 指令檢索JVM度量标準。
"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" : {
"collection_count" : 260,
"collection_time_in_millis" : 3463
"collection_count" : 2,
"collection_time_in_millis" : 125
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
JVM運作的重要名額如下：
mem：記憶體使用情況。堆和非堆程序和池的使用情況統計資訊。
threads：目前使用的線程和最大數量。
gc：垃圾收集。算和垃圾收集所花費的總時間。
6、ElasticsearchTop10監控名額
經過上面的分析，Top10監控名額如下。使用英文是為了和咱們的指令行傳回一緻，更好了解。
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叢集時，很難對每個關注領域做出公正的判斷。不同名額之間的緊密耦合以及了解配置變化如何影響每個名額需要一支經驗豐富且訓練有素的工程師團隊。
對于将Elasticsearch作為解決方案的任何公司而言，投資全面的監控政策至關重要。有效的監控可以節省公司因非響應或無法修複的叢集問題而導緻的停機時間成本和經濟成本。
7、小結
這篇文章翻譯自：
https://sematext.com/blog/top-10-elasticsearch-metrics-to-watch/。
本文删除了原作者的自己公司軟體的推銷截圖，所有的指令都是kibana實踐過的，部分語言描述加上了自己的實踐了解以確定流暢。
和之前的博文強調的一樣：“全局思維”的重要性。顯然此篇是監控名額的全局思維。五個思維次元+10個名額次元剖析了Elasticsearch最常見的監控名額，在大規模叢集實踐中都會用的到。
性能問題一般到産品實踐的中後期會叫苦連連，提前最好監控，防患于未然不止是運維也是研發必備的技能。
推薦閱讀：
嚴選 | Elasticsearch史上最全最常用工具清單