為了模擬異常場景，我們首先本地搭建一個三個節點的叢集(http埠分別為9200，9400，9600)，然後建立測試用的索引：
curl --location --request PUT 'http://127.0.0.1:9200/fruit-1?pretty' \--header 'Content-Type: application/json' \--data-raw '{ "settings":{ "number_of_shards":3, "number_of_replicas":2 }, "mappings":{ "properties":{ "name":{ "type":"text" }, "fruit_type":{ "type":"keyword" } } }}'使用叢集API檢視此時的叢集狀態,可以看到叢集status是green，總共3個主分片，每個主分片有兩個副本分片，共3+3*2=9個分片。
curl --location --request GET 'http://127.0.0.1:9200/_cat/shards/fruit-1?v'結果如下，可以看到三個主分片分別分佈在三個節點上，同時，每個節點也分佈了兩個副本分片。
2、首先透過cluster API檢視叢集的狀態，可以看到status的值為yellow，unassigned_shards有3個，正好符合目前叢集情況，每個索引都有2個副本分片，同個索引的分片不能位於同一個節點上，所以每個主分片都有一個副本分片沒有被分配。
叢集狀態為red，叢集無法對外提供服務1、建立新的index，但排除分片落在所有的節點上
2、使用explain API檢視分片未分配的原因
3、重置cluster.routing.allocation.exclude
curl --location --request PUT 'http://127.0.0.1:9200/fruit-2/_settings' \--header 'Content-Type: application/json' \--data-raw '{ "index.routing.allocation.exclude._name":null}'4、重新檢視叢集健康狀態，發現status狀態已經變為green。
啟動時提示unable to lock JVM Memory:error=12,reason=cannot allocate memory這是因為配置了bootstrap.memory_lock: true,想要解決這個問題，只需要在/etc/security/limits.conf增加如下內容：
2、透過elasticsearch hot_threads API獲取繁忙執行緒的堆疊，預設情況下，返回3個熱點執行緒的資訊，確定了佔用CPU比較高的執行緒以後就能根據執行緒情況排查到具體的原因了，下面是一個熱點執行緒案例。
2、如果發現是Elasticsearch佔用記憶體很高，可以檢視相關的記憶體結構，判斷是哪個因素導致的。
檢視bulk佇列佔用記憶體
curl --location --request GET 'http://127.0.0.1:9200/_cat/thread_pool/bulk?v'檢視顯示結果queue的大小，乘以bulk請求的大小就可以判斷bulk佇列佔用記憶體的大小。
檢視segments佔用記憶體
以下命令檢視每個節點所有分段佔用的記憶體：
curl --location --request GET 'http://127.0.0.1:9200/_cat/nodes?v&h=segments.memory'segments.memory 2.6kb 2.6kb 2.6kb以下命令檢視每個索引分片上每個分段佔用的記憶體：
index shard segment size.memoryfruit-2 0 _0 1364fruit-2 0 _0 1364fruit-2 0 _0 1364fruit-2 2 _0 1364fruit-2 2 _0 1364fruit-2 2 _0 1364檢視fielddata cache佔用記憶體