《ES故障处理指南》Elasticsearch集群异常状态分析-集群YELLOW

说明本文所述的问题及解决方案同样适用于腾讯云Elasticsearch服务（ES）。本文是上一篇文章的延续：Elasticsearch集群异常状态（红、黄）原因分析 前言 在上一篇文章中，我们初步了解了ES异常状态的排查思路，以及ES在什么情况下会导致分片异常。

本文将继续扩展，进一步介绍集群异常状态的排查及处理方案。异常状态分析 我们已经了解到ES集群异常状态分为YELLOW和RED。

黄色：主分片可用，但副本分片不可用。在这种情况下，Elasticsearch集群的所有主分片均已分配，但至少有一个副本未分配。

没有数据丢失，因此搜索结果保持不变。但集群高可用会受到一定程度的削弱。

您可以将黄色视为需要注意的警告。这种情况不影响索引读写，一般会自动恢复。

红色：有一个不可用的主分片。虽然此时执行查询时仍然可以找到一些数据，但实际上已经影响了索引的读写，需要特别注意。

在这种情况下，Elasticsearch 集群（及其所有副本）至少有一个主分片丢失。这意味着索引缺少数据，搜索仅返回部分数据，并且分配给该分片的请求返回异常。

在这篇文章中，我们将讲解如何处理集群处于YELLOW异常状态，以及什么情况下不需要人工干预，什么情况下需要人工干预。黄色异常 黄色异常是ES中最常见的集群异常。

当负载较高时，集群往往会长时间陷入黄色状态而无法逃脱。其表现形式是：不需要人工干预，副本分片的恢复速度慢，大部分副本分片都在排队初始化，需要人工干预，并且在没有人工干预的情况下无法分配副本分片。

场景一：写触发索引创建（INDEX_CREATED） ES支持在索引不存在时发起写入索引。写入时，ES会自动创建索引，并开始自动映射（put-mapping）不存在的索引字段。

这是一个繁重的操作，会给元数据带来很大的压力。 尤其是当有大量写入或者集群本身的元数据较大时，ES会延迟分配副本分片并进入pending_task队列，这会导致集群陷入黄色状态。

此时，即使副本分片开始初始化，由于索引的大量写入，也需要同步主分片数据，从而导致副本分片初始化缓慢。 总体表现为集群长期处于黄色状态，短时间内无法逃逸。

不过，这种情况会自动恢复。当副本分片初始化完成后，黄色状态将变为绿色。

如图：当URGENT Task过多时，会导致HIGH Task排队，进入pending状态。优化建议：业务可以提前预先创建索引，而不是让批量请求自动触发索引创建（create-index）。

场景二：节点暂时下线（NODE_LEFT） 我们假设集群中所有索引都有冗余副本分片，并且只有一个节点下线，那么此时集群会进入黄色状态。由于该索引目前主分片仍然在线，因此不会对业务使用造成影响。

如果短时间内节点因压力过大而发生脱离，一般会自动恢复。这种情况不需要人工干预：代码语言：javascript copy [o.e.c.r.a.AllocationService] [] failed shard [failed shard, shard [.ds-cdwch -.11.13-04][23], node[vAnpreEnTaSWY-QYV3GGWg], [R ]、recovery_source[对等恢复]、s[初始化]、a[id=r48vj2pQRmauAuXKm-qX9g]、unassigned_info[[reason=NODE_LEFT]，位于 [11-14T06:58:10.Z]、delayed=true、详细信息[node_left [vAnpreEnTaSWY-QYV3GGWg]]，allocation_status[no_attempt]]，消息[恢复失败]，失败 [RecoveryFailedException[[.ds-cdwch-.11.13 -04][23]：从 {}{QUotMJ0DRsiMJPtqlmA}{2aWADQvMRjSKRRsFg-Abrw 恢复失败}{10.1.0.47}{10.1.0.47:}{hilrst}{ml.machine_memory=,rack=cvm_8_07,xpack.installed=true,set=07,transform.node=true,ip=9.15..,ml.max_open_jobs =、ml.max_jvm_size=、region=8} 进入 {}{vAnpreEnTaSWY-QYV3GGWg}{-vaCwjbhSpG1iGEY18Wz4A}{10.0..45}{10.0 ..45:}{hilrst}{ml.machine_memory=、rack=cvm_8_06、xpack .installed=true、set=06、transform.node=true、ip=9.15..46、ml.max_open_jobs=、ml.max_jvm_size=, 区域=8}];嵌套：RemoteTransportException[[][10.1.0.47:][内部：index/shard/recovery/start_recovery]];嵌套：ScpRecoveryIsRunningException[正在为同一副本和节点运行另一个恢复任务。

现有恢复：RecoveryKey{shard: [.ds-cdwch-.11.13-04][23]，目标：vAnpreEnTaSWY-QYV3GGWg，recovery:21}，新恢复：RecoveryKey{shard: [.ds-cdwch-.11.13-04 ][23]，目标：vAnpreEnTaSWY-QYV3GGWg，恢复：26}]； ], markAsStale [true]]org.elasticsearch.indices.recovery.RecoveryFailedException: [.ds-cdwch-yuogefjn-es-let66hx8-space-mk4wn5x5-.11.13-04][23]: 从 {}{QUotMJ0DRsiMJPtqlmA} 恢复失败{2aWADQvMRjSKRRsFg-Abrw}{10.1.0.47}{10.1.0.47:}{hilrst}{ml.machine_memory=,rack=cvm_8_07,xpack.installed=true,set=07,transform.node=true,ip=9.15.. 、ml.max_open_jobs=、ml.max_jvm_size=、region=8} 进入 {}{vAnpreEnTaSWY-QYV3GGWg}{-vaCwjbhSpG1iGEY18Wz4A}{10.0..45}{10.0..45:}{hilrst}{ml.machine_memory=，机架=cvm_8_06, xpack.installed=true，set=06，transform.node=true，ip=9.15..46，ml.max_open_jobs=，ml.max_jvm_size=，region=8}at org.elasticsearch.indices.recovery.PeerRecoveryTargetService$RecoveryResponseHandler.handleException(PeerRecoveryTargetService.java :) ~[elasticsearch-7.14.2.jar:7.14.2]在 org.elasticsearch.transport.TransportService$ContextRestoreResponseHandler.handleException(TransportService.java:) ~[elasticsearch-7.14.2.jar:7.14.2]在 org .elasticsearch.transport.TransportService$ContextRestoreResponseHandler.handleException(TransportService.java:) ~[elasticsearch-7.14.2.jar:7.14.2] 在 org.elasticsearch.transport.InboundHandler.lambda$handleException$3(InboundHandler.java:) ~ [elasticsearch-7.14.2.jar:7.14.2]at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:) ~[elasticsearch-7.14.2.jar:7.14.2]at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:) [?:?]at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:) [?:?]at java.lang.Thread.run(Thread.java:) [?:?]引起：org.elasticsearch.transport.RemoteTransportException: [][10.1 .0.47:][internal:index/shard/recovery/start_recovery]优化建议：节点一般不会无故离线。如果偶尔有节点离开，则需要进一步检查ES是否存在资源瓶颈。

场景 3：集群崩溃 (ALLOCATION_FAILED) 什么是断路器？ Elasticsearch Service官方提供了多种断路器来防止内存使用过多导致ES集群因OutOfMemoryError而出现问题。 Elasticsearch 设置了各种类型的子断路器，负责特定请求处理的内存限制。

此外，还有一个父熔丝限制所有子熔丝使用的内存总量。断路器介绍 父断路器 父断路器限制所有子断路器使用的内存总量。

当父断路器被触发时，可能的日志信息如下： 代码语言：javascript Copy Caused by: org. elasticsearch.common.breaker.CircuitBreakingException: [parent] 数据太大，[] 的数据将为 [47/1.6gb]，大于 [24/1.5gb] 的限制，实际使用量：[72 /1.6gb]，保留新字节：[/b]Field data Breaker（字段数据断路器） 当对文本字段进行聚合或排序时，将生成 Field data 数据结构。现场数据熔断器估计有多少数据将被加载到内存中。

当估计的数据占用内存达到现场数据熔断阈值时，现场数据熔断被触发熔断。此时可能的日志信息如下： 代码语言：javascript Copy org.elasticsearch.common.breaker.CircuitBreakingException: [fielddata] Data Too Large, data for [_id] will be [0/.2mb], 较大超过 [8/.7mb] 飞行中请求断路器的限制 飞行中请求断路器限制传输层和 HTTP 层所有当前传入请求使用的内存。

触发 In Flight request Breaker 时，可能的日志信息如下： 代码语言：javascript copy [o.e.x.m.e.l.LocalExporter] []索引监控 documentorg.elasticsearch.xpack.monitoring.exporter.ExportException: RemoteTransportException[[][ 时出现意外错误9.10。 .16:][索引:数据/写入/批量[s]]];嵌套：CircuitBreakingException[[in_flight_requests]数据太大，[]的数据将为[/18.1gb]，大于[/15.8gb]]的限制；优化建议：出现断路器表示当前节点JVM使用率过高，使用断路器保护进程OOM。

可以通过适当减少读写、清理内存等方式来降低节点负载，也可以通过升级节点内存规格来增加JVM大小。场景四：添加副本分片（REPLICA_ADDED） ES副本可以提高查询性能吞吐量，增加数据高可用性。

每增加一个副本，索引数据能够承受下线的节点数也会增加1，这说明副本分片对于ES来说有多么重要。但是，当我们添加副本时，集群将立即进入 YELLOW 状态。

这是因为ES集群状态是在分片层面决定的。换句话说，如果一个分片没有处于就绪状态，就会影响集群的健康状况。

这个时候我们只需要耐心等待即可。副本分片初始化完成后，集群将返回到 GREEN 状态。

建议：添加副本有一定的性能开销，建议在业务低峰时段进行。场景 5：快照恢复 (NEW_INDEX_RESTORED) 快照恢复是一个例外。

我们知道ES集群状态是在shard级别决定的。换句话说，如果某个分片没有处于就绪状态，就会影响集群的健康状况。

那么当ES发起快照恢复时，主分片一定不能处于就绪状态。但是，这不会导致集群变为红色，而只会导致集群变为黄色，直到拍摄快照为止。

数据恢复完成。建议：快照操作有一定的性能开销，建议在非高峰时段进行。

需要人工干预的场景一：磁盘水位问题（ALLOCATION_FAILED） 如果磁盘水位过高，ES新分片无法分配，更严重的甚至可能导致节点下线。集群中所有节点都达到磁盘低水位，导致副本分片不允许分配的磁盘被填满，导致节点永久离开。

这两种情况都会导致簇呈黄色。不同的是，如果只有单个节点的磁盘被填满并且该节点离线，则达到阈值。

之后，副本将被强制分配给其他节点（unassigned.node_left.delayed_timeout），但如果所有节点都达到磁盘低水位线，副本分片将不再被分配，直到人工干预：代码语言：javascript复制[o.e.c.r.a.] DiskThresholdMonitor] [ ] 在 [4s2ulawjTSSvt-QQlqsDPQ][][/data1/containers//es/data/nodes/0] 上超出低磁盘水位线 [85%] 空闲：70.1gb[14.2%]，副本将不会分配给本节点优化建议：订阅集群警报，及时发现集群水位，保持集群磁盘水位处于健康状态。制定 ILM（索引生命周期管理）策略，定期清理过期数据，以保持健康的水位。

场景二：节点永久离线（NODE_LEFT） 我们还假设集群中所有索引都有冗余副本分片，只有一个节点宕机离线。但是，由于某些原因，该节点将不会返回到集群中。

那么集群此时就会进入黄色状态。在没有人为干预的情况下，delayed_timeout达到阈值后会强制分配给其他节点。

当然，这也会降低ES的整体性能： 代码语言：javascript copy [o.e.c.r.a.AllocationService][]failed shard[failed shard, shard[. ds-cdwch-.11.13-04][23]，节点[vAnpreEnTaSWY-QYV3GGWg]，[R]，recovery_source[对等恢复]，s[初始化]，a[id=r48vj2pQRmauAuXKm-qX9g]，unassigned_info[[原因=NODE_LEFT ]，在[11-14T06：58：10.Z]，延迟= true，详细信息[node_left [vAnpreEnTaSWY-QYV3GGWg]]，allocation_status [no_attempt]]，消息[恢复失败]，失败[RecoveryFailedException [[.ds-cdwch] -.11.13-04][23]：从 {}{QUotMJ0DRsiMJPtqlMA}{2aWADQvMRjSKRRsFg-Abrw}{10.1.0.47}{10.1.0.47:}{hilrst}{ml.machine_memory=、rack=cvm_8_07、xpack.installed 恢复失败=true、set=07、transform.node=true、ip=9.15..、ml.max_open_jobs=、ml.max_jvm_size=、region=8} 到 {}{vAnpreEnTaSWY-QYV3GGWg}{-vaCwjbhSpG1iGEY18Wz4A}{10.0..45 }{10.0..45：}{hilrst}{ml.machine_memory=，rack=cvm_8_06，xpack.installed=true，set=06，transform.node=true，ip=9.15..46，ml.max_open_jobs=，ml.max_jvm_size=，区域=8}]；嵌套：RemoteTransportException[[][10.1.0.47:][内部：index/shard/recovery/start_recovery]];嵌套：ScpRecoveryIsRunningException[正在为同一副本和节点运行另一个恢复任务。现有恢复：RecoveryKey{shard: [.ds-cdwch-.11.13-04][23]，目标：vAnpreEnTaSWY-QYV3GGWg，recovery:21}，新恢复：RecoveryKey{shard: [.ds-cdwch-.11.13-04 ][23]，目标：vAnpreEnTaSWY-QYV3GGWg，恢复：26}]； ], markAsStale [true]]优化建议：节点一般不会无故离线。

如果偶尔有节点detach，需要进一步排查ES是否存在资源瓶颈？场景三：副本分片过多（ALLOCATION_FAILED） 对于同一个ES节点，无法分配同一个副本分片。这意味着索引的最大副本数（Replicas）=Date Node number - 1，当Replicas >= Date Node nums时，就会出现副本无法继续分配的情况。

为了避免这个问题，请遵循以下公式来确保每个索引的每个副本分片小于集群中的节点数： 代码语言：javascript 复制 N >= R + 1 其中 N 是 ES 中的节点数cluster，R 是索引的副本数 (num_of_replicas)。摘要 YELLOW 状态可能会降低集群的读写性能。

当然，除此之外，YELLOW对业务没有其他负面影响，但是有一点特别重要——任务进度。我们知道ES的任务调度是有优先级的，分配副本分片的优先级高于重定位。

也就是说，当集群处于黄色状态时，ES默认不会触发rebalance，这很可怕。 正是因为ES有分片再平衡机制，所以可以尽可能的实现负载均衡，充分发挥分布式计算的性能。

试想一下，当rebalance无法触发时，ES会是什么状态？我想大家很容易想到的是：热点瓶颈、负载不均、甚至读写拒绝。幸运的是，ES 在设计之初就想到了这一点，因此提供了动态参数进行调整： 代码语言：javascript 复制 PUT _cluster/settings{ "transient": { "cluster.routing.allocation.allow_rebalance": "indices_primaries_active " }}always - 任何情况下都可以触发重新平衡，包括集群 REDindices_primaries_active - 仅当主分片 Ready 时才可以触发重新平衡，包括集群 YELLOWindices_all_active - （默认）只有当所有分片都 Ready 时，即 cluster 才可以触发重新平衡绿色的。

我参加腾讯科技创意创作训练营第三期有奖征文比赛。