接触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