bulk写es超时问题

 阅读约 5 分钟

背景

笔者维护的线上EFK集群,在每天早上8点创建新索引的时候,日志中总会出现如下的日志:

failed to process cluster event (cluster_update_settings) within 30s
[2019-04-13T08:00:38,213][DEBUG][o.e.a.b.TransportShardBulkAction] [logstash-felice-query-2019.04.13][2] failed to execute bulk item (index) BulkShardRequest [[logstash-felice-query-2019.04.13][2]] containing [7] requests
org.elasticsearch.cluster.metadata.ProcessClusterEventTimeoutException: failed to process cluster event (put-mapping) within 30s
        at org.elasticsearch.cluster.service.MasterService$Batcher.lambda$onTimeout$0(MasterService.java:124) ~[elasticsearch-6.3.0.jar:6.3.0]
        at java.util.ArrayList.forEach(ArrayList.java:1257) ~[?:1.8.0_152]
        at org.elasticsearch.cluster.service.MasterService$Batcher.lambda$onTimeout$1(MasterService.java:123) ~[elasticsearch-6.3.0.jar:6.3.0]
        at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:625) ~[elasticsearch-6.3.0.jar:6.3.0]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_152]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_152]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_152]

问题原因

简言之:es的master处理不过来了,es的segment合并是一个非常耗时的操作。
批量处理的超时时间默认设置为30s。
可以通过以下命令查看pending的task:

curl 'localhost:9200/_cat/pending_tasks?v'

网上说法不一,出现这个问题很可能的原因可以总结如下:

  1. 分片数过多;单节点的分片数不要超过1000个(经验值);
  2. 通过写入数据自动创建索引最容易出现这种情况;
  3. 大批量写入数据refresh时间间隔太短;
  4. 索引的字段数量太多(几十上百个)

解决方案

方案一:每天预创建索引

虽然普通的EFK日志服务可以通过logstash的默认模板去创建索引,但是当索引个数比较大,并且索引的字段数量太多时,就非常容易出现超时。那么我们一般的做法是提前创建好索引,并且设定好每个索引的mapping。
笔者采用了一种偷懒的操作,写了一个定时任务,每天去读取当天的索引的mapping,然后直接用这个mapping去创建新的索引。当然这种解决方案的前提是你自己已经对索引有了一个基本的管理。

方案二:减少每个节点的分片数

es默认为每个索引设置的分片数是5。可以通过以下命令查看索引的settings:

GET /logstash-sonofelice-2019.04.27

可以在创建索引的时候,优化一下分片的个数。可以参考文章:https://www.cnblogs.com/gugul...
一句话:shard越少越好。shard越少,越能减少写入开销。

方案三:集群扩容

如果是偶发性的写入超时,可能是流量高峰或者新创建索引的时候创建mapping新字段导致。
但是如果经常性的出现超时,并且write_queue里面的数据太多,cpu使用率居高不下,那可能就是es集群出现了瓶颈,这时候就需要进行扩容,没有更好的办法。

参考资料

https://github.com/elastic/el...

阅读 2.4k发布于 2019-04-30

推荐阅读
分布式日志服务
用户专栏

分布式服务的架构以及维护经验

3 人关注
8 篇文章
专栏主页
目录