集群熔断和健康值非绿场景分析排查

集群熔断

1、集群熔断的原理

原理：Elasticsearch的请求的数据超过JVM堆内存设置，引发的集群异常。

es中内存分配方式：

官方建议把 50％ 的可用内存作为JVM的堆内存，剩下的 50％给Lucene。

每个es节点使用的内存分为两部分，一是JVM堆内存，分配给es进程，一种是堆外内存，供Lucene使用，因此堆内存越小，Elasticsearch和Lucene的性能越好。

每台节点的JVM内存不要超过32GB。 当JVM内存小于32GB时，会采用了内存指针压缩（compressed oops）技术。一旦超过32 GB 的边界，指针就会切回普通对象的指针。 每个对象的指针都变长了，就会使用更多的 CPU 内存带宽，也就是说你实际上失去了更多的内存。

事实上，当内存到达 40–50 GB 的时候，有效内存才相当于使用内存对象指针压缩技术时候的 32 GB 内存。即便你有足够的内存，也尽量不要超过 32 GB。因为它浪费了内存，降低了 CPU 的性能，还要让 GC 回收大内存。

ES检索数据的过程，大概是这样的：

客户端发送请求到一个coordinate node，在这里就是随机的节点收到请求，根据请求得到对应数据的分片，路由到各个shard，由协调节点进行数据合并、排序、分页等操作，最终产生一个结果返回给客户端。

通过这个原理，数据加载到内存，堆内存不够当前请求加载数据所需要就会报data too large, circuitbreakingexception异常请求被熔断。

这里可以了解下java的新老生代和内存gc机制。

参考文档：GC回收过程 - 简书 (jianshu.com)

ElasticSearch本质上是个Java程序，所以配置JVM垃圾回收器本身也很有必要的工作。我们使用JVM的Xms和Xmx参数来提供指定内存大小，本质上提供的是JVM的堆空间大小，当JVM的堆空间不足的时候就会触发OOM。

出现熔断说明当前节点 JVM 使用率过高，通过熔断保护进程不会 OOM。此时可以通过适当降低读写、清理内存等方法降低节点负载，也可以通过升级节点内存规格来提高 JVM 大小。

熔断器介绍：

Elasticsearch 官方熔断器

父熔断器（Parent circuit breaker）：

父熔断器限制所有子熔断器上使用的内存总量。

Elasticsearch 也设置有各种类型的子熔断器，负责特定请求处理的内存限制。

Field data 熔断器（Field data breaker）：

当对 text 字段聚合或排序时，会产生 Field data 数据结构。Field data 熔断器会预估有多少数据被加载到内存中。当预估的数据占用内存到达 Field data 熔断器阈值时，会触发 Field data 熔断器熔断。

In flight 请求熔断器（In flight requests circuit breaker）：

In flight 请求熔断器限制了在 transport 和 HTTP 层的所有当前传入的请求所使用的内存。

腾讯云 ES 自研熔断器：

官方熔断机制仅仅跟踪那些经常会出问题的请求来预估内存的使用，而无法根据当前节点的实际内存使用状态，来限制请求的内存使用或触发熔断。在腾讯云 ES 中，开发了针对 JVM OLD 区内存使用率的自研熔断器来解决这个问题。

腾讯云 ES 的自研熔断器监控 JVM OLD 区的使用率，当使用率超过85%时开始拒绝写入请求，若 GC 仍无法回收 JVM OLD 区中的内存，在使用率到达90%时将拒绝查询请求。

参考文档：

Elasticsearch Service 集群熔断问题如何解决？ - 常见问题 - 文档中心 - 腾讯云 (tencent.com)

ES的gc日志解读：

参考文档：【最佳实践】巡检项：节点熔断诊断 - 云+社区 - 腾讯云 (tencent.com)

2、集群熔断出现原因枚举

熔断可以先从青鹅平台的集群监控上查看“节点单周期熔断次数”判断是否有熔断发生，再进一步查看集群日志确定具体的熔断信息，做出判断正确处理。

案例1：

客户在做reindex操作时，查看task时显示任务中断，查看集群日志发现有集群有熔断，集群配置为2c4g的低配集群，引导客户升级配置后，熔断没有再发生，后面reindex出现相同报错，再次查看日志，发现是客户的磁盘使用率超水位了，引导客户清理磁盘后，恢复正常。

日志：

磁盘使用率超水位：

案例2：

客户咨询集群健康状态变化原因，排查监控得知集群这个时间有查询陡增部分节点压力大集群节点触发熔断了，排查日志可以得到具体熔断节点，反馈对应信息给客户。

日志：

案例3：

客户反馈集群状态异常，排查监控和日志发现是有熔断发生，协助客户优化了相关参数和查询方面的使用姿势。

日志：

3、解决集群熔断的方案

a：清理内存

参考官网文档，执行API清理fielddata 内存占用和segment 占用内存

参考文档：Elasticsearch Service 集群熔断问题如何解决？ - 常见问题 - 文档中心 - 腾讯云 (tencent.com)

b：更新内核

优先推动更新内核，根据客户使用情况来重启集群更新到最新版本的内核，会有所优化。ES内核基本上每个月都有迭代，会修复一些已知的问题。内核版本查看：

c：合理规划分片

因为请求热点，分片设计不均衡导致的熔断。临时的话，可以通过重启节点进行恢复，长期建议索引主分片合理规划。 这样能有效规避节点熔断带来的集群不稳的问题。分片设计原则：

1、主 shard 数与副 shard 数之和需要是集群数据节点的整数倍；

2、分片容量，主要分为写入和查询两个场景

（写多读少场景）索引单分片10g~20g，多分片有利于写入；

（读多写少场景）索引单分片20g~40g，尽量减少分片数，可以降低热点，因为当分片数过多时，就容易出现长尾子请求，即有可能部分子请求因节点异常或 Old GC、网络抖动等延迟响应，导致整个请求响应缓慢。另一方面，拆分过多的子请求无法提升数据节点请求吞吐，不能充分利用 CPU。在尽量减少主分片数的情况下，同时也可以适当增加副本数，从而提升查询吞吐；

3、在遵循单分片设计原则的前提下，预测出索引最终大小，并根据集群节点数设计索引分片数量，使分片尽量平均分布在各个节点。

d：升级配置

提升集群节点JVM配置。

健康值非绿场景

1、健康值非绿的原理；

RED：

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

YELLOW：

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

GREEN:

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

2、健康值非绿问题定位

合理运用API排查集群健康状态异常原因进行分析处理

GET /_cluster/health：

查看集群索引分片分配情况和健康状态

GET /_cat/indices：

查看索引情况，并根据返回找到状态异常的索引

GET /_cluster/allocation/explain：

查看详细的异常信息

POST _cluster/reroute?retry_failed=true：

触发集群索引副本分片重新分配

参考文档：Elasticsearch集群异常状态（RED、YELLOW）原因分析 - 云+社区 - 腾讯云 (tencent.com)

案例1：

客户反馈集群yellow需要排查原因，排查集群是 1c2g集群 负载比较大 集群yellow是因为存在未分配的副本，恢复速度较慢，集群自行恢复至green。

案例2：

客户反馈长时间集群状态yellow一直未恢复green，排查是集群的一个系统索引的副本分片分配卡住的问题，重新设置这个索引的副本为零，集群会自动加回副本并触发重新分配，分配完成后集群恢复green。

cerebro查看未分配副本情况：

案例3：

客户反馈集群持续red，初步排查是有节点离线导致有主分片不能分配至节点，升级到运维排查具体原因，因为集群是大数据机型磁盘性能不足，当节点压力大的时候，因为磁盘性能不足，节点和master节点通信超时，导致节点离线，节点已经join，等待恢复至green。

3、解决健康值非绿的方案

a:磁盘使用超水位-yellow

磁盘使用超过85%影响集群的副本分片分配，此时清理磁盘空间或者扩容磁盘就可以恢复

b:副本分片分配卡住-yellow

执行API：POST _cluster/reroute?retry_failed=true 触发重新分配分片

c:节点离线/分片损毁-red

整理信息透传至运维恢复处理

d:系统索引副本分配分片卡住-yellow

重新设置这个系统索引的副本为零，集群会自动加回副本并触发触发分配，分配完成后集群会恢复至green。