filebeat+kafka+logstash+elasticsearch全链路日志收集系统压测分享

前阵子做了一次日志收集系统压测,我们的全链路日志收集系统采用filebeat+kafka+logstash+elasticsearch,今天主要分享原始日志入库ES的压测经验,并不涉及storm的实时日志处理。压测目标是120万条日志/分钟,压测团队由本人、自动压测同事、SRE、众多PO、领导组成。压测的目标是明确的,却不太好下手。经过优化后,大概摸索出了方案。真是团队协作才完成,手上排满了别的活,这个压测算是挤进来的。很多操作都是同事在帮忙操作。无论如何,也算是出了一个压测报告,与持续优化的经验。

初始压测环境

1.yue.ma    ES-9100-9200-9300
2.yue.ma    logstash-  zookerper-2182 storm  ui-8080  nimbus-16627
3.yue.ma    kafka-9092   redis-63705
4.yue.ma    mysql5.7-3306
5.yue.ma    iis、filebeat、LogGenerator服务、WebGenerator站点
6.yue.ma    iis、filebeat、LogGenerator服务、WebGenerator站点
7.yue.ma    压测客户端
8.yue.ma    压测客户端

以上机器均为8核16G内存,[1-8].yue.ma为脱敏host,仅做示例

压测优化思路

依据120万条日志/分钟的要求,我们通过ES查看工具,配合自己写的ES入库速率实时分析显示工具,实时观察入库速度,未达到要求,就分析,调整,直到满足目标。

日志生成

我们采用了服务生成日志、站点生成日志两种不同的方式,分别代别了实时业务中的场景。LogGenerator服务生成服务类日志,WebGenerator站点生成站点日志,站点的日志生成需要压测机器发起大量的请求​。有同事基于jmeter做好了压测工具​。​

优化后的压测环境

1.yue.ma    ES-9100-9200-9300  logstash- 
2.yue.ma    logstash-  zookerper-2182 storm  ui-8080  nimbus-16627
3.yue.ma    kafka-9092   redis-63705
4.yue.ma    mysql5.7-3306 logstash- 
5.yue.ma    iis、filebeat、LogGenerator服务、WebGenerator站点
6.yue.ma    iis、filebeat、LogGenerator服务、WebGenerator站点
7.yue.ma    压测客户端
8.yue.ma    压测客户端

实时优化措施

优化操作 优化来源 未优化前 执行 优化后
logstash节点增加到2个 实时观察 kafkak中可以查看到logstash消费存在堆积
查看命令:
./kafka-consumer-groups.sh –bootstrap-server 3.yue.ma:9092 –describe –group  sss
SRE执行 有所缓解
调整kafka的topic的partion数量 实时观察 每个topic只有一个partion,仅能被一个logstash consumer线程消费。这个时候有2个logstash,因此每个topic的partion数量配置为2
通过./kafka-consumer-groups.sh –bootstrap-server 3.yue.ma:9092 –describe –group  sss可查看到消费者情况
通过图形化工具http://10.14.71.5:9000/调整kafka每个topic的partion .此kafka工具由SRE安装 单个topic可以被多个logstash consumer线程消费
调整logstash consumer线程数量 实时观察 发现有的logstash服务器未工作,有的服务器全抢占了partion
通过./kafka-consumer-groups.sh –bootstrap-server 3.yue.ma:9092 –describe –group  sss可查看到消费者情况
SRE调整logstash配置,将原来5个线程调整为2个线程 每个logstash服务器都参与进来
1.logstash节点增加到3个
2.调整kafka中topic的partion数量为3
3.Logstash的Consumer线程数保持为2,因为只有2个topic
实时观察 发现有服务器上的LogStash在处理Common日志上还是不够快,能查看到kafka日志堆积
通过./kafka-consumer-groups.sh –bootstrap-server 3.yue.ma:9092 –describe –group  sss可查看到消费者情况
SRE执行 3个logstash服务器同时工作

历史经验

优化LogStash批量写
调整ES模板

没有设计任何场景与验证,直接向同事打听到去年压测的经验。

压测结论

短日志场景 单条日志长度22个字符
入库ES峰值 140万条日志/分钟
长日志场景 单条日志长度7143个字符
入库ES峰值 40万条日志/分钟
瓶颈分析 1.kafka中显示logstash消息正常无积压
2.网络为1.5 Gbps , 250MB/s,到达网络瓶颈
进一步优化方案 可增加kakfa节点,预计需要新增加2个节点,才能达到120万/分钟日志入库ES要求

测压解读,我们压到40万长日志/分钟的时候,就停止了进一步压测。依据长短日志的压测优化经验,日志系统的吞吐量可以通过调整kafka、logstash、ES的节点数来适应目标容量要求。Kafka的节点数大概为每分钟日志量的大小除以每分钟带宽满载的传输量,Logstash的数量可以观察消费堆积情况,增加数量。本次压测的经验是将kafka中topic的partion数量配置为logstash消费线程数,这样子,每个logstash都能保持工作状态。然后,每种topic的日志量占比不尽相同,可以在实战中进一步优化配置。ES侧的优化未进行,依据这次优化的经验,同样可从日志传输量与带宽角度,推测出ES节点数要求。有一个合理的初始配置,再在初始配置的基础上进行优化。

干货

kafka的图形管理工具,是开源WEB管理工具

ES入库速率实时分析显示工具,这个工具是DIY的,能实时显示当前入库到ES的日志速度,感兴趣的可以留言索取。

本次压测收集到的命令集合,感兴趣的可以留言索取

LogGenerator服务,感兴趣的可以留言索取

WebGenerator站点,感兴趣的可以留言索取

此条目发表在未分类分类目录。将固定链接加入收藏夹。

发表评论

电子邮件地址不会被公开。 必填项已用*标注