记一次线上ES异常

记一次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需要的时间也比较长（预估超过一天），遂放弃此方案（主要是近期会对es进行迁移，所以当前最紧要的还是保障这段时间集群能够提供服务）。 上面提到了实际我们的分片数是5，却只有3台机器在提供服务，查看发现果然有两台机器上都分配了2个shard，这时我想要是shard分布均匀后，那就有五台机器提供服务，cpu的占用应该可以降低一些。一开始准备想让es集群去自动平衡，所以把这两台机器暂时下线后重启（智商下线），等了一会发现分布还是不均匀的，尝试了几次后放弃es集群自动平衡，上网看了些博客后发现可以手动指定shard迁移

curl -XPOST 'http://localhost:9200/_cluster/reroute' -d '{
  "commands":[{
  "move":{
    "index":"indexName",
    "shard":3,
    "from_node":"nodeA",
    "to_node":"nodeB"
}}]}'

提示剩余磁盘空间低于80%，不允许迁移。 这时我想不准备我手动平衡，那我增加副本数总可以吧（副本数设置为1，那shard总数就是10，最终应该比现在的分布情况要好一点）,通过下面的命令设置shard副本数

curl -XPUT 'http://localhost:9200/indexName/_settings' -d '{
    "index": {
       "number_of_replicas": "1"
    }
}'

设置完成后索引的unassigned shard 中果然多了五个副本。本想等一会儿应该会被集群分配运行，但是等了十多分钟后，还是没动静。突然想到还是磁盘剩余空间不够的缘故。上网查询后果然如此。

curl -XPUT 'http://localhost:9200/_cluster/settings' -d '{
    "transient":{
       "cluster":{
          "routing":{
               "allocation.disk.watermark.high":"95%",
               "allocation.disk.watermark.low":"90%"
             }
           }
       } 
}'

cluster.routing.allocation.disk.watermark.low：Controls the low watermark for disk usage. It defaults to 85%, meaning that Elasticsearch will not allocate shards to nodes that have more than 85% disk used. It can also be set to an absolute byte value (like 500mb) to prevent Elasticsearch from allocating shards if less than the specified amount of space is available. This setting has no effect on the primary shards of newly-created indices or, specifically, any shards that have never previously been allocated. cluster.routing.allocation.disk.watermark.high：Controls the high watermark. It defaults to 90%, meaning that Elasticsearch will attempt to relocate shards away from a node whose disk usage is above 90%. It can also be set to an absolute byte value (similarly to the low watermark) to relocate shards away from a node if it has less than the specified amount of free space. This setting affects the allocation of all shards, whether previously allocated or not.

设置后果然五个副本上线了，并且手动迁移shard也不会提示磁盘空间不足了。(在此过程中减少了部分索引的分片数，为了节省磁盘空间) 到这里问题就差不多算是解决了，后续就是手动迁移shard到磁盘空间较充足的机器上。