在使用ES的過程中，我們時常要關注着集群的狀態。
ES查看集群的狀態實際上也是使用RESTful的接口，而且一般用的是GET方法，所以本文演示就直接用瀏覽器演示就好了。
curl和kibana下Dev tools的console方法都是一樣的。
- crul
curl -X get [請求的鏈接]
- kibana
GET [請求的鏈接]
也許，我們查看集群狀態頻率最高的是下面這個。
http://[主機IP]:[ES端口]
通常我們啟動服務器之后，就可以通過這個簡單的方式來驗證服務器是否啟動成功。
從下面返加的JSON我們可以得到該節點的節點名，所屬集群名，ES版本號，lucene版本號
本次演示的集群有兩個節點，屬於本地單台機器的兩個節點。
主機IP和端口如下
127.0.0.1:9200
127.0.0.1:9201
所以我們從另外一個節點進入，情況是一樣的。
因此在下面演示過程中，端口號使用9200與9201無異，我選擇9200端口進行演示。
下面演示利用其它URL來監控和查看集群狀態。
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
通過該連接返回了集群中的所有索引，其中.kibana是kibana連接后在es建的索引，school是我自己添加的。
這些信息，包括
索引健康（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，是索引總容量的一半。
3.查看集群所在磁盤的分配狀況
http://127.0.0.1:9200/_cat/allocation?v
通過該連接返回了集群中的各節點所在磁盤的磁盤狀況
返回的信息包括：
分片數（shards），集群中各節點的分片數相同，都是6，總數為12，所以集群的總分片數為12。
索引所占空間（disk.indices），該節點中所有索引在該磁盤所點的空間。
磁盤使用容量（disk.used），已經使用空間41.6gb
磁盤可用容量（disk.avail），可用空間4.3gb
磁盤總容量（disk.total），總共容量45.9gb
磁盤便用率（disk.percent），磁盤使用率90%。
4.查看集群的節點
http://127.0.0.1:9200/_cat/nodes?v
通過該連接返回了集群中各節點的情況。這些信息中比較重要的是master列，帶*星號表明該節點是主節點。帶-表明該節點是從節點。
另外還是heap.percent堆內存使用情況，ram.percent運行內存使用情況，cpu使用情況。
5.查看集群的其它信息。
http://127.0.0.1:9200/_cat/
通過上面的鏈接，其實，我們就相當於獲得查看集群信息的目錄。
=^.^= /_cat/allocation /_cat/shards /_cat/shards/{index} /_cat/master /_cat/nodes /_cat/tasks /_cat/indices /_cat/indices/{index} /_cat/segments /_cat/segments/{index} /_cat/count /_cat/count/{index} /_cat/recovery /_cat/recovery/{index} /_cat/health /_cat/pending_tasks /_cat/aliases /_cat/aliases/{alias} /_cat/thread_pool /_cat/thread_pool/{thread_pools} /_cat/plugins /_cat/fielddata /_cat/fielddata/{fields} /_cat/nodeattrs /_cat/repositories /_cat/snapshots/{repository} /_cat/templates
6.http創建空索引
需要添加http請求的head信息，指定為json
PUT /haoke
添加body
{ "settings": { "index": { "number_of_shards": "2", "number_of_replicas": "0" } } }
number_of_shards : 分片數
number_of_replicas： 副本數
7、刪除索引
DELETE /haoke
不給請求體，返回 {"acknowledged": true}
8. 插入數據
POST /{索引}/{索引類型}/{id} id如果不傳，會自動生成
例:
POST /haoke/user/1001
指定body
{ "id": 1001, "name": "張三", "age": 20, "sex": "男" }
查看結果：
說明：非結構化的索引，不需要事先創建，直接插入數據默認創建索引。
不指定id插入數據：
POST /haoke/user/
指定body
{ "id": 1002, "name": "張三", "age": 20, "sex": "男" }
更新數據：
在Elasticsearch中，文檔數據是不可修改的，但是可以通過覆蓋的方式進行更新，步驟如下：
1. 從舊文檔中檢索JSON
2. 修改它
3. 刪除舊文檔
4. 索引新文檔
PUT /haoke/user/1001
指定body, 將性別修改為 “女”
{ "id": 1001, "name": "李四", "age": 30, "sex": "女" }
局部更新，與全部更新機制相同，只是多了_update標識
POST /haoke/user/1001/_update
指定body
{ "doc": { "age": 23 } }
查看 
9、 刪除數據
發起delete請求即可
DELETE /haoke/user/1001
需要注意的是，result表示已經刪除，version也增加了，如果刪除一條不存在的數據，會響應404。 說明：刪除一個文檔不會立即從磁盤上移除，它只是被標記成已刪除。Elasticsearch將會在你之后添加更多索引的時候才會在后台進行刪除內容的清理。
10、搜索數據
根據id搜索數據
GET /haoke/user/6NAVEXEBVAiLr6jRjciF
11、搜索全部數據（默認返回10條數據）
GET /haoke/user/_search
12、關鍵字搜素數據，查詢年齡等於20的用戶
GET /haoke/user/_search?q=age:20
13、 DSL搜索
14、刪除所有數據
POST /haoke/_delete_by_query
傳入body
{ "query": { "match_all": {} } }
返回：
{ "took": 1828, "timed_out": false, "total": 2983, "deleted": 2983, "batches": 3, "version_conflicts": 0, "noops": 0, "retries": { "bulk": 0, "search": 0 }, "throttled_millis": 0, "requests_per_second": -1.0, "throttled_until_millis": 0, "failures": [] }
ref: https://www.cnblogs.com/roadlandscape/p/12568550.html