elasticsearch运维踩坑

接触ES也小半年了,ES虽然使用方便,运维简单但是集群规模和数据量大的话运维也很头疼,这里梳理下这半年的运维经验。

磁盘坑

集群随着使用,数据会积累越来越多,磁盘消耗也会越来越大,此时为了保护某个磁盘被写满,需要给磁盘设置阈值,配置项为:

1
2
3
4
5
6
# 磁盘使用超过此值,将不再接受shard的均衡,只接受主shard的写入
cluster.routing.allocation.disk.watermark.low
# 磁盘使用超过此值,磁盘上的shard开始向其他磁盘迁移,释放磁盘空间
cluster.routing.allocation.disk.watermark.high
# 磁盘使用超过此值,节点将不再提供服务
cluster.routing.allocation.disk.watermark.flood_stage

配置项值的默认形式是百分比,也可以是绝对值。
如果集群进行了扩容,各个机器的磁盘大小不一,此时依然使用百分比的话对磁盘大机器就会造成存储空间浪费,将百分比改为绝对值可以充分使用各个不同大小的磁盘。

shard重新分配

集群中某个DataNode实例挂掉或者集群中某个磁盘的使用率达到上线,就需要对shard进行重新分配,有几个配置项可以对其调整,加快分配的速度,配置项为:

1
2
3
4
# 实例用来控制接收和分发shard的线程数
cluster.routing.allocation.node_concurrent_recoveries
# 控制从本地恢复主分片的线程数
cluster.routing.allocation.node_initial_primaries_recoveries

node_concurrent_recoveries不宜设置的太大,如果集群规模没有超过百台,设置为DataNode实例个数的一半即可。
node_initial_primaries_recoveries此值可根据机器配置进行设置即可。

重启坑

当集群实例宕机出现雪崩无法恢复时,需要重启集群进行恢复。但是由于ES重启之后需要加载所有索引的shard之后集群才可正常使用,而ES会自动对索引shard根据现有的集群状态对shard进行重分配,这个分配过程是比较耗时而且针对集群重启的场景是没有意义的,因为集群只是重启,shard并没有丢失。
所以在集群重启之时可以将cluster.routing.allocation.enable设置为none,等所有的DataNode实例启动之后再将其设置为all。

大查询

数据查询量大,会触发ES的内存保护机制进行熔断,可以增加单独的查询客户端,并增加客户端实例的内存。随后设置集群配置,配置项为:

1
2
3
4
5
6
# 
indices.breaker.total.limit
#
indices.breaker.fielddata.limit
#
indices.breaker.request.limit

排查问题工具

  • 集群状态发生变化
    • 使用命令ip:9200/_cluster/health?pretty查询集群状态,如果集群状态发生了变化,可以从中分析原因
  • 节点正常,但是集群状态不是green
    • 使用命令ip:9200/_cat/indices?v,此命令会返回所有索引的状态,找到非green的索引,然后具体分析。
  • 查询分片失败原因
    • 命令ip:9200/_cluster/allocation/explain
  • 查询索引分片状态
    • 命令ip:9200/_cat/shards/index_name?v
您的肯定,是我装逼的最大的动力!