iT邦幫忙

第 12 屆 iT 邦幫忙鐵人賽

DAY 9
0

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的單元測試


上一篇
Day 8 Elasticsearch基本設定及查詢(續)
下一篇
Day 10 Index API介紹及使用
系列文
親愛的,我把ElasticSearch上雲了30

尚未有邦友留言

立即登入留言