记一次ES日志系统的接入

近期接了一个新项目,某部门的日志要从HDFS迁移到ES中,每天15T,保留15天,每天有150亿条数据写入,这对于我们现有集群吞吐量是一个很大的挑战。

attachments-2020-11-Uiq4dhPi5fb4b988cdef4.png

0 - 前言

近期接了一个新项目,某部门的日志要从HDFS迁移到ES中,每天15T,保留15天,每天有150亿条数据写入,这对于我们现有集群吞吐量是一个很大的挑战。


1 - 现状

目前默认ES集群采用3 master、3 data的结构。数据节点服务器:

CPU: 24 核、Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
MEM:128G
Disk: Intel 4510 * 4 单盘挂载

默认集群可承载25w/s的请求,index速度可以达到120w/s,吞吐量最大可到25MB/s。如果每天有150亿的写入,QPS在20w左右,默认的集群配置可以接受,但是,问题出在了Logstash上。

我们的离线日志接入流程是:

Log file -> Flume -> Kafka -> Logstash -> ES

我们使用40 Cores Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz的机器来做Logstash节点(内存> 64G),发现消费速度仅为1w/s,仅是实际值的5%。

于是,我们调整Logstash配置,加大pipeline参数:

pipeline.workers: 40
pipeline.batch.size: 500
pipeline.batch.delay: 10

此时,写入量达到了2w/s,但还是不够。接下来,我们只好通过水平扩展Logstash节点来增加吞吐量,结果还是比较喜人的,机器数量和吞吐量呈线性增长。但是耗费的机器数量也是巨大的,常态需要10台左右,为防止业务激增,需要准备至少20台服务器。用这么多机器来做一个离线日志系统,显然不太合理。

于是,机器不够,人工来凑,我们开始对ES集群进行针对性优化。

  1. 日志数据允许丢失,我们关掉了副本,只保留主分片;
  2. 为了增加吞吐量,刷新间隔增加到了100s;
  3. 为了降低translog占用的资源,增大了缓存的日志大小、调整了刷新间隔和方法;

具体索引配置如下:

"index.refresh_interval":"100s",
"number_of_replicas": 0,
"translog.flush_threshold_size": "1024mb",
"translog.sync_interval": "100s",
"translog.durability": "async",
"merge.scheduler.max_thread_count": "1",
"merge.policy.max_merged_segment": "2gb"

经过一番折腾,耗费的服务器减少了一半,吞吐量增加了30%。


attachments-2020-11-Tj5hPa9u5fb4b99c8038f.jpg原文:https://www.jianshu.com/p/03512da5aa19?utm_campaign=hugo

  • 发表于 2020-11-18 14:04
  • 阅读 ( 15 )
  • 分类:操作系统

你可能感兴趣的文章

相关问题

0 条评论

请先 登录 后评论
阿梓
阿梓

965 篇文章

作家榜 »

  1. 阿梓 965 文章
  2. 吉洪叶 6 文章
  3. 百日慕晴 2 文章
  4. baiyang 2 文章
  5. li 1 文章
  6. yaya6x 1 文章
  7. 阿杰和飞机 1 文章
  8. 刘新超 1 文章