ES 05 - 經過Kibana查看Elasticsearch集羣的健康狀態、節點和索引個數

[TOC]

在本篇文章以前, 須要完成: ① 啓動Elasticsearch服務, 至少啓動一個節點, 參考博主文章 ES 02 - Elasticsearch單機服務的部署 (包括常見問題的解決), 部署Elasticsearch服務; ② 啓動Kibana, 參考博主文章 ES 04 - 安裝Kibana插件(6.6.0版本), 安裝並啓動Kibana; ③ 經過瀏覽器訪問Kibana; ④ 進入Dev Tools(開發者工具)界面.

1 檢查集羣的健康情況

ES提供了一套_cat API, 能夠查看ES中的各種數據.

# 查詢API: 
GET _cat/health?v
# 響應信息以下(一行顯示不全, 分做兩行):
epoch       timestamp  cluster  status  node.total  node.data  shards  pri  relo
1552979327  07:08:47   heal_es  yellow           1          1      33   33     0

init  unassign  pending_tasks  max_task_wait_time  active_shards_percent
   0         5              0                   -                  86.8%

(1) 如何快速瞭解集羣的健康情況? 經過查看status選項的值:

① green: 全部primary shard和replica shard都已成功分配, 集羣是100%可用的; ② yellow: 全部primary shard都已成功分配, 但至少有一個replica shard缺失. 此時集羣全部功能都正常使用, 數據不會丟失, 搜索結果依然完整, 但集羣的可用性減弱. —— 須要及時處理的警告. ③ red: 至少有一個primary shard(以及它的所有副本分片)缺失 —— 部分數據不能使用, 搜索只能返回部分數據, 而分配到這個分配上的寫入請求會返回一個異常. 此時雖然能夠運行部分功能, 但爲了索引數據的完整性, 須要儘快修復集羣.

(2) 集羣狀態爲何是yellow?

① 當前只有一個Elasticsearch節點, 並且此時ES中只有一個Kibana內建的索引數據. ② ES爲每一個index默認分配5個primary shard和5個replica shard, 爲了保證高可用, 它還要求primary shard和replica shard不能在同一個node上. ③ 當前服務中, Kibana內建的index是1個primary shard和1個replica shard, 因爲只有1個node, 因此只有primary shard被分配和啓動了, 而replica shard沒有被成功分配(沒有其餘node可用).

2 查看集羣中的節點個數

# 查詢API: 
GET _cat/nodes?v
# 響應信息以下(一行顯示不全, 分做兩行):
ip             heap.percent  ram.percent  cpu  load_1m  load_5m  load_15m  
172.16.22.133            49           98    3     0.56     0.74      1.02

node.role  master  name
mdi        *       1UlY804

3 查看集羣中的索引

# 查詢API: 
GET _cat/indices?v
# 響應信息以下(一行顯示不全, 分做兩行): 
health  status  index      uuid                    pri  rep  
green   open    .kibana_1  4q7ELvdcTVilW3UwtMWqeg    1    0

docs.count  docs.deleted  store.size  pri.store.size
        18             0      78.5kb          78.5kb

版權聲明

做者: 馬瘦風(https://healchow.com)

出處: 博客園 馬瘦風的博客(https://www.cnblogs.com/shoufeng)

感謝閱讀, 若是文章有幫助或啓發到你, 點個[好文要頂👆] 或 [推薦👍] 吧😜

本文版權歸博主全部, 歡迎轉載, 但 [必須在文章頁面明顯位置標明原文連接], 不然博主保留追究相關人員法律責任的權利.