1、集群狀態red、yellow處理方法
1.red表示主分片數據不完整，通常時由於某個索引的主分片為分片unassigned，找出這個分片未分配的原因，解決即可；
curl -XGET http://{ESIP}:9200/_cluster/health?level=indices
2.yellow表示所有主分片可用，但副本分片不完整，最常見的情景是單節點時，由於es默認是有1個副本，主分片和副本不能在同一個節點上，所以副本就是未分配unassigned；
2、elasticsearch出現unassigned shards的原因排查
1.原因：造成未分配的分片原因有很多，具體看每一次未分配的具體情況，ES使用 Cluster Allocation Explain API，會返回集群為什么不分配分片的詳細原因，照返回的結果，進行有針對性的解決。
2.舉例：ES集群出現unassigned shards，導致集群變黃，執行Cluster Allocation Explain API，返回結果如下：
"reason" : "CLUSTER_RECOVERED","explanation" : "too many shards [6] allocated to this node for index [bot-audio-upload-2020.02.10], index setting [index.routing.allocation.total_shards_per_node=6]"
從返回我們看到集群默認index.routing.allocation.total_shards_per_node=6，意思是單個節點上最大能分配的分片是6個，導致此節點上無法分配額外的分片，副本分片缺失，集群變黃。
3.以下是官方給的reason分類
1）INDEX_CREATED：由於創建索引的API導致未分配。
2）CLUSTER_RECOVERED ：由於完全集群恢復導致未分配。
3）INDEX_REOPENED ：由於打開open或關閉close一個索引導致未分配。
4）DANGLING_INDEX_IMPORTED ：由於導入dangling索引的結果導致未分配。
5）NEW_INDEX_RESTORED ：由於恢復到新索引導致未分配。
6）EXISTING_INDEX_RESTORED ：由於恢復到已關閉的索引導致未分配。
7）REPLICA_ADDED：由於顯式添加副本分片導致未分配。
8）ALLOCATION_FAILED ：由於分片分配失敗導致未分配。
9）NODE_LEFT ：由於承載該分片的節點離開集群導致未分配。
10）REINITIALIZED ：由於當分片從開始移動到初始化時導致未分配（例如，使用影子shadow副本分片）。
11）REROUTE_CANCELLED ：作為顯式取消重新路由命令的結果取消分配。
12）REALLOCATED_REPLICA ：確定更好的副本位置被標定使用，導致現有的副本分配被取消，出現未分配。
3、ES集群磁盤高低水位問題
1.es根據磁盤使用情況來決定是否繼續分配shard，有兩個重要的設置：
cluster.routing.allocation.disk.watermark.low：控制磁盤最小使用率。默認85%.說明es在磁盤使用率達到85%的時候將會停止分配新的shard。
cluster.routing.allocation.disk.watermark.high：控制磁盤的最大使用率。默認90%.說明在磁盤使用率達到90%的時候es將會relocate shard去其他的節點。
2.如果集群中所有data節點的磁盤使用率都達到90%，此時集群將拒絕寫入，可以通過API動態調整高低水位值，例如低水位90%，高水位95%
curl -H 'Content-Type:application/json' -XPUT 'http://10.12.24.77:9202/_cluster/settings' -d'{"transient" : {"cluster.routing.allocation.disk.watermark.low" : “90%","cluster.routing.allocation.disk.watermark.high" : “95%"}}'
4、bulk、index 報錯EsRejectedExcutionException[rejected execution(queue capacity 200) on.......
思路：找出拒絕bulk、index的data節點，默認bulk隊列是200，調整成2000，然后查此節點磁盤、CPU，確認在報錯時間點是否繁忙。
1.通過API查看下thread pool配置，默認index、bulk線程池大小與cpu核數保持一致，bulk、index queue_size默認是200，生產環境后期部署均給2000，發現是默認的200，可以調整到2000；
curl -XGET http://10.35.50.42:9201/_nodes/thread_pool?pretty
thread_pool.bulk.queue_size: 2000
2.通過cat thread_pool API查看各節點index、bulk拒絕數量統計，找出拒絕bulk、index請求的data節點；
curl -XGET http://10.35.50.42:9201/_cat/thread_pool?pretty
3.排查data節點在報錯時間是否有IO、CPU繁忙的問題存在，如果集群中所有data節點均有拒絕，說明集群寫入出現瓶頸，需要擴容或者更換性能更好的SSD盤。
5、緩解data節點IO wait高導致的CPU Load高的情況
1.當IO wait出現時，表明節點IO出現瓶頸，出現這種情況的同時，通常伴隨着大量的數據寫入，先判斷如果是日志或對搜索實時性要求不是很高的場景，可以嘗試修改索引settings
通常修改兩處（可以動態修改），保證數據異步落盤，減少段合並頻率，釋放IO壓力
"refresh_interval": "60s",
"translog": {
"flush_threshold_size": "500mb",
"sync_interval": "60s",
"durability": "async"
},
2.如果IO wait依然很高，可以考慮下掉副本，但這樣索引數據的高可用就無法保證，需要看具體場景，同時和業務方確認；
3.給集群擴容data節點，或更換性能更高的SSD盤。
6、緩解JVM Heap使用率高的情況
1.先看JVM Heap已使用容量高會導致哪些問題：
1）寫入性能查，index buffer缺少一定的內存空間用緩沖文檔數據；
2）查詢或搜索性能異常，缺少一定的數據緩存空間，導致查詢超時或中斷；
3）嚴重情況下出現內存溢出異常，節點宕機，java.lang.OutOfMemoryError: Java heap space
2.解決方法：
1）確認data節點的JVM配置大小，生產環境一般給30G；
2）關閉或刪除過期的索引數據，釋放出空間；
3）給集群擴容，並平衡分片。
7、當前查詢加載數據會報”breaker.CircuitBreakingException: [parent] Data too large, data for [<http_request>] would be [1454565650/1.3gb], which is larger than the limit of..."；
1.問題原因：fielddata緩存占用大量JVM Heap空間，其他索引無法分配更多的內存，所以當前查詢加載數據會報錯；
通過API可以查看fielddata緩存占用的內存大小；GET /_stats/fielddata?pretty
2.解決方法：
1）通過設置indices.fielddata.cache.size值來修改單個索引占用緩存的大小，如果超出這個值，該數據將被逐出，設置方法有兩種，一種是更新配置文件后重啟生效，另一種是API動態修改
indices.fielddata.cache.size: 20% _cluster/settings { "persistent" : { "indices.breaker.fielddata.limit" : "20%" }}
2）清理fielddata緩存，清理后並確認；
curl localhost:9200/index/_cache/clear?pretty&field_data=true
3）給當前集群擴容data節點。