记一次ES线上异常解决过程
周六线上es报警es not green，由于没有带笔记本回家并且考虑到集群容量本身就很紧张以及最近的读写压力确实很大（并没有多余的机器可以加入集群），觉得应该不会是什么大问题，就没有太多在意。周末去上班打开电脑一看，出事情了，线上依赖es的服务全部挂了，幸好不是实时服务不然就出大事了。
尝试重启es集群，部分服务恢复正常，但是好景不长，几分钟后es集群又挂了。感觉是线上服务读写qps太高，es集群的压力过大。所以决定先将服务暂停等es重启后再依次启动服务。这次重启es后很正常（集群健康值依然是yellow，并且unassigned的分片数很多，当时以为是初始化需要时间就没有管），等了几分钟es没有出现问题。
开始依次重启服务，但是当第一个服务启动后，观察了下es集群个节点的cpu使用率，发现10个节点中只有3个节点cpu占用较高（>80%）, 其他节点的cpu使用率接近0。因为集群中的索引数量较多，这样必然导致这个3个节点上的其他索引分片查询rejected率很高。通过监控面板发现原因是此索引的分片数太少并且没有副本数为0（机器为10 ，shard 为5）。第一个反应是增加此索引的分片数，网上查询后发现es并不支持动态扩展shard size，推荐的做法是新建索引然后reindex。考虑到这个索引比较大（2个T左右），使用 curl -XGET http://localhost:9200/_cat/allocation?v 命令查看集群剩余磁盘空间，果然不到20%了。贸然reindex可能会影响集群运行，并且考虑到reindex需要的时间也比较长（
