ElasticSearch 集群与索引Red&Yellow状态分析思路

开篇

ES的索引有红，黄，绿三种状态，其中绿色代表正常状态，红色和黄色则说明多少有一些问题。我们在正常的ES运维过程中常常需要处理这些情况。

先说明索引的三种颜色代表的意义吧：

绿色：索引的所有分片都正常分配。

黄色：至少有一个副本没有得到正确的分配。

红色：至少有一个主分片没有得到正确的分配。

集群和节点同样有三种颜色，这个颜色取决于相关索引的最差状况。比如说，整个集群中有3个节点，10个索引，每个索引分成3个分片，并有一份副本。如果其中有一个节点离线，上面有多个索引的主分片。那么集群的状态就是红色(red)

可能的情况

事实上，索引状态变成红色或者黄色并不一定是出了问题。这些情况可以通过catAPI查询获知，参考文档：https://www.elastic.co/guide/en/elasticsearch/reference/7.1/cat-shards.html

下面这些情况有可能是正常的情况，可能导致索引的状态临时性的变成红色和黄色。

INDEX_CREATED: 集群正在创建索引。

CLUSTER_RECOVERED: 集群处于重启阶段。

INDEX_OPENED: 正在重新打开一个已经关闭的索引。

NEW_INDEX_RESTORED:还原数据到一个新索引。

EXISTING_INDEX_RESTORED: 还原数据到一个已经关闭的索引。

REPLICA_ADDED: 索引的设置被修改，副本数增加。

REROUTE_CANCELLED: 由于reroute命令被取消导致有一些分片没有被分配。

REINITIALIZED:由于一个分片的状态重新退回到初始化导致。

REALLOCATED_REPLICA:副本位置变化导致未分配。

只有下面几个状态是明确地由于分片错误导致的：

ALLOCATION_FAILED: 由于配置原因或者资源问题导致未分配情况。

DANGLING_INDEX_IMPORTED: 副本在节点离线情况下被修改，在这个副本回到集群中时会产生此问题。

问题的处理

在运维的过程中，如果发现集群的状态变成黄色或者红色，我们不妨等一等，很多问题会在短时间消失。然而，并不是所有错误都能自动修复，如果发现集群状态一直不正常的情况下，我们需要分析具体情况，找出导致问题的根本原因，再将其修复。

ES提供了healthAPI供我们查询集群的状态和发现问题的原因：

参考文档：https://www.elastic.co/guide/en/elasticsearch/reference/7.1/cluster-health.html

我们可以看到一些用法：

GET _cluster/health：检测集群的健康状态，可以使用这个API检测集群的节点数量

GET _cluster/health?level=indices: 查看全部索引的状态，找出有问题的索引

GET _cluster/health/index_name： 检测某个索引的状态，分析问题

GET _cluster/health?level=shards: 查看分片分配的情况，寻找未分配的分片

GET _cluster/allocation/explain: 查看第一个未分配分配的故障原因

在找到原因后，需要对一些不能自动恢复的问题进行修复。

• 配置问题

比如，由于routing的设置，某些索引需要在标记为hot的节点上进行分配，但是集群内并没有标记为hot的节点，这时，索引就会由于主分片无法分配而处于红色状态。解决这种问题，可以向集群中添加或者将集群中某些节点标记为hot来解决，也可以改变routing的策略使得索引主分片可以被正确分配。

又比如，如果当前集群只有一个节点，但是索引的副本配置并非是0，这时副本分片会由于没有多余的节点而无法分配。需要往集群中添加新节点或者将副本配置设为0。

• 资源问题

节点的磁盘空间不足可能导致相关分片无法分配，解决方法是增加新节点或者修改分片方案。

• 故障

上述有一个状态DANGLING_INDEX_IMPORTED，是由于节点离线后，其上的索引被修改导致，这种情况是无法自动恢复的。解决方法是删除该有问题的节点。

集群中如果有节点离线，在相关分片重新分配之前，状态也会变为红色或者黄色。重新分配也也会加到集群剩余节点的压力。需要尽快修复问题，将节点重新上线。

总结

集群状态变成红色或者黄色是运维时经常会出现的状况，并不是所有的情况都是因为故障导致，一些正常的操作也会导致红色或者黄色的状况，并且会在一段时间之内自动恢复。由于故障导致的状态变化往往不会自动恢复，需要通过一些手段进行调查，寻找解决方案并修复问题。