大家都知道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
jmeter工具做性能测试压力发起经常遇到：
持续12小时或更长的稳定性测试过程中会碰到一些请求在某个时刻出现报错，这些报错一般为偶发、零星的几笔。遇到这些问题时，找开发工程师或者项目经理沟通时，他们第一反应就是问我们，报错返回内容是什么，我们答是找不到断言内容才报错（等于没说。。），可以告诉你们报错时刻或者时间段，你们去查下应用有没有异常日志出现。这个过程测试组就比较被动了，开发同事有时间的话可能会及时响应，即使响应了可能得到“没有查到相关异常日志”的答复；碰到开发工程师比较忙的，测试工程师等待时间过长，进而影响测试效率。
在测试过程中收集异常发生时的响应内容就显得非常必要。
本篇文章基于团队使用性能测试平台，先分析jmeter.log和响应断言，后提出轻量级jmeter日志可视化方案。
jmeter.log
熟悉性能测试工具jmeter的同学知道jmeter在运行时会生成一个jmeter.log日志文件，此文件生成的路径为执行jmeter运行测试开始命令所在的目录。一个jmeter.log文件在默认情况下会呈现如下内容：
a.运行一笔java请求,断言成功,查看jmeter.log
b.运行一笔java请求,断言失败,查看jmeter.log
经过对比，默认情况下在断言成功和失败（可以理解为请求成功和失败）情况下，jmeter.log内容没有任何不同，在断言失败时并不会追加错误信息到jmeter.log中去，因为这属于被压测业务的失败，并不是jmeter软件运行本身或者脚本内容的错误（eg:参数化文件找不到；beanshell异常）。
如果要在被压测业务失败时从jmeter.log文件中获取有价值的内容还得做一些处理，而判断压测业务失败在jmeter中是靠断言来实现的。
jmeter的断言
jmeter的断言目的大家已经很清楚了，此处不讲。jmeter的断言种类很多，如下图所示：
我们拿最常用的响应断言进行举例，先看看在jmeter GUI模式下断言失败时查看结果树监听器的内容展示：（本例中我的java请求成功响应内容是SUCCESS，目标断言内容是SUCCESS，为了呈现断言失败效果将断言内容改成了SUCCESS1）
图中我们可以看到在java请求sampler下级目录下有个响应断言，点击响应断言有三行内容：
Assertion error: false
Assertion failure: true
Assertion failure message: Test failed: text expected to contain /SUCCESS1/
在GUI模式下我们可以直接观察到以上信息，NON GUI模式下能不能获取到以上标记绿色的内容呢，经过分析
org.apache.jmeter.assertions.AssertionResult我们看到了如下三个方法：
确定有这三个方法，证明可以通过代码来获取断言是成功还是失败的状态，进而可以判断在断言失败时将此时的jmeter请求的响应内容获取到并通过log.error方法追加到jmeter.log中
代码判断断言状态实现日志过滤
import org.apache.jmeter.assertions.AssertionResult;
AssertionResult[] results = sampleResult.getAssertionResults() ;
for(int i =0 ; i<results.length;i++) {
//获取响应断言
AssertionResult result = results[i];
//判断断言是否失败：isFailure为true
if(result.isFailure().toString() == "true"){
//断言失败时获取请求的响应报文追加到jmeter.log中log.error(prev.getResponseDataAsString());
}
}
错误发生时响应内容追加至jmeter.log
模拟断言失败时抓取请求的响应内容（本例中java请求的响应内容是SUCCESS）到jmeter.log中，实现了ERROR日志追加。
轻量级日志可视化方案提出
Jmeter+Filebeat+Elasticsearch+Kibana实现轻量级日志可视化检索
Jmeter：sampler+响应断言+beanshell监听器 实现日志过滤追加（错误发生时取到请求的响应内容并追加到jmeter.log）
Filebeat：Beats组件之一，轻量处理日志源（应用到本例中的日志源就是jmeter.log）
Elasticsearch:ELK协议栈软件之一,Elasticsearch 是一个开源的分布式 RESTful 搜索和分析引擎,简单点就是接收filebeat的日志数据，供kibana搜索。
Kibana:ELK协议栈软件之一，日志可视化检索
前篇主要分析了jmeter.log文件特性以及提前做了日志过滤，力求打造一个通用模板（只需本例中beanshell监听器中的代码）后推广至整个团队使用。受限于环境问题，后续会以中篇、终篇介绍关于此套方案集成的测试、运行细节。
