原文地址：https://www.elastic.co/guide/en/elasticsearch/guide/current/_cluster_health.html

Cluster Health（集群狀態）

一個ES集群可能由1個節點1個索引構成，亦或有100個數據節點（data node），3個master節點，幾個客戶端節點（client node） —— 所有的操作都發生在成百上千的分片上。 先不用關心集群的規模，我們可能希望能夠快速的訪問集群狀態，我們可以通過Cluster Health API來訪問集群狀態，它能夠告訴我們集群是否健康，或者提醒我們集群哪里出了點問題。可以像下面這樣調用cluster-health API。 GET _cluster/health像其他ES API一樣cluster-health將返回一個JSON字符串作為response，下面的信息包含了一些和我們集群相關的重要信息 {"cluster_name": "elasticsearch_zach","status": "green","timed_out": false,"number_of_nodes": 1,"number_of_data_nodes": 1,"active_primary_shards": 10,"active_shards": 10,"relocating_shards": 0,"initializing_shards": 0,"unassigned_shards": 0 }在上面比較重要的數據字段是status，它的可能取值如下 green：表示所有分片和副本都被分配，我們的集群100%可用 yellow：表示所有分片都被分配，但是部分副本缺失，沒有數據丟失，查詢結果也是完整的。但在HA存在一定程度安全隱患，如果再丟失一部分主分片可能導致數據丟失。 red：表示至少丟失1個主分片（和所有的備份），這意味著我們集群丟失了數據，查詢結果將不再完整，索引數據時會拋出異常。 green/yellow/red 是一個很好的衡量我們集群狀態健康程度的指標，其他的指標大概描述了我們的集群其他狀態 number_of_nodes：集群所有節點數 number_of_data_nodes：集群所有數據節點數 active_primary_shards：集群所有索引的主分片數 active_shards：集群所有索引的主分片數 relocating_shards：表示當前集群分片從一個節點轉移到另一個節點的分片數，這個值一般情況為0，但是可能會增加，當ES集群不平衡時會存在這種情況，比如一個新節點的加入或一個幾點關閉。 initializing_shards：表示分片在創建初期的分片數。 unassigned_shards：未分配分片數。

深入練習：找到有問題的索引

想象一下如果某天集群出問題，通過cluster-health Api返回的結果如下： {"cluster_name": "elasticsearch_zach","status": "red","timed_out": false,"number_of_nodes": 8,"number_of_data_nodes": 8,"active_primary_shards": 90,"active_shards": 180,"relocating_shards": 0,"initializing_shards": 0,"unassigned_shards": 20 }
OK，我們能從上面的監控檢測結果中推測出什么呢？首先，我們的集群狀態是red，這表示我們丟失了數據（主分片+備份）。我們知道集群有10個節點，但上面只列出了8個，意味著2各節點丟失。我們還能看到有20個未分配的分片。 上面是我們能收集到的所有的信息。從中看不出具體丟失了哪些分片？哪個索引？主分片還是備份？ 為了回答上面的問題，我們可以使用 cluster-health API加上一個level參數： GET _cluster/health?level=indices通過這個參數，我們可以獲得關于集群中索引狀態詳情的列表（狀態、分片數、未分配分片，等等） {"cluster_name": "elasticsearch_zach","status": "red","timed_out": false,"number_of_nodes": 8,"number_of_data_nodes": 8,"active_primary_shards": 90,"active_shards": 180,"relocating_shards": 0,"initializing_shards": 0,"unassigned_shards": 20"indices": {"v1": {"status": "green","number_of_shards": 10,"number_of_replicas": 1,"active_primary_shards": 10,"active_shards": 20,"relocating_shards": 0,"initializing_shards": 0,"unassigned_shards": 0},"v2": {"status": "red", "number_of_shards": 10,"number_of_replicas": 1,"active_primary_shards": 0,"active_shards": 0,"relocating_shards": 0,"initializing_shards": 0,"unassigned_shards": 20 },"v3": {"status": "green","number_of_shards": 10,"number_of_replicas": 1,"active_primary_shards": 10,"active_shards": 20,"relocating_shards": 0,"initializing_shards": 0,"unassigned_shards": 0},....} }1. 我們可以看到v2索引的狀態是red 2. v2索引有20個分片未分配
通過上面的分析問題就變得清晰多了：v2索引有10個分片1個備份，這20個分片都丟失了，可以大概推測出這20個分片都在那丟失的2個節點上。 level這個參數還可以接受更多選項： GET _cluster/health?level=shardsshards這個選項將導致很冗余的輸出，它將列出所有索引上所有分片的狀態詳情。

Blocking for Status Changes

cluster-health API還有一些有用的技巧，特別是在集成一些單元測試的時候，如： GET _cluster/health?wait_for_status=green這個api調用將會被阻塞直到集群返回green狀態時，這在我們單元測試或者腳本運行中非常重要。 當你創建新的索引時，ES必須將集群狀態的改變廣播給集群中每一個節點。這些節點必須初始化新的分片，緊接著返回分片“Started”的狀態給主節點，這個處理過程是很快的，但是由于節點間網絡延遲可能會花費10-20ms。 如果你有一個自動創建索引的腳本，自動去創建索引（a），然后索引一條文檔（b），這個操作可能會失敗，因為此時索引可能還未初始化完畢。在a和b這段時間可能小于1ms（遠遠小于網絡延遲）。 比起讓應用程序（腳本）睡眠更好的辦法是調用cluster-health API加上wait_for_status這個參數，一旦索引分片在所有節點上創建成功，集群狀態立刻變為green，這個API調用會返回，此時再執行索引文檔就不會有問題了。

轉載于:https://www.cnblogs.com/chennanlcy/p/6591789.html

總結

以上是生活随笔為你收集整理的Elasticsearch2.x Cluster Health的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。