ES集群节点性能不均引起的一次生产事故

ES集群节点性能不均引起的一次生产事故

背景

5月21日晚上6点再次收到es集群变了，查询变得很慢，已经严重影响到了线上请求响应，部分接口响应失败。近期已经出现多次进群变黄的现象

排查过程

1. 登录grafana上看机器负载，观察机器负载情况，如下图所示mig-es2这台机器的cpu使用率很高，整台机器的负载都很高。因为业务中用到了很多es中的agg请求，理论上是确实很耗费cpu的
2. 登录对应的机器上查看了es的慢查询日志，发现故障的这个时间段上有很多响应时间非常长的请求，响应有高达2分钟的，这样的请求足以把机器拖垮了，连续几条这么大规模的查询估计把实例干崩
   
3. 再登录cerebro看节点状态，发现是确实是mig-es2（部署了2个实例）这台机器上的一个实例挂掉了，导致分片丢失，集群变黄影响到正常的业务了！还有一个非常重要的现象就是，整个索引有3/1的分片都分布在mig-es2这台机器上，每次请求来了3/1的压力都打在这台机器上

问题定位

1、es的agg语句过于复杂，需要耗费大量的cpu资源
2、es分片不均匀，很多分片都集中分配在mig-es2机器上***
3、mig-es2和mig-es3是前段时间新加进去机器，两台机器均部署了2个es实例。这两台机器是老机器，虽然用上了ssd，但是cpu能力很弱并且部署2个实例，遇到了复杂的agg时根本应付不过来，导致超负荷了

解决方案

1、优化es的agg语句，禁止大规模数据agg，只允许小规模的复杂agg操作
2、利用cerebro手动重新分配分片，平衡机器负载压力***
3、mig-es2和mig-es3两台老机器各去掉一个实例，每台机器只部署一个实例
4、做一层根据机器性能来分配请求的负载均衡机制

结论

es节点的性能应该做到均衡点（注意木桶效应），避免个别节点太弱挂掉，导致整个es变黄影响了正常的服务

以上均为本人的记录，文中可能有对说得不对的地方，欢迎大佬们指出。