elasticsearch高负载问题场景分析

1.磁盘文件系统只读

问题原因：磁盘文件系统只读是机器本身 Linux的文件系统触发了只读。

解决办法：在CVM中使用fsck命令修复文件系统，解除只读状态。

触发背景：集群长时间大量写入的情况下会小概率发生。

表现形式：集群健康状态非绿。写入速度突然下降。

注：磁盘文件系统只读非es集群只读和索引只读。切勿混淆。

2. 节点频繁离线

集群内节点负载过高，频繁脱离集群，引起健康状态变化，节点分片未分配，影响集群业务。

表现形式：日志中有明显的node-left日志。 监控中部分节点资源使用率过高。例如：CPU使用率过高，节点load长时间打满。JVM堆内存使用率过高，集群熔断。

解决办法：

① CPU使用过高，load持续打满情况

需要结合机架监控，集群监控，分析集群当前业务的实际情况与与集群状态，索引分片配置等。可以使用GET _tasksAPI来确认一下集群当前主要的任务。进而明确导致CPU使用率过高的原因。然后引导用户进行节点规格升级等操作。

② JVM堆内存使用率过高情况

Case1：检查集群分片数，对应集群规格，判断一下当前集群是否能够承载现有分片。如果无法承载，需要引导用户进行分片删除降低负载与数据节点规格升级。后续引导用户合理规划分片使用。

Case2：结合集群日志与机架监控，确认集群熔断的具体原因。如果是读写引起的熔断。可以先尝试开启部分堆外内存空间，看看是否可以缓解，内存压力。结合实际情况暂停短时间的业务访问，让集群恢复。根据集群实际状况，来排查是否需要升配与扩容。

3.节点失联

表现形式：该类问题常见于1C2G，2C2G等低配节点。监控页面显示节点失联，后端cerebro无法登录等。

触发背景：配置过低，会使es服务以及操作系统不稳定，容易导致操作系统hung死，造成集群起不来。

解决办法：需要重启CVM实例，强制释放资源。然后及时升级集群。

4.客户端请求超时

表现形式：用户客户端报请求超时，kibana请求es报500错误等形式。

参考日志：Java客户端报30,000 milliseconds timeout on connection http-outgoing-0 [ACTIVE]，connected time out等信息。

问题原因：节点负载过高，无法响应部分客户端对于es的请求。造成其他客户端请求es超时。

解决办法：

连接池的连接有已经关闭掉的连接，请求时从连接池里拿到了一条被关闭的连接，请求就会超时了；通过对连接池里的连接进行定期健康检查，探活；或者是说，连接池的连接需要定期换新，主动关闭掉长时间idle的连接。这个连接长时间是空闲的，vpc gateway会主动断掉这条连接，不会持续保持着客户端一般会维护一个http连接池，连接池里的连接都是keep alive的；客户端是指的用户自己程序，ES集群只是服务端这个时间一般不超过2个小时，连接就不会被vpc gateway断掉，为了保险起见，可以设置的短一些； 客户端代码控制http连接池的空闲连接的有效时间，VPC的gateway 会根据客户端中的这是对符合条件的连接进行释放；请求量不大的话，改用短连接也行；不用连接池，就没有这个问题；

然后在根据具体情况，结合日志与监控分析，确认超时原因。

我正在参与2023腾讯技术创作特训营第三期有奖征文，组队打卡瓜分大奖！