0、監控Elasticsearch集羣的重要性

Elasticsearch具有通用性，可擴展性和實用性的特點，集羣的基礎架構必須滿足如上特性。合理的集羣架構能支撐其數據存儲及併發響應需求。相反，不合理的集羣基礎架構和錯誤配置可能導致集羣性能下降、集羣無法響應甚至集羣崩潰。

適當地監視羣集可以幫助您實時監控集羣規模，並且可以有效地處理所有數據請求。

本文我們將從五個不同的維度來看待集羣，並從這些維度中提煉出監控的關鍵指標，並探討通過觀察這些指標可以避免哪些潛在問題。

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
}

集羣運行的重要指標：

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
        },

索引性能維度相關重要指標：

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" : {
            "young" : {
              "collection_count" : 260,
              "collection_time_in_millis" : 3463
            },
            "old" : {
              "collection_count" : 2,
              "collection_time_in_millis" : 125
            }
          }
        },

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史上最全最常用工具清單

銘毅天下——Elasticsearch基礎、進階、實戰第一公衆號

乾貨 | Elasticsearch Top10 監控指標

0、監控Elasticsearch集羣的重要性

1、集羣健康維度：分片和節點

2、搜索性能維度：請求率和延遲

3、索引性能維度：刷新(refresh)和合並(Merge)時間

4、節點運行狀況維度：內存，磁盤和CPU指標

5、JVM運行狀況維度：堆，GC和池大小（Pool Size）

6、ElasticsearchTop10監控指標

7、小結

測試人員都是畫畫大神，讓我看看誰還不會用代碼圖？

Object.values()對象遍歷

網絡現代化通向雲原生應用的高速公路

面試官：說說你對序列化的理解

乾貨 | Elasticsearch Top10 監控指標

重磅|Elasticsearch7.X學習路線圖

logstash_output_kafka:Mysql同步Kafka深入詳解

Elasticsearch 7.0 正式發佈，盤他！

Elasticsearch自定義分詞，從一個問題說開去

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結