Docker系列——InfluxDB+Grafana+Jmeter效能監控平臺搭建（二）

溫一壺清酒發表於2021-04-09
DockerUXGrafanaJMeter

在上一篇博文中，主要是講了InfluxDB的配置，博文連結：https://www.cnblogs.com/hong-fithing/p/14453695.html，今天來分享下Jmeter的配置。

在介紹Jmeter之前，必須是要有Jmeter環境的，至於環境怎麼配，工具怎麼用，可以看以前的博文。環境搭建：Jmeter——環境搭建；Jmeter系列博文：Jmeter系列。所以這些就不多講了，可以自行檢視，今天以效能監控平臺配置為主，介紹Jmeter執行指令碼來採集對應資料。

Jmeter配置

新增監聽器

線上程組中，新增監聽器（Listener）-> Backend Listener，如下圖所示：

配置Backend Listener監聽方式

新增監聽後，監聽方式預設為GraphiteBackendListenerClient，如下圖所示：

監聽方式是可以修改的，監聽器沒擴充套件的情況下，共有2種，擴充套件後，支援四種方式，如下所示：

我已經擴充套件過了，所以展示4種，具體擴充套件方式，稍後再說。今天介紹主要以前三種監聽方式為主，三種方式採集的資料，也有些許不同，我們詳細來看。

GraphiteBackendListenerClient監聽

介面配置

配置監聽方式為GraphiteBackendListenerClient，不同的監聽方式，配置皮膚上的配置欄位也有不同之處，配置如下所示：

配置介面的詳細欄位如下：

  • graphiteHost：InfluxDB安裝的伺服器ip
  • graphitePort：埠；預設就是2003。ps：除非你自己安裝InfluxDB時設定了其他埠。按自己的實際埠配置即可
  • rootMetricsPrefix：指標的根字首；將測試結果存入資料庫時，不同指標會生成不同表
  • summaryOnly：當你執行緒組有多個請求又想知道每個請求的結果資料時，最好填false，因為true只會返回所有請求的集合資料包告，不會輸出每條請求的資料包告
  • samplersList：取樣器列表；想收集哪些請求就填哪些，最好用正則去匹配
  • useRegexpForSamplersList：是否使用正則；如果true則使用，samplersList裡可以匹配正規表示式
  • percentiles：百分比；即類似聚合報告裡90% Line，95% Line，99% Line的資料；倘若想要99.9時，需要寫成【99_9】，用下劃線代替點

執行指令碼

執行指令碼，執行沒報錯，便會產生資料了，可以通過伺服器客戶端檢視，或者上篇博文中介紹的客戶端工具查詢。查詢資料如下所示：

通過查詢資料發現，總共會生成三種字首的表，分別是：jmeter.請求名稱、jmeter.all、jmeter.test。通過資料可以看到，請求資料都是整齊劃一的以jmeter.開頭，是因為我們剛才配置的時候，設定的是jmeter.；如果你配置成其他，那就會以自定義的字首生成資料了。

  • 字首說明

jmeter.all ：代表了所有請求；當summaryOnly=true時，就只有samplerName=all的表了

jmeter.請求名稱 ：如圖所示，HTTP請求的名字是HTTP Request 溫一壺清酒 appium

jmeter.test ：執行緒組設定相關的指標資料

引數指標

引數指標說明，在jmeter官網有介紹，地址是：https://jmeter.apache.org/usermanual/realtime-results.html，可以檢視原文件。我在這裡就按中文來說明了。

執行緒/虛擬使用者指標

Thread/Virtual Users metrics - 執行緒/虛擬使用者指標

執行完指令碼，生成的資料中，是有對應的5個指標資料的，如下所示：

指標 全稱 含義
<rootMetricsPrefix>test.minAT Min active threads 最小活躍執行緒數
<rootMetricsPrefix>test.maxAT Max active threads 最大活躍執行緒數
<rootMetricsPrefix>test.meanAT Mean active threads 平均活躍執行緒數
<rootMetricsPrefix>test.startedT Started threads 啟動執行緒數
<rootMetricsPrefix>test.endedT Finished threads 結束執行緒數

響應時間指標

Response times metrics - 響應時間指標

每個sampler都包含了所有響應時間指標，每個sampler的每個指標都會有單獨的一個表儲存結果資料

指標 含義
<rootMetricsPrefix><samplerName>.ok.count sampler的成功響應數
<rootMetricsPrefix><samplerName>.h.count 伺服器每秒命中次數(每秒點選數，即TPS）
<rootMetricsPrefix><samplerName>.ok.min sampler響應成功的最短響應時間
<rootMetricsPrefix><samplerName>.ok.max sampler響應成功的最長響應時間
<rootMetricsPrefix><samplerName>.ok.avg sampler響應成功的平均響應時間
<rootMetricsPrefix><samplerName>.ok.pct<percentileValue> sampler響應成功的所佔百分比
<rootMetricsPrefix><samplerName>.ko.count sampler的失敗響應數
<rootMetricsPrefix><samplerName>.ko.min sampler響應失敗的最短響應時間
<rootMetricsPrefix><samplerName>.ko.max sampler響應失敗的最長響應時間
<rootMetricsPrefix><samplerName>.ko.avg sampler響應失敗的平均響應時間
<rootMetricsPrefix><samplerName>.ko.pct<percentileValue> sampler響應失敗的所佔百分比
<rootMetricsPrefix><samplerName>.a.count sampler響應數(ok.count+ko.count)
<rootMetricsPrefix><samplerName>.sb.bytes 已傳送位元組
<rootMetricsPrefix><samplerName>.rb.bytes 已接收位元組
<rootMetricsPrefix><samplerName>.a.min sampler響應的最短響應時間 (ok.count和ko.count的最小值)
<rootMetricsPrefix><samplerName>.a.max sampler響應的最長響應時間 (ok.count和ko.count的最大值)
<rootMetricsPrefix><samplerName>.a.avg sampler響應的平均響應時間 (ok.count和ko.count的平均值)
<rootMetricsPrefix><samplerName>.a.pct<percentileValue> sampler響應的百分比（根據成功和失敗的總數來計算）

InfluxDBBackendListenerClient監聽

介面配置

配置方式一樣，只是選擇不同的監聽方式而已，直接上圖，配置也如下圖所示：

每個配置項的含義如下：

  • influxdbUrl：安裝influxdb的路徑；主要格式：http://主機地址:8086/write?db=資料庫名
  • application：應用名稱；在 events 表中對應的欄位是 application
  • measurement：表名；資料儲存到哪個表，預設是jmeter，不用改即可
  • summaryOnly：當你執行緒組有多個請求又想知道每個請求的結果資料時，最好填false，因為true只會返回所有請求的集合資料包告，不會輸出每條請求的資料包告
  • samplersRegex：取樣器列表；想收集哪些請求就填哪些，最好用正則去匹配
  • percentiles：百分比；即類似聚合報告裡90% Line，95% Line，99% Line的資料；倘若想要99.9時，需要寫成【99_9】，用下劃線代替點
  • testTitle：測試名稱；在 events 表中對應的欄位是 text ，JMeter在測試的開始和結束時自動生成註釋，該註釋的值以'started'和'ended'結尾
  • eventTags：Grafana允許為每個註釋顯示標籤；在 events 表中對應的欄位是 tags

執行指令碼

我們還是用客戶端工具檢視，這次只生成了2張表，分別是：events 和 jmeter。如下所示：

表作用

events表：用於儲存事件的

jmeter表：儲存測試結果資料，Grafana也是從這個表獲取資料再展示

在講配置項含義解釋時，application和testTitle對應資料表中對應的欄位，我們查詢events表資料，如下所示：

application預設為jmeter；testTitle對應的是text，落的資料值為Test name started/Test name ended，Test name就是我們在介面配置的名稱；time欄位的時間差，就是指令碼的執行時間了。

jmeter皮膚中也看出的確只執行了1s，如下所示：

JmeterInfluxDBBackendListenerClient監聽

這種方式是在查詢Grafana監控模板時找到的，這次博文先不講Grafana的監控指標的配置，先把指令碼監聽方式講完。

Grafana官網介紹如下：

外掛引用

下載外掛

外掛下載地址，下載對應的jar包即可。

jmeter配置

將下載的外掛放到Jmeter的/lib/ext目錄下，如果jmeter是啟用的，則需要重新啟動下才能生效；jmeter沒啟用的情況下，則不需要。

介面配置

配置方式一樣，只是選擇不同的監聽方式而已，引入外掛後，就多了兩種監聽方式，我們選擇JmeterInfluxDBBackendListenerClient，配置如下圖所示：

每個配置項的含義如下：

  • testName：測試名稱；在 testStartEnd 表中對應的欄位是 testName
  • nodeName：節點名稱；在 testStartEnd 表中對應的欄位是 nodeName
  • influxDBHost：InfluxDB安裝的伺服器ip
  • influxDBPort：埠；influxDB埠，預設是8086，不用改即可
  • influxDBUser：資料庫使用者名稱
  • influxDBPassword：資料庫密碼
  • influxDBDatabase：資料庫名稱，我們之前配置的資料庫是jmeter，所以填入即可
  • retentionPolicy ：預設即可
  • samplersList：取樣器列表；想收集哪些請求就填哪些，最好用正則去匹配
  • useRegexForSamplerList：是否使用正則；如果true則使用，samplersList裡可以匹配正規表示式

執行指令碼

按自己所需配置完成後，執行指令碼，我們通過客戶端檢視資料，生成如下三張表：

requestsRaw表

主要是儲存請求資訊資料，包含：請求時間，請求名稱，執行緒名稱等資訊。如下所示：

testStartEnd表

主要是用於儲存事件資訊，如下所示：

virtualUsers表

儲存執行緒相關資訊，如下所示：

指令碼生成資料的方式，就介紹到這了，離最終效果圖只差一步了喲。今天介紹了三種方式，配置Grafana監控皮膚時，也對應有三種模板，下期再來細說。

相關文章