前阵子做了一次日志收集系统压测,我们的全链路日志收集系统采用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服务