elasticsearch集群生产问题处理总结

对于elasticsearch这款中间件，笔者是很感兴趣的，在工作中处理的es生产问题大大小小有500+了，涉及es集群升级、扩容、数据迁移、双活、异地多活、灾备、冷热架构、角色分离等，逐渐形成一些问题处理经验，本篇文章会结合一些案例，提供下常见es生产问题处理思路供大家参考(不包含问题详情和报错日志等生产敏感信息，请大家理解）

问题一：

同网段集群9台节点，经常随机出现某台节点离开集群的现象，节点重启后恢复正常。

处理过程：

查看日志，发现该节点在夯住前经常有长时间gc停顿，刚开始可能几秒，十几秒，后面达到一百多秒，超过es节点健康检测时长（93秒），主节点将该节点踢出集群，

节点为什么会夯住那么长的时间？堆内存不够了？需要扩容吗？查看监控排除了这些可能性，后面对健康检测时长进行了调整（305秒），仍然有这种情况发生，并且看到发生节点脱离的情况时，gc停顿已经有上千秒了，所以延长健康检测时长并不是解决办法，必须要找到gc停顿如此之长的原因。经过hot_threads查询，发现9个节点中同一时刻总有一个节点上显示pinyin tokenizer的线程占用cpu很高，并且发现一个规律，这个pinyin tokenizer在哪个节点上，下一次发生节点脱离的情况时就必然是这个节点。那说明就跟这个pinyin分词器有关了，经了解，该pinyin分词器是业务侧从github下载的后，经过改造之后安装的。而改造的内容就是更改了拼音多音字的功能（pinyin分词器默认值匹配多音字中的一个音，业务侧改成了匹配多个音，会导致大量循环，耗费cpu），最后改成原版的pinyin分词器后，集群恢复正常。

 

问题二：

集群各节点配置相同、部署服务相同，但出现某台节点cpu消耗高的情况。

处理过程：

首先通过top等查询排除了该节点其他进程导致CPU占用高的情况，继续检查发现该节点write线程池有任务拒绝的情况，同配置下的集群各节点只有这台出现写数据异常，

那是不是该节点的磁盘写入有问题呢？通过iostat –x –d –k 1发现瓶颈不在磁盘上。使用top –Hp pid，用jstack打一下es的线程dump，发现也没什么问题。

接着查看es索引，发现集群中有一个索引数据量较大，在es集群中索引是均衡分配的，但每个分片的数据不会完全相等的，只是大致相同。用_cat/shards查看该索引的分片分配详情，然后计算索引分片在各个节点的总容量，此时发现一个特点，各节点cpu占用和这个总容量强相关，也就是总容量大一点的cpu占用也会相应高一些，而出问题的那个节点，该索引的分片总容量最高。手动分配该索引分片，将一部分分片迁移到容量最少的那个节点上，集群节点恢复正常，没有写任务异常了。