浅谈某运维平台ES优化之路

你好，我是本站的小编小本本。近期在运维平台的工作中，我们遇到了ES集群压力不断增大的问题。通过不断的优化，最终我们成功的减轻了集群的压力。下面我来跟大家分享一下优化ES时采取的方案。

浅谈某运维平台ES优化之路

优化方案1：索引分片数优化

首先，我们对ES集群的整体情况进行了分析。集群共有24个节点，包括6个master节点和18个data节点，数据量高达11.9TB。但是，索引数达到了12817，分片数量达到了53617，这显然超出了官方建议的范围。

接着，我们根据索引设置是否合理的标准，以索引domp_10000_zhuji-messages为例进行了分析。我们发现，该索引分片数为1，副本数为1，而且数据量最大不过10M。一般日志类的索引一个分片可以承载30G左右的数据。因此，domp_10000_zhuji-messages这样数据量小的索引完全没有必要做成日索引。

通过与应用沟通了解，我们得知索引domp_10000_zhuji-messages需要保留周期是90天。如果我们将该索引改造为月度索引，单个索引数据量预估在300M左右，一个分片就足够使用了。在保留周期内，我们只需要6个分片就可以满足要求。应用到整个集群上，索引数和分片数量将大幅度减少，从而减轻ES集群的压力。

优化方案2：减少监控采集频率

我们发现ES监控索引数据写入被拒绝，监控这块的写入比较大。查看监控索引大小，在某些情况下居然能超过40G，这对于ES集群来说压力非常大。

ES默认的采集频率为10秒。因此，我们将采集频率调整为60秒，减少监控对ES集群产生的压力。可以通过如下命令实现：

curl -uelastic:elastic -HContent-Type:application/json -XPUT http://XXX.XXX.XXX.101:9206/_cluster/settings -d{"persistent":{"xpack.monitoring.collection.interval":"60s"}}

需要注意的是，在ES7.0版本之后，需要在kibana.yml配置文件中加入xpack.monitoring.min_interval_seconds参数，并与ES集群配置的采集频率相同。加了参数之后别忘了重启kibana。

如果仍然存在压力过大的情况，我们可以放弃对索引的监控，仅收集集群元数据。调整参数xpack.monitoring.collection.indices”:”.*”，指定监控的索引。默认情况下是监控所有的索引。

查询优化

在集群压力如此之大的情况下，我们需要考虑当时在跑什么查询。通过查看慢查询日志，我们可以了解当时的查询情况。例如，以下查询使用了ES中的in查询，in中id数量远超过了1024：

SELECT * FROM my_index WHERE my_id IN ('1', '2', '3', ..., '2000')

而ES默认情况下，参数indices.query.bool.max_clause_count的值为1024。如果查询远超过此限制，将会占用大量的CPU和内存资源。因此，我们采用循环查询的方式，一次取100个id的数据，经过测试后发现，查询总耗时与原方法无较大差别，但是资源消耗却大大减少。

对于大索引的查询，我们之前是使用from-size，但在此情况下，使用size较大的查询可能对集群造成很大的压力。相比之下，scroll查询能大大降低集群的负载。scroll查询可以模拟传统数据的游标，记录当前读取的文档信息位置，从而实现数据的分页。相对于from-size的分页，scroll查询的压力更小。

以上就是我们优化ES集群的方案，经过不断的尝试和实践，我们成功的减轻了ES集群的压力。希望这篇文章能为那些在优化ES过程中遇到问题的同学提供一些参考和启示。

原创文章，作者：小编小本本，如若转载，请注明出处：https://www.benjiyun.com/yunzhujiyunwei/vps-yunwei/6372.html