Day 9 Elasticsearch API 查詢(Monitor)

前言

昨天我們簡單闡述了ElasticCloud上關於Elasticsearch的簡單設定，以及elasticsearch的cluser API，今天我們繼續介紹基本的Elasticsearch API操作。

這幾天講解的主要都是監控的部分，從第一天的_cat，我們可以查詢到各式各樣的狀態，今天我們來講解一下，在cluster層級中，如何去監控並察覺elasticsearch的異常，進而做出處理。

_Cluster API

首先講解一下cluster，cluster其實就是一整個elasticsearch的架構，通常至少會包含一個node以及一個index，以及多個分片。當然如果擴增到很大，其實是可以擴充到非常大的，幾千個index，幾萬個分片等等。

而我們想要監控目前elasticsearch狀況，其實從整個cluser的健康度就可以略知一二，先找到大問題以後再針對細節去確認。

GET _cluster/health

首先這個指令，就是可以看當前整個cluster的健康狀況，會輸出幾項數值如下：

{
  "cluster_name": "040e5f8c0090455d8f57adf21005276f",
  "status": "green",
  "timed_out": false,
  "number_of_nodes": 3,
  "number_of_data_nodes": 2,
  "active_primary_shards": 36,
  "active_shards": 72,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 0,
  "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": 100.0
}

裡面主要就是目前健康狀況、有多少個node、多少分片。
其中我們可以看目前的健康狀況，有三個情況如下：
green
主分片及副分片都已經有分配好
yellow
有部分的分片遺失，這可能會影響效能或甚至是遺漏資料（算warning）
red
至少有一個主分片遺失，這代表可能會遺漏不少數據，需要及時處理。

而看到健康狀況有問題時，可以檢視unassigned_shards，通常若有遺失的分片，這邊會有值。

這時候可以確認一下節點數量，若節點數量有少，代表這些unassigned_shards，可能就是這些節點遺失的。

因此我們可以進一步去細看，可以透過level去看細節的分片狀況。

GET _cluster/health?level=indices

可以看到細節indices如下：

indices": {
    ".slm-history-2-000001": {
      "status": "green",
      "number_of_shards": 1,
      "number_of_replicas": 1,
      "active_primary_shards": 1,
      "active_shards": 2,
      "relocating_shards": 0,
      "initializing_shards": 0,
      "unassigned_shards": 0
    }

這時若部分的index，health是紅色，且有未分配的分片，那就找到問題原由了，這時候就可以確認他的分片情況

當然也可以再輸出更細節的，但debug層次上，基本上若細到shard，其實也很難去做處理

GET _cluster/health?level=shards

最後介紹一個在做單元測試時非常好用的指令：

GET _cluster/health?wait_for_status=green

這個指令意思是，要等到status是green的時候才會回傳值，如此一來可以用來確認是否狀況健康，可以做為CI/CD的單元測試