如何保存JMeter的性能测试数据到ElasticSearch上，并且使用Kibana进行可视化分析

Posted 2020-08-22

前言

Jmeter是一款性能测试，压力测试的开源工具，被大量的测试人员拿来测试产品的性能，负载等等。 Jmeter除了强大的预置的各种插件，各种可视化图表工具以外，也有些固有的缺陷，例如：

• 我们往往只能在报告中分析同一个部署的性能，不方便进行纵向的比较，例如我们每个build都会跑一次性能测试，但是两个build之间性能有没有变差？这些只能我们拿到结果报告，然后自己用其他第三方工具来分析
• Jmeter的图表插件产生的报告不够灵活，一般是固定的几个维度，不能更灵活的进行分析

本文会尝试将JMeter的sample数据写入ElasticSearch，然后通过Kibana强大的搜索和可视化能力，进行各种维度的性能分析，帮助开发测试人员找出性能的瓶颈，监控系统性能的变化情况，给整个开发，测试和运维团队发布各种报告

问题

如何自动化的把性能测试的各种原始数据写入ElasticSearch

信息采集上这里有两种可行的方案，

• 一种让JMeter生成各种报告，然后在测试跑完之后，用自己写的结果分析脚本，把数据导入ElasticSearch，这种方式不影响JMeter的运行，但是不具有通用性／实时性，而且由于一般JMeter的各种报告并没有包含全面的性能信息，这些信息的缺失是致命的，没有原始信息，接下来的各种分析就是无源之水
• 另外一种，就是我们采用的，实时的采集JMeter的Sample的性能信息，在不影响JMeter本省性能的情况下，相对实时的把结果写入ElasticSearch。优点是信息比较完备，而且可以包含其他自定义参数，在跑长时间的负载测试的时候，可以实时的监控系统的性能

对于数据采集，技术上，我们采用了开发一个JMeter的Backend Listener插件，这个插件会处理JMeter的每个Sample的结果

与BackendListener有关的信息可以查看 http://jmeter.apache.org/api/org/apache/jmeter/visualizers/backend/BackendListenerClient.html

我们着重看看SampleResult包含的信息，基本上我们可以拿到：

• 请求的URL
• 请求的各种参数
  • Cookies
  • Headers
  • Paramters
• 响应的各种参数
  • Headers
  • Cookies
  • Body
  • Response Code
• JMeter相关信息
  • Sample Label

这些信息已经足够我们用来分析性能了，在具体采集上，我们也会看自己的需要，只保存感兴趣的参数，用来节省ElasticSearch的存储空间，例如只保存出错的响应的body

关于SampleResult，具体可以参见 https://jmeter.apache.org/api/org/apache/jmeter/samplers/SampleResult.html

对于保存采样结果，技术上也有几个选择：

• 通过ElasticSearch的RestClient
• 通过我们这里使用的TransportClient
• 通过ElasticSearch的NodeClient

三种方式性能是依次提高的，能实现的功能也是逐个增强的。因为我们只是保存数据，并没有ElasticSearch的管理的需求，但是对性能有很强的需求，所以我们选择了TransportClient， 关于三种连接方式的具体介绍，可以参见：

• RestClient　　     https://www.elastic.co/guide/en/elasticsearch/client/java-rest/current/index.html
• TransportClient   https://www.elastic.co/guide/en/elasticsearch/client/java-api/current/transport-client.html
• NodeClient         https://www.elastic.co/guide/en/elasticsearch/client/java-api/current/client.html

 

如何不影响JMeter本身的性能

JMeter本身就需要生成和管理多个Threads，所以一般情况下，并不建议JMeter 的Test Plan中，包含图形化的分析插件，或者尽量减少各种分析插件的使用。我们引入一个Backendlistener，当然也不希望影响JMeter的性能，或者尽量减少对JMeter本身的影响，我们的策略是：

　　采用异步的策略，每50个采样的结果，通过ElasticSearch bulk ingest的API，存入ElasticSearch，减少网络的开销。当然，这里的50是可以自己配置的，根据自己的机器性能、采样数据的大小和网络状况确定

　　可以定制化的数据保存策略，例如只保存感兴趣的采样信息

而JMeter本身的BackendListener也是异步的，JMeter的Load并不会等待结果的存储是否完成

当然，具体的性能影响，也需要严格的测试确定，这里我就不展开了，可能接下来会进行一些相关的测试

如何支持Jmeter的Controller／Server的部署方式

初步看下来，JMeter是把各个Server的Sample信息传给Controller处理的，所以呢，当JMeter部署规模比较大的时候，Controller的Sample信息处理会重一些，好在我们一般情况下，Controller上并不会有Load需要处理，所以也还好。。。但是对于插件的使用上，我接下来会部署几台JMeter的server确认下，是各个Server来处理SampleResult还是传回Controller，这个我会在更新中详细介绍，公司的网络，各种限制，还没有机会做这部分。

如何保存各种自定义的参数（除了Jmeter自己提供的参数之外），用于为将来提供更多分析的可能性

比如我们希望保存当前部署的产品的版本号，这个在比较各个不同版本的性能的时候，非常有用。我们在插件中，会把当前机器的以自定义的字符串开头的环境变量都存储到每条JMeter的记录中去。事后，用户就可以很灵活的使用这些自定义的参数来分析性能了（例如，地域代码，产品部署相关的各种参数）

 

由于时间的问题，今天先介绍下大概的情况，接下来我会更新

• 如何创建一个JMeter BackendListener，并且调用ElasticSearch的TransportClient保存SampleResult
• 如何使用Kibana／Kibana Timelion从各个维度分析性能结果
• 如何与Jenkins集成，创建完成一套性能测试的框架，让所有者一切对使用者都透明

接下来我会把相关的Code放到Github上，并把相关代码开源， 请关注后续的更新。