ElasticSearch Check cluster status

# 1.集群状态为什么会异常？
Elasticsearch 集群健康状态分为三种：
- GREEN
- YELLOW
- RED

GREEN是最健康的状态，说明所有的分片包括副本都可用。这种情况Elasticsearch集群所有的主分片和副本分片都已分配，Elasticsearch集群是100%可用的。

那么，集群状态在什么情况下发生RED和YELLOW呢？
YELLOW：主分片可用，但是副本分片不可用。这种情况Elasticsearch集群所有的主分片已经分配了，但至少还有一个副本是未分配的。不会有数据丢失，所以搜索结果依然是完整的。不过，集群高可用性在某种程度上会被弱化。可以把yellow想象成一个需要关注的warnning，该情况不影响索引读写，一般会自动恢复。

RED：存在不可用的主分片。此时执行查询虽然部分数据仍然可以查到，但实际上已经影响到索引读写，需要重点关注。这种情况Elasticsearch集群至少一个主分片（以及它的全部副本）都在缺失中。这意味着索引已缺少数据，搜索只能返回部分数据，而分配到这个分片上的请求都返回异常。

# 2.检查集群状态
集群Red时，我们可以从如下方法排查 :
1. 集群层面：curl -s 172.31.30.28:9200/_cat/nodes 或者 GET _cluster/health
1. 索引层面：GET _cluster/health?pretty&level=indices
1. 分片层面：GET _cluster/health?pretty&level=shards
1. 恢复情况：GET _recovery?pretty

有unassigned分片的排查思路 ：
1. 先诊断：GET _cluster/allocation/explain
1. 重新分配： /_cluster/reroute

无法分配分片：
-  索引重建：
step 1.新建备份索引：
```
curl -XPUT ‘http://xxxx:9200/a_index_copy/‘ -d ‘{ “settings”:{ “index”:{ “number_of_shards”:3, “number_of_replicas”:2 } } }
```
step 2.通过reindex api将a_index数据copy到a_index_copy：
```
POST _reindex { "source": { "index": "a_index" }, "dest": { "index": "a_index_copy", "op_type": "create" } }
```
step 3.删除a_index索引，这个必须要先做，否则别名无法添加
```
curl -XDELETE 'http://xxxx:9200/a_index'
```
step 4.给a_index_copy添加别名a_index
```
curl -XPOST 'http://xxxx:9200/_aliases' -d ' { "actions": [ {"add": {"index": "a_index_copy", "alias": "a_index"}} ] }'
```

# 3.检查步骤
## 3.1.查看集群的节点信息
```
[root@elastic-01 config]# curl http://11.96.55.6:9200/_cat/nodes?v
ip          heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
11.96.55.5             9          96   0    0.04    0.33     0.72 mdi       -      elastic-08
11.96.55.6            56          98   3    8.17    6.54    10.19 mdi       *      elastic-04
11.96.55.26           41          98   1    3.64    3.90     4.60 mdi       -      xx-12
11.96.55.6            71          98   3    8.17    6.54    10.19 mdi       -      elastic-06
11.96.55.5            11          96   0    0.04    0.33     0.72 mdi       -      elastic-07
11.96.55.7            28          99   2   11.09   10.69    12.18 mdi       -      elastic-01
11.96.55.7            69          99   2   11.09   10.69    12.18 mdi       -      elastic-02
11.96.55.6            55          98   2    8.17    6.54    10.19 mdi       -      elastic-05
11.96.55.29           45          99   2    3.00    2.89     3.70 mdi       -      xx-15
11.96.55.7            38          99   2   11.09   10.69    12.18 mdi       -      elastic-03
11.96.55.28                                                       mdi       -      xx-14
11.96.55.27           68          98   1    3.51    2.31     2.07 mdi       -      xx-13
11.96.55.5             9          96   0    0.04    0.33     0.72 mdi       -      elastic-09
[root@elastic-01 config]# 
```
参数说明：
- ip：节点ip
- heap.percent：堆内存使用百分比
- ram.percent： 运行内存使用百分比
- cpu：cpu使用百分比
- master：带* 表明该节点是主节点，带-表明该节点是从节点

## 3.2.查看集群健康状态
```
[root@elastic-01 config]# curl http://11.96.55.6:9200/_cat/health?v
epoch      timestamp cluster    status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1665201352 03:55:52  data-lakes red            13        13    298 151    0    0      127             0                  -                 70.1%
[root@elastic-01 config]# 
```
参数说明：
- cluster：集群名称
- status：集群状态 green 表示集群一切正常；yellow 表示集群不可靠但可用(单节点状态)；red 集群不可用，有故障。
- node.total：节点总数量
- node.data：数据节点的数量
- shards：存活的分片数量
- pri：主分片数量
- relo：迁移中的分片数量
- init：初始化中的分片数量
- unassign：未分配的分片
- pending_tasks：准备中的任务
- max_task_wait_time：任务最长等待时间
- active_shards_percent：激活的分片百分比

确定集群状态
```
[root@elastic-01 config]# curl http://*:9200/_cluster/health?pretty
{
  "cluster_name" : "data-lakes",                    # es集群名称
  "status" : "red",                                 # es集群状态
  "timed_out" : false,                              # 是否出现超时 
  "number_of_nodes" : 13,                           # es节点数 
  "number_of_data_nodes" : 13,                      # es数据节点数 
  "active_primary_shards" : 151,                    # 集群中所有活跃的主分片数 
  "active_shards" : 298,                            # 集群中所有活跃的分片数 
  "relocating_shards" : 0,                          # 当前节点迁往其他节点的分片数量，通常为0，当有节点加入或者退出时该值会增加 
  "initializing_shards" : 0,                        # 正在初始化的分片 
  "unassigned_shards" : 127,                        # 未分配的分片数，通常为0，当有节点加入或者退出时该值会增加
  "delayed_unassigned_shards" : 0,                  # 延迟未分配的分片数 
  "number_of_pending_tasks" : 0,                    # 是指主节点创建索引并分配shards等任务，如果该指标数值一直未减小代表集群存在不稳定因素 
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 70.11764705882354  # 集群分片的可用性百分比，如果为0则表示不可用
}
[root@elastic-01 config]#
```
有两个未分配的分片，初步怀疑是由于分片分配不成功，导致索引异常，下一步查找异常索引确认问题

## 3.2.查看所有索引状态
```
[root@elastic-01 config]# curl -XGET "http://*:9200/_cat/indices?pretty"
yellow open antennalinfo                    KLWWlNf4RqaBal18N88aaw  5 2 1353286944    55749 405.9gb 184.5gb
green  open .kibana_2                       DjxfwqYbQ6OUySOMv2zU5g  1 1          1        0  10.1kb     5kb
yellow open vehicledetectorheartbeat        dHYGtRXmQz654cgMXnAU3w  5 2          0        0     3kb   1.2kb
red    open .kibana_task_manager            uFgYddfARW2hyJ3i0SCZ9g  1 1                                    
red    open .watcher-history-9-2022.10.07   HPT-FVrfT5qQcQKu1ocgDg  1 1                                    
yellow open trcviu                          U33FdVl-TuC6B31PdanShQ  3 2  899830693    35883 451.6gb 170.3gb
yellow open trcexsu                         BEHjztQGSpCXLbnha5p7Jg  5 1     266363        0 175.7mb 125.5mb
green  open .kibana_1                       ZP2TzofbSG2yQtvvOJBpGA  1 1          1        0  10.1kb     5kb
yellow open trcsplitprovince                fOSY27WcTZ-xjzcVFSSAQA  3 2  490898368     8415 188.5gb  94.2gb
yellow open trcotu                          kQe4qCkBRmKxf97JZY5xBQ  5 1  162883081      233 170.4gb 121.7gb
yellow open .watches                        mvnGP9FUTUuIXkxH_ELo7Q  1 1          8        3  48.4kb  48.4kb
yellow open gantry                          YOE6eA4bQhSspfR1aZTHbw  5 1     286165       72 121.2mb  86.7mb
red    open .watcher-history-9-2022.10.05   DSpTG2LFT4uf3wbmtODwxQ  1 1                                    
red    open .watcher-history-9-2022.10.04   MzqeEjHNQaOrVyWGXJAUag  1 1                                    
red    open .watcher-history-9-2022.10.08   0PlXjLWyQHSbJs4XDTRo0A  1 1                                    
red    open .watcher-history-9-2022.10.06   nK3L6GuISnKwqK0U_x1iuw  1 1                                    
green  open .tasks                          cME3uTmlSpGZYuG4C4Ny0w  1 1          1        0  12.3kb   6.1kb
yellow open otherheartbeat                  3M8glyHKQHKjeQ6xjbs84A  5 2  396370590    29539  84.5gb  38.4gb
yellow open specialevent                    enivzVUdQBSrQT95Y2gWsA  5 1 3620745153     2437   1.3tb 972.8gb
yellow open etcsu_req_data_bak              Bip8GGvSRAWoYqXS5-tHTg 10 3   13154599  2633923     9gb   3.2gb
yellow open data-lakes                      l4pp6eiOQmCrka1z5C-4MQ  5 1          0        0     2kb   1.2kb
yellow open chargeunitheartbeat             GodaL0r-Sg2Ei7trpiYegQ  5 2  398558145    12014 305.4gb 138.8gb
yellow open .elastichq                      93IG80HYTYuVJA0MZluIHA  5 1          1        0  14.1kb   7.3kb
yellow open .triggered_watches              A9v6s3iaQ6y8NIcUB1Wggg  1 1       1241       11  42.5mb  42.5mb
red    open .monitoring-es-6-2022.10.08     AzwYbnRqS-uv_2h2kD66Xg  1 1                                    
yellow open trcout                          QTVQE8tvQn6E00RwHxVAxw  3 2     270138        0 582.7mb 249.7mb
yellow open trclhbu                         Pynl-sqGRc-WqZeqFnQgSg  3 2  566197905      859 378.9gb   190gb
yellow open tghbuviu                        eHLv781TQG2C4EPNOGOZCQ  3 2  103627614     4126 103.7gb  38.9gb
yellow open viu_req_data_bak                YYj7UmJbQi-xOKUc2493Qg  5 1          0        0     2kb   1.2kb
yellow open other                           DHdHhNAHSw-G3VB5cCzp0Q  5 1     159658      126  20.1mb  11.1mb
yellow open rsuheartbeat                    GwdiurfWShOD8W3lMNMPdQ  5 2  463335741    33161 493.2gb 224.1gb
red    open .watcher-history-9-2022.10.02   Xys5HIe2TMa75fp7cMC7hw  1 1                                    
yellow open trcensu                         gedQRLMFRv2M4dLBUE1AGA  5 1     199150        0 144.5mb 103.1mb
red    open .watcher-history-9-2022.10.03   QhLJThfJQQWTqYO_s9ij7g  1 1                                    
yellow open cemera                          i42Qx1xQSfWmUc1ncpY4mw  5 1    3396514      933   711mb 444.5mb
yellow open psaminfo                        CaCERT7RRh-blr3SYmoGkg  5 2 1825079545    70295 606.7gb 275.8gb
yellow open etctu_req_data_bak              W7RkkH9UQGal7SRV2RCBiQ 10 3  725213258 12084876     4tb   1.5tb
red    open .monitoring-kibana-6-2022.10.08 _hpoBWVLS_2fJDfB59RuGA  1 1                                    
yellow open chargeunit                      7bmLmL8lSzGbzdtkPX-fdQ  5 1    1698542      735 650.8mb   465mb
yellow open cameraheartbeat                 _OF7RHkiRAWqGrfSwS8B8w  5 2 1430234291    51347 962.4gb   401gb
yellow open gantryheartbeat                 bIFswWhgTBOiRQaUD0XkBA  5 2  472016514    10879 381.9gb 173.5gb
red    open .watcher-history-9-2022.10.01   Q3_HA9ZyQFqPmbQyoR7ieg  1 1                                    
yellow open viu_req_data                    TVNvhmATScCcgI7ux_CShw  5 1 1237853449  1716308 944.9gb 590.8gb
yellow open rsu                             5v9vr8bvS8yTYl_3TshLjg  5 1    1169492       38 246.6mb 176.2mb
yellow open trcenpu                         -XJPKcKQQ-yEqxJX-xDaxQ  3 2  524183292     3760 560.5gb 239.4gb
yellow open trcexetcpu                      bF0Z4jBRSR2xV9V0Yu9Zmw  3 2  286684820      251 492.8gb 246.3gb
[root@elastic-01 config]# 
```

## 3.3.查看所有索引的分片信息
```
curl http://*:9200/_cat/shards?v
```
查看指定索引的分片信息
```
curl http://*:9200/_cat/shards/.kibana_task_manager?v
```
参数说明：
- index：索引名称
- shard：分片数
- prirep：分片类型，p为主分片，r为复制分片
- state：分片状态，STARTED为正常
- docs：记录数
- store：存储大小
- ip：节点ip
- node：节点名称

## 3.4.查看异常索引状态
```
[root@elastic-01 config]# curl -XGET "http://*:9200/_cat/indices?v&health=red"
health status index                           uuid                   pri rep docs.count docs.deleted store.size pri.store.size
red    open   .kibana_task_manager            uFgYddfARW2hyJ3i0SCZ9g   1   1                                                  
red    open   .watcher-history-9-2022.10.07   HPT-FVrfT5qQcQKu1ocgDg   1   1                                                  
red    open   .watcher-history-9-2022.10.05   DSpTG2LFT4uf3wbmtODwxQ   1   1                                                  
red    open   .watcher-history-9-2022.10.04   MzqeEjHNQaOrVyWGXJAUag   1   1                                                  
red    open   .watcher-history-9-2022.10.08   0PlXjLWyQHSbJs4XDTRo0A   1   1                                                  
red    open   .watcher-history-9-2022.10.06   nK3L6GuISnKwqK0U_x1iuw   1   1                                                  
red    open   .monitoring-es-6-2022.10.08     AzwYbnRqS-uv_2h2kD66Xg   1   1                                                  
red    open   .watcher-history-9-2022.10.02   Xys5HIe2TMa75fp7cMC7hw   1   1                                                  
red    open   .watcher-history-9-2022.10.03   QhLJThfJQQWTqYO_s9ij7g   1   1                                                  
red    open   .monitoring-kibana-6-2022.10.08 _hpoBWVLS_2fJDfB59RuGA   1   1                                                  
red    open   .watcher-history-9-2022.10.01   Q3_HA9ZyQFqPmbQyoR7ieg   1   1                                                  
[root@elastic-01 config]# 
```

## 3.5.查看异常索引分片分配状态，找到异常索引
```
[root@elastic-01 config]# curl -X GET "http://*:9200/_cat/shards/.kibana_task_manager?v" 
index                shard prirep state      docs store ip node
.kibana_task_manager 0     p      UNASSIGNED               
.kibana_task_manager 0     r      UNASSIGNED               
[root@elastic-01 config]# 
```

step 1.查看分片分配不成功的原因
```
# 使用以下查询来识别集群未分配分区的根本原因：
GET /_cluster/allocation/explain

# 要识别哪些索引导致集群进入red状态，请使用以下查询：
GET _cat/indices?v&health=red
GET /_cat/shards?v&h=n,index,shard,prirep,state,sto,sc,unassigned.reason,unassigned.details
```
- ALLOCATION_FAILED：由于分片分配失败而未分配。
- CLUSTER_RECOVERED：由于集群恢复而未分配。
- DANGLING_INDEX_IMPORTED：由于导入了悬空索引导致未分配。
- EXISTING_INDEX_RESTORED：由于恢复为已关闭的索引导致未分配。
- INDEX_CREATED：由于API创建索引而未分配。
- INDEX_REOPENED：由于打开已关闭索引而未分配。
- NEW_INDEX_RESTORED：由于恢复到新索引而未分配。
- NODE_LEFT：由于托管的节点离开集群而未分配。
- REALLOCATED_REPLICA：确定了更好的副本位置，并导致现有副本分配被取消。
- REINITIALIZED：当分片从开始移动回初始化，导致未分配。
- REPLICA_ADDED：由于显式添加副本而未分配。
- REROUTE_CANCELLED：由于显式取消重新路由命令而未分配。

```
[root@elastic-01 config]# curl -XGET "http://*:9200/_cat/shards/.kibana_task_manager?v&h=n,index,shard,prirep,state,sto,sc,unassigned.reason,unassigned.details"
n index                shard prirep state      sto sc unassigned.reason unassigned.details
  .kibana_task_manager 0     p      UNASSIGNED        ALLOCATION_FAILED failed shard on node [HN-dyHNuSCObPxYVdMv2dg]: failed to create shard, failure IllegalStateException[environment is not locked]; nested: NoSuchFileException[/mnt/disk01/elastic-09/data/nodes/0/node.lock]; 
  .kibana_task_manager 0     r      UNASSIGNED        INDEX_CREATED     
[root@elastic-01 config]# 
```
片分配失败原因：获取共享锁超时
```
ALLOCATION_FAILED failed shard on node [HN-dyHNuSCObPxYVdMv2dg]: failed to create shard, failure IllegalStateException[environment is not locked]; nested: NoSuchFileException[/mnt/disk01/elastic-09/data/nodes/0/node.lock]; 
```

step 2.重新分配失败的分片
```
curl -X POST "http://*:9200/_cluster/reroute?retry_failed=true"
```
重新分配失败的分片后，集群状态恢复 green

step 3.重新启停集群尝试
step 4.重新关开索引尝试
```
POST /index/_close(_open)
```
step 5.将副本分片提升为主分片
如果确定了主分片已经损坏，可以尝试将副本分片提升为主(会丢部分数据)：
```
POST /_cluster/reroute?pretty
{
  "commands": [
    {
      "allocate_stale_primary": {
        "index": "indexname",//索引名
        "shard": 3,//操作的分片id
        "node": "node1",//此分片副本位于的节点
        "accept_data_loss": true//提示数据可能会丢失
      }
    }
  ]
}
```
此方案存在一个问题是需要提前知道此分片的副本位于哪个节点用以指定，可以通过如果api获取副本分片位置：
```
GET _shard_stores?pretty
GET indexname/_shard_stores?pretty
```
判断当前es进程使用的数据目录:通过pid和yml配置的目录去匹配，如data
```
ll /proc/pid/fd |grep data
```
如果索引损坏导致api失效，则需要人工去数据目录进行查找副本分片位置,目录结构如下:
```
data/nodes/0/indices/Z60wvPOWSP6Qbk79i757Vg/0
```
数据目录下为节点号 -> 索引文件夹 -> 索引ID -> 分片号

step 6.将此分片置为空分片
如果此分片的主副都已经损坏，则可将此分片置为空以保留索引其他分片数据：
```
{
  "commands": [
    {
      "allocate_empty_primary": {
        "index": "indexname",//索引名
        "shard": 3,//操作的分片id
        "node": "node1",//空分片要分配的节点
        "accept_data_loss": true//提示数据可能会丢失
      }
    }
  ]
}
```
如果集群存在大量索引分片无法恢复，则可以使用脚本将全部分片置空,可以基于下面的脚本修改：
```
#!/bin/bash
master=$(curl -s 'http://localhost:9200/_cat/master?v' | grep -v ' ip ' | awk '{print $1}')
for index in $(curl  -s 'http://localhost:9200/_cat/shards' | grep UNASSIGNED | awk '{print $1}' | sort | uniq); do
    for shard in $(curl  -s 'http://localhost:9200/_cat/shards' | grep UNASSIGNED | grep $index | awk '{print $2}' | sort | uniq); do
        echo  $index $shard
        curl -XPOST -H 'Content-Type: application/json'  'http://localhost:9200/_cluster/reroute' -d '{
            "commands" : [ {
                  "allocate_empty_primary" : {
                      "index" : "'$index'",
                      "shard" : "'$shard'",
                      "node" : "'$master'",
	              "accept_data_loss" : true
                  }
                }
            ]
        }'
        sleep 1
    done
done
```

# 4.优化
修改ES设置，调整ES进行分片分配的重试次数（默认为5次）
```
curl -XPUT "http://*:9200/some_index_name/_settings" -d'
{
  "index": {
    "allocation": {
      "max_retries": 20
    }
  }
}'
```
可进一步查看ES的CPU和内存占用情况，比如都比较高，根本原因是由于历史数据太多导致，应在业务层增加逻辑去定时关闭或删除索引