有kibana最好了。
https://www.elastic.co/guide/en/elasticsearch/reference/current/cat.html 感興趣的，英語OK的同學可以去官網自查
·························································
查看API
查看別名接口(_cat/aliases): 查看索引別名
查看分配資源接口(_cat/allocation)
查看文檔個數接口(_cat/count)
查看字段分配情況接口(_cat/fielddata)
查看健康狀態接口(_cat/health)
查看索引信息接口(_cat/indices)
查看master信息接口(_cat/master)
查看nodes信息接口(_cat/nodes)
查看正在掛起的任務接口(_cat/pending_tasks)
查看插件接口(_cat/plugins)
查看修復狀態接口(_cat/recovery)
查看線城池接口(_cat/thread_pool)
查看分片信息接口(_cat/shards)
查看lucence的段信息接口(_cat/segments)
··························································································
集群API
查看集群健康狀態接口(_cluster/health)
查看集群狀況接口(_cluster/state)
查看集群統計信息接口(_cluster/stats)
查看集群掛起的任務接口(_cluster/pending_tasks)
集群重新路由操作(_cluster/reroute)
更新集群設置(_cluster/settings)
節點狀態(_nodes/stats)
節點信息(_nodes)
節點的熱線程(_nodes/hot_threads)
關閉節點(\nodes/_master/_shutdown)
以下對常用的命令做了解釋·············································································
verbose
每個命令都支持使用?v參數，來顯示詳細的信息
help
每個命令都支持使用help參數，來輸出可以顯示的列：
$ curl localhost:9200/_cat/master?help
id | | node id
host | h | host name
ip | | ip address
node | n | node name
headers
通過h參數，可以指定輸出的字段：
$ curl localhost:9200/_cat/master?v
id host ip node
QG6QrX32QSi8C3-xQmrSoA 127.0.0.1 127.0.0.1 Manslaughter
$ curl localhost:9200/_cat/master?h=host,ip,node
127.0.0.1 127.0.0.1 Manslaughter
參數拼到？后面 和 get請求一樣
····································································································
1._cat/allocation 查看分配資源接口
curl 192.168.10.7:9200/_cat/allocation
9 38.8mb 4.7gb 13gb 17.7gb 26 192.168.2.116 192.168.2.116 node-1
9 38.8mb 9.1gb 8.6gb 17.7gb 51 192.168.2.114 192.168.2.114 node-2
curl 192.168.10.7:9200/_cat/allocation?v ?v表示顯示詳細信息（字段名）
shards disk.indices disk.used disk.avail disk.total disk.percent host ip node
9 38.8mb 9.1gb 8.6gb 17.7gb 51 192.168.2.114 192.168.2.114 node-1
9 38.8mb 4.7gb 13gb 17.7gb 26 192.168.2.116 192.168.2.116 node-2
shards:分片個數
disk.indices：索引所占磁盤大小
disk.used：已用磁盤大小
disk.avail：可以使用磁盤大小
disk.total：磁盤總容量
disk.percent：磁盤使用百分比
host：主機名
ip：服務ip
node：節點名稱
------------------------------------------------------------
2._cat/nodes?v
curl 192.168.10.7:9200/_cat/nodes?v
ip heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
192.168.2.114 10 96 1 0.00 0.01 0.00 mdi - node-1
192.168.2.116 3 100 0 0.00 0.00 0.00 mdi * node-2
heap.percent：堆內存占的內存百分比
ram.percent：物理內存占用百分比
cpu：表示使用的cpu核心
load_1m load_5m load_15m：1分鍾 5分鍾 15分鍾 占用系統cup百分比
node.role：表示節點能充當的角色主、數據 節點
master：表示當前是否為主節點，*表示當前為主
------------------------------------------------------------
3._cluster/health 快速檢查集群的健康狀況
curl localhost:9200/_cluster/health?pretty # ?pretty JSON格式顯示，易讀
{
"cluster_name" : "RK",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 2,
"number_of_data_nodes" : 2,
"active_primary_shards" : 9,
"active_shards" : 18,
"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
}
輸出里最重要的就是 status 這行。很多開源的 ES 監控腳本，其實就是拿這行數據做報警判斷。status 有三個可能的值：
green 綠燈，所有分片都正確運行，集群非常健康。
yellow 黃燈，所有主分片都正確運行，但是有副本分片缺失。這種情況意味着 ES 當前還是正常運行的，但是有一定風險。注意，在 Kibana4 的 server 端啟動邏輯中，即使是黃燈狀態，Kibana 4 也會拒絕啟動，死循環等待集群狀態變成綠燈后才能繼續運行。
red 紅燈，有主分片缺失。這部分數據完全不可用。而考慮到 ES 在寫入端是簡單的取余算法，輪到這個分片上的數據也會持續寫入報錯。
curl 'localhost:9200/_cluster/health?level=cluster&pretty'
接口請求的時候，可以附加一個 level 參數，指定輸出信息以 indices 還是 shards 級別顯示。當然，有三個級別：cluster，indices，shards （如果寫錯了就默認輸出cluster級別）一般來說，indices 級別就夠了。
green
所有的主分片和副本分片都已分配。你的集群是 100% 可用的。
yellow
所有的主分片已經分片了，但至少還有一個副本是缺失的。不會有數據丟失，所以搜索結果依然是完整的。不過，你的高可用性在某種程度上被弱化。如果 更多的 分片消失，你就會丟數據了。把 yellow 想象成一個需要及時調查的警告。
red
至少一個主分片（以及它的全部副本）都在缺失中。這意味着你在缺少數據：搜索只能返回部分數據，而分配到這個分片上的寫入請求會返回一個異常。
green/yellow/red 狀態是一個概覽你的集群並了解眼下正在發生什么的好辦法。剩下來的指標給你列出來集群的狀態概要：
number_of_nodes 和 number_of_data_nodes 這個命名完全是自描述的。
active_primary_shards 指出你集群中的主分片數量。這是涵蓋了所有索引的匯總值。
active_shards 是涵蓋了所有索引的_所有_分片的匯總值，即包括副本分片。
relocating_shards 顯示當前正在從一個節點遷往其他節點的分片的數量。通常來說應該是 0，不過在 Elasticsearch 發現集群不太均衡時，該值會上漲。比如說：添加了一個新節點，或者下線了一個節點。
initializing_shards 是剛剛創建的分片的個數。比如，當你剛創建第一個索引，分片都會短暫的處於 initializing 狀態。這通常會是一個臨時事件，分片不應該長期停留在 initializing 狀態。你還可能在節點剛重啟的時候看到 initializing 分片：當分片從磁盤上加載后，它們會從 initializing 狀態開始。
unassigned_shards 是已經在集群狀態中存在的分片，但是實際在集群里又找不着。通常未分配分片的來源是未分配的副本。比如，一個有 5 分片和 1 副本的索引，在單節點集群上，就會有 5 個未分配副本分片。如果你的集群是 red 狀態，也會長期保有未分配分片（因為缺少主分片）。
鑽更深點：找到問題索引編輯
想象一下某天碰到問題了， 而你發現你的集群健康狀態看起來像是這樣：
{
"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
}
好了，從這個健康狀態里我們能推斷出什么來？嗯，我們集群是 red ，意味着我們缺數據（主分片 + 副本分片）了。我們知道我們集群原先有 10 個節點，但是在這個健康狀態里列出來的只有 8 個數據節點。有兩個數據節點不見了。我們看到有 20 個未分配分片。
這就是我們能收集到的全部信息。那些缺失分片的情況依然是個謎。我們是缺了 20 個索引，每個索引里少 1 個主分片？還是缺 1 個索引里的 20 個主分片？還是 10 個索引里的各 1 主 1 副本分片？具體是哪個索引？
要回答這個問題，我們需要使用 level 參數讓 cluster-health 答出更多一點的信息：
GET _cluster/health?level=indices
這個參數會讓 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
"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
},
....
}
}
我們可以看到 v2 索引就是讓集群變 red 的那個索引。
由此明確了，20 個缺失分片全部來自這個索引。
一旦我們詢問要索引的輸出，哪個索引有問題立馬就很清楚了：v2 索引。我們還可以看到這個索引曾經有 10 個主分片和一個副本，而現在這 20 個分片全不見了。可以推測，這 20 個索引就是位於從我們集群里不見了的那兩個節點上。
level 參數還可以接受其他更多選項：
GET _cluster/health?level=shards
shards 選項會提供一個詳細得多的輸出，列出每個索引里每個分片的狀態和位置。這個輸出有時候很有用，但是由於太過詳細會比較難用。如果你知道哪個索引有問題了，本章討論的其他 API 顯得更加有用一點。
阻塞等待狀態變化編輯
當構建單元和集成測試時，或者實現和 Elasticsearch 相關的自動化腳本時，cluster-health API 還有另一個小技巧非常有用。你可以指定一個 wait_for_status 參數，它只有在狀態達標之后才會返回。比如：
GET _cluster/health?wait_for_status=green
這個調用會 阻塞 （不給你的程序返回控制權）住直到 cluster-health 變成 green ，也就是說所有主分片和副本分片都分配下去了。這對自動化腳本和測試非常重要。
如果你創建一個索引，Elasticsearch 必須在集群狀態中向所有節點廣播這個變更。那些節點必須初始化這些新分片，然后響應給主節點說這些分片已經 Started 。這個過程很快，但是因為網絡延遲，可能要花 10–20ms。
如果你有個自動化腳本是 (a) 創建一個索引然后 (b) 立刻寫入一個文檔，這個操作會失敗。因為索引還沒完全初始化完成。在 (a) 和 (b) 兩步之間的時間可能不到 1ms —— 對網絡延遲來說這可不夠。
比起使用 sleep 命令，直接讓你的腳本或者測試使用 wait_for_status 參數調用 cluster-health 更好。當索引完全創建好，cluster-health 就會變成 green ，然后這個調用就會把控制權交還給你的腳本，然后你就可以開始寫入了。
有效的選項是： green 、 yellow 和 red 。這個調回會在達到你要求（或者『更高』）的狀態時返回。比如，如果你要求的是 yellow ，狀態變成 yellow 或者 green 都會打開調用。
4.查看集群的健康狀態。
http://127.0.0.1:9200/_cat/health?v
URL中_cat表示查看信息，health表明返回的信息為集群健康信息，?v表示返回的信息加上頭信息，跟返回JSON信息加上?pretty同理，就是為了獲得更直觀的信息，當然，你也可以不加，不要頭信息，特別是通過代碼獲取返回信息進行解釋，頭信息有時候不需要，寫shell腳本也一樣，經常要去除一些多余的信息。
通過這個鏈接會返回下面的信息，下面的信息包括：
集群的狀態（status）：red紅表示集群不可用，有故障。yellow黃表示集群不可靠但可用，一般單節點時就是此狀態。green正常狀態，表示集群一切正常。
節點數（node.total）：節點數，這里是2，表示該集群有兩個節點。
數據節點數（node.data）：存儲數據的節點數，這里是2。數據節點在Elasticsearch概念介紹有。
分片數（shards）：這是12，表示我們把數據分成多少塊存儲。
主分片數（pri）：primary shards，這里是6，實際上是分片數的兩倍，因為有一個副本，如果有兩個副本，這里的數量應該是分片數的三倍，這個會跟后面的索引分片數對應起來，這里只是個總數。
激活的分片百分比（active_shards_percent）：這里可以理解為加載的數據分片數，只有加載所有的分片數，集群才算正常啟動，在啟動的過程中，如果我們不斷刷新這個頁面，我們會發現這個百分比會不斷加大。
5.查看集群的索引數。
http://127.0.0.1:9200/_cat/indices?v
通過該連接返回了集群中的所有索引：
索引健康（health），green為正常，yellow表示索引不可靠（單節點），red索引不可用。與集群健康狀態一致。
狀態（status），表明索引是否打開。
索引名稱（index），這里有.kibana和school。
uuid，索引內部隨機分配的名稱，表示唯一標識這個索引。
主分片（pri），.kibana為1，school為5，加起來主分片數為6，這個就是集群的主分片數。
文檔數（docs.count），school在之前的演示添加了兩條記錄，所以這里的文檔數為2。
已刪除文檔數（docs.deleted），這里統計了被刪除文檔的數量。
索引存儲的總容量（store.size），這里school索引的總容量為6.4kb，是主分片總容量的兩倍，因為存在一個副本。
主分片的總容量（pri.store.size），這里school的主分片容量是7kb，是索引總容量的一半。
1.查看集群的健康狀態。
http://127.0.0.1:9200/_cat/health?v
URL中_cat表示查看信息，health表明返回的信息為集群健康信息，?v表示返回的信息加上頭信息，跟返回JSON信息加上?pretty同理，就是為了獲得更直觀的信息，當然，你也可以不加，不要頭信息，特別是通過代碼獲取返回信息進行解釋，頭信息有時候不需要，寫shell腳本也一樣，經常要去除一些多余的信息。
通過這個鏈接會返回下面的信息，下面的信息包括：
集群的狀態（status）：red紅表示集群不可用，有故障。yellow黃表示集群不可靠但可用，一般單節點時就是此狀態。green正常狀態，表示集群一切正常。
節點數（node.total）：節點數，這里是2，表示該集群有兩個節點。
數據節點數（node.data）：存儲數據的節點數，這里是2。數據節點在Elasticsearch概念介紹有。
分片數（shards）：這是12，表示我們把數據分成多少塊存儲。
主分片數（pri）：primary shards，這里是6，實際上是分片數的兩倍，因為有一個副本，如果有兩個副本，這里的數量應該是分片數的三倍，這個會跟后面的索引分片數對應起來，這里只是個總數。
激活的分片百分比（active_shards_percent）：這里可以理解為加載的數據分片數，只有加載所有的分片數，集群才算正常啟動，在啟動的過程中，如果我們不斷刷新這個頁面，我們會發現這個百分比會不斷加大。
2.查看集群的索引數。
http://127.0.0.1:9200/_cat/indices?v
通過該連接返回了集群中的所有索引：
索引健康（health），green為正常，yellow表示索引不可靠（單節點），red索引不可用。與集群健康狀態一致。
狀態（status），表明索引是否打開。
索引名稱（index），這里有.kibana和school。
uuid，索引內部隨機分配的名稱，表示唯一標識這個索引。
主分片（pri），.kibana為1，school為5，加起來主分片數為6，這個就是集群的主分片數。
文檔數（docs.count），school在之前的演示添加了兩條記錄，所以這里的文檔數為2。
已刪除文檔數（docs.deleted），這里統計了被刪除文檔的數量。
索引存儲的總容量（store.size），這里school索引的總容量為6.4kb，是主分片總容量的兩倍，因為存在一個副本。
主分片的總容量（pri.store.size），這里school的主分片容量是7kb，是索引總容量的一半。