Jmeter BeanShell Listener+Filebeat+ElasticSearch+Kibana日志轻量级可视化方案（前篇）

前提条件

大家都知道jmeter官方是不建议使用GUI模式进行压测的，因打开查看结果树监听器去获取响应结果会消耗更多肉机的内存和CPU（View Results Tree MUST NOT BE USED during load test as it consumes a lot of resources (memory and CPU). Use it only for either functional testing or during Test Plan debugging and Validation.），这也是本篇文章的前提条件–use NON GUI Mode

性能测试情景

非gui模式下，不能通过查看结果树过滤出失败的内容进行展示并查看。持续12小时或更长的稳定性测试过程中会碰到一些请求在某个时刻出现报错，这些报错一般为偶发、零星的几笔。遇到这些问题时，找开发工程师或者项目经理沟通时，他们第一反应就是问我们，报错返回内容是什么，我们答是找不到断言内容才报错（等于没说。。），可以告诉你们报错时刻或者时间段，你们去查下应用有没有异常日志出现。这个过程测试组就比较被动了，开发同事有时间的话可能会及时响应，即使响应了可能得到“没有查到相关异常日志”的答复；碰到开发工程师比较忙的，测试工程师等待时间过长，进而影响测试效率。在测试过程中收集异常发生时的响应内容就显得非常必要。
本篇文章基于团队使用性能测试平台，先分析jmeter.log和响应断言，后提出轻量级jmeter日志可视化方案。

jmeter.log文件

熟悉性能测试工具jmeter的同学知道jmeter在运行时会生成一个jmeter.log日志文件，此文件生成的路径为执行jmeter运行测试开始命令所在的目录。一个jmeter.log文件在默认情况下会呈现如下内容：

1. 运行一笔java请求,断言成功,查看jmeter.log
   
2. 运行一笔java请求,断言失败,查看jmeter.log