如何保存JMeter的性能測試數據到ElasticSearch上，而且使用Kibana進行可視化分析（1）

前言

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上，並把相關代碼開源， 請關注後續的更新。