jmeter集羣下腳本日誌和報告處理

jmeter支持分佈式測試，在分佈式模式下，由一臺調度機調度全部的執行機（集羣節點），執行腳本時能夠自由的選擇單節點執行或者分發集羣中指定或所有的機器執行。在使用調度機客戶端分發腳本時，不管是在GUI模式仍是non-GUI模式，腳本日誌的收集及報告的生成都無任何問題，可是若是是使用jmeter SDK在代碼中調用客戶端大併發分發腳本到執行機執行，則會存在日誌沒法實時獲取的問題（超大jmx腳本執行時產生的超大日誌經過網絡傳輸須要時間）。

經過分析jmeter SDK的源代碼，發現日誌的收集是異步執行的，而在SDK中並未提供日誌收集完成的通知能力，致使根據日誌生成報告時常常出錯（實際的腳本都是正常執行完的）。分析上述問題，提供的解決方案以下：

• 腳本執行完後，當前線程睡眠必定時間

• 暴力反射嘗試得到日誌的傳輸狀態

• 修改jmeter SDK的源代碼，在其中增長監聽機制

• 當前線程只負責執行腳本到結束狀態，定時收集日誌並生成報告

針對以上的4種方案，分析其優缺點：

• 日誌大小沒法肯定，睡眠時間沒法肯定，並且睡眠會致使線程等待，可能會產生ThreadInterruptException

• jmeter SDK註釋寫的不好（基本無註釋），分析源代碼須要強大的技術能力和必定的時間，目前的時間排期不容許

• 一樣因爲註釋的緣由，也須要強大的技術能力和必定的時間，不過難度比第二種方式要低，也是能夠產生最優結果的解決方案

• 技術要求最低，實現容易，可是日誌和報告的生成會延遲（基於定時器的週期）

在當前產品的需求上，其實日誌和報告並非極其敏感和實時性要求高的數據，因此最終選擇第4種方案，代碼以下：

每一個十分鐘拉取距今14400秒（任務執行超時時間，可配置啓動參數）還未獲取日誌的任務並嘗試獲取日誌。

由於是異步的拉取日誌，因此在拉取日誌以前加載一次jmeter的配置。

考慮到每一次停機維護的時間可能會很長（超過當前設置的任務超時時間），所以還須要提供一個啓動應用時掃描任務的能力。

CommandLineRunner接口標識應用啓動完成時執行該接口的實現類，所以須要使用@Component將類的對象加入到IOC容器中。

日誌拉取完成後，再處理報告，一樣的原理每一個十分鐘拉取距今14400秒（任務執行超時時間，可配置啓動參數）還未獲取日誌的任務並嘗試根據日誌生成報告。

一樣由於是異步生成報告，所以須要在生成報告時，加載一次jmeter的配置管理。此處也要考慮停機維護的問題，使用CommandLineRunner。

到此，jmeter日誌和執行生成的問題完美解決，每一次執行完的任務可能會有10左右的延遲時間用來獲取日誌和報告。

▲上圖顯示任務執行時和執行成功後，日誌和報告正在生成中

做者：陳潔

其餘技術文章

企業應用運維自動化應該如何設計？

域內計算機本地管理員密碼管理

騰訊PaaS平臺 | 主機名設置錯誤怎麼辦？

Redis持久化介紹

4大步驟節省30%浪費，優化企業上雲成本從瞭解雲開始！