零.引言

我們對被測應用進行性能測試時，除了關注吞吐量、響應時間等應用自身的表現外，對應用運行所涉及的服務器資源的使用情況，也是非常重要的方面，通過實時監控，可以準確的把握不同測試場景下服務器資源消耗情況的變化，對于應用性能分析有著重要的作用，同時也是調整測試場景設計的重要依據。對于使用JMeter執行性能測試的朋友，可能大都知道jmeter-plugins中就有用于服務器資源監控的插件PerfMon Metrics Collector，同時也有不少同學會選擇類似nmon的獨立監控方案。

之所以決定寫這篇文章，一是因為在使用JMeter作為性能測試工具的情況下，使用專為其設計的插件會更方便，二是對于普通互聯網公司的性能測試方案，這款插件所提供的功能已經可以滿足其資源監控方面的大多數需求，而最重要的一點，是在技術群里發現雖然很多同學知道或者在用這款插件，但是對于一些概念和細節，并不了解，導致不能很好的滿足自己的需求，而現在網絡上介紹這款插件的博客文章，大都是Quick Start式的入門文章，并不能解答這些同學的疑問。
注：本文使用的JMeter版本為當前最新release版本3.2。

壹.基礎

本來PerfMon插件的安裝部署不是本文的重點，但為了保持文章的完整性，這里還是進行簡單的介紹。有基礎的同學可以跳過。

使用PerfMon進行服務器資源監控的方案由兩部分來實現

1. ServerAgent，部署在被測服務器，負責資源耗用數據的采集，其功能實現主要基于hyperic的SIGAR。
2. PerfMon Listener，以插件形式集成到JMeter，作為其中一個Listener。

1.1 ServerAgent部署

• 前提：ServerAgent運行需要jre1.4以上版本支持。
• 下載：從官方下載
• 部署：將下載的.zip放置到被測服務器，解壓后，直接運行startAgent.sh(Linux)/startAgent.bat(Windows)即可，與JMeter進行數據傳輸時使用簡單的文本協議，默認使用TCP協議，默認端口4444。當然，在Linux，我們通常將其放在后臺運行，比如用nohup。
• 驗證：為了保證測試過程的順暢，我們可以先行確認JMeter壓力機與被測服務器上部署的ServerAgent的通信是否正常。一個簡便的方法是在JMeter壓力機使用telnet像ServerAgent發送"test"，如telnet 192.168.18.10 4444，連通后，輸入test，正常情況下ServerAgent會輸出類似INFO 2017-07-29 23:10:52.430 [kg.apc.p] (): Yep, we received the 'test' command的日志。

可以在運行腳本時添加--tcp-port xxx來指定端口，如$ ./startAgent.sh --tcp-port 3450，需要注意的是此時JMeterPerfMon插件使用時也需要對綁定端口進行對應修改。更多信息可以參考下載頁的官方文檔。

1.2 PerfMon插件使用

• 安裝：JMeter3.0之后，有兩種方式安裝jmeter-plugins所包含的插件。
  • 第一種方式：到jmeter-plugins官網搜索PerfMon并下載，將得到的jar包放置于JMeter安裝目錄的lib/ext/路徑下，重啟JMeter，從Listener中選擇使用插件。
    
    圖1 插件下載
  • 第二種方式：使用Plugins Manager，不過由于國內眾所周知的原因，很多同學可能遇到網絡不通不能展示插件的問題，這里就不展開了，可參考我之前的文章：JMeter性能測試3.0時代之-全新JMeter插件管理
• 使用：如圖2所示，在Listener中選擇PerfMon插件，添加到測試計劃中，然后參考圖3進行配置，包括配置部署了ServerAgent的被測服務器的IP、ServerAgent使用的端口、要獲取和展示的資源項等。測試啟動后
  
  圖2 使用PerfMon插件
  
  
  圖3 配置
• 數據觀察和保存：在使用GUI模式進行調試時，測試啟動后，可以直接在對應窗口觀察到根據采集數據描繪的圖形。而要在使用NO GUI模式正式執行測試后，查看監控數據，可以在設計測試計劃時在圖3的Filename位置配置數據要保存的地址，它和保存JMeter測試主數據的方式一樣，需要注意的是不要和JMeter測試主數據保存到同一個文件。在測試執行完成后，再在插件界面載入這個文件，即可顯示監控數據的圖形展示。

貳.進階

從同事、技術群友們那里，我了解到有不少同學對于PerfMon插件展示的各個指標數據的含義，特別是單位并不是特別明確，所以先講一下這部分。另外對于數據曲線圖的展示，也有一些點值得說明。

2.1 指標

關于監控指標數據的疑惑，大多可以從PerfMon插件的Metric parameter設置界面找到答案。我們知道對于服務器如CPU、內存等每一個監控指標類型，都有多種數據從不同維度來體現資源使用情況，比如對于CPU，在Linux系統用top命令，就可以看idle、user、system等數據。

對于PerfMon插件，可以通過Metric parameter來設置某種資源具體要收集和展示的數據，只是它的入口并不是很醒目，如下圖4右上的紅色箭頭所指，需要雙擊輸入框后，點擊最后邊的按鈕打開，打開的界面如圖4中級紅色箭頭所指，雖然每種指標的具體配置項不同，但結構相同，都分為Primary Metrics、Additional Metrics等等，Primary是官方認為常用的，通常也是實際工作中更關心，更具有參考意義的指標項，Additional則是在一些特殊場景可能需要了解的指標項。

圖4 監控指標參數設置

這里先簡單說一下幾種主要的資源類型的指標項，對應的圖就不貼了，太占篇幅，影響閱讀：

1. CPU：
   • 對于各指標項，數值都是代表百分比，比如默認配置(combined)下在曲線圖中看到某個時間的數值是30，即代表此時總的cpu使用時間占比為30%。
   • 有兩點比較有用的地方值得說明：一是在Scope區域，可以通過Per Process選項來獲取指定進程的CPU使用情況，二是在CPU Cores區域，我們可以選擇監控指定的單個Core。
2. Memory：
   • 各指標項中，usedperc(默認)和freeperc兩項的數值代表與總內存的百分比，其余指標項的數值都是指內存大小，選中對應想，可以看到Metric Unit區域單位配置將變為可用，通常Mb會比較適合觀察。
   • 同樣，也可以選擇監控指定進程的數據
3. Disk I/O:
   • 各指標項中，queue(默認)的數值代表等待I/O隊列長度，reads、writes分別代表每秒處理的讀/寫次數，readbytes、writebytes顧名思義，代表每秒讀/寫的數據量，單位同樣在Metric Unit區域配置，通常Mb會比較適合觀察。

• 如果有掛載多個存儲設備，可以在Filesystem Filter區域指定要監控的設備。

剩下的，就不一一說明了，參考前面幾項，我覺得理解其他資源類型的配置應該沒有問題了，至于具體指標項的含義，首先用不到的可以暫時不去了解，如果想要了解，請善用搜索。

2.2 曲線圖

1. 使用策略：

   • 如果測試場景的測試執行時間較長，采集的監控數據量比較大，為了在GUI模式查看曲線圖時更方便、快捷，建議將各個監控指標項單獨使用一個PerfMon監聽器，從而配置不同的指標項數據存儲到不同的文件中，測試執行完畢后，載入數據和數據查看都會更快。
   • 如果預計數據量不會太大，可以以服務器為單位來劃分PerfMon監聽器。這樣可以方便的觀察到整個測試過程中，某臺服務器各項資源使用情況的變化趨勢
   • 對于分布式服務、為了方便觀察各個節點的負載分布、負載變化趨勢，可以考慮將同類型的節點放置到同一個PerfMon監聽器，以便對比觀察

2. 數值：

   • 當一個PerfMon監聽器中展示多種指標項的數據時，為了曲線圖的可觀察性，插件會自動進行優化，如圖5所示，我們看到在CPU項和內存項都有個x10，代表曲線圖中展示的數值是在采集到的真實數值上放大了10倍，目的是為了保證不同數據項在同一坐標系中展示時，各項都變化趨勢都能夠被觀察到。
     
     圖5 曲線圖

3. 曲線圖配置：

   • 插件界面的Rows標簽頁可以調整要在曲線圖中展示的指標項
   • Setting標簽頁中常用的有：
     • use relative times用于配置曲線圖x軸表示相對時間(測試開始時為0)還是實際系統時間。
     • Auto-zoom rows for best fit默認勾選，則會有上一節講數值時提到的展示數據自動放大的功能，取消勾選則全部展示采集的實際數值。
     • Limit number of points in row to xx points：勾選后可以設定曲線圖展示的采樣點數量，我們的測試報告會有不同的角色查看，其中一些角色可能不具備也不需要對監控數據的細節理解能力，此時我們提供的監控曲線圖應該是易讀的，如果按照實際的所有采樣點來渲染出曲線圖，可能會有很多偏離趨勢的噪點數據，這對于不了解的人來說可能會有很多疑惑，所以當我們有了分析結論，最后報告呈現的時候，可以考慮通過調整采樣點，來讓曲線圖更好的展示資源使用趨勢，消除其他不必要的信息。
       
       圖6 曲線圖配置
     • Force maximum Y axis value to xx，實際上我更多會選擇不勾選，不勾選的情況下，插件在描繪曲線圖的時候，會根據數值大小自動調整Y軸最大值，以達到更佳可讀性，如圖7和圖8，分別是不勾選，和勾選后設置最大值為100時的曲線圖效果，顯然圖7可以更容易的觀察到變化的細節。不過與上一項類似，可能在對外出具報告時，為了更少的解釋說明，可能需要某個指定的數值。
       
       圖7 不自定義Y軸
       
       
       圖8 自定義Y軸

2.3 自定義指標

1. EXEC
   • 在插件界面選擇指標類型時，可以看到一個EXEC選型，該選項允許我們在后面的Metric parameter中配置一個命令語句(該語句最終應該輸出單個數值)，測試執行時，ServerAgent將執行該命令，同時插件將接收ServerAgent捕獲的輸出數值。
   • 語法規則：EXEC所配置的語句需要按照一定的規則來填寫，先是給出命令的執行程序的位置，然后將具體的命令以及命令的參數作為，命令和命令參數都需要用冒號":"來隔開。比如/bin/sh:-c:free |grep Mem |awk '{pring $7}'
     • /bin/sh，代表命令的執行程序
     • -c，即/bin/sh的-c選型，有-c選型的情況下，將從后面的字符串按一定規則解析為命令和命令參數
     • 可以看到有用冒號分隔了執行程序/選型參數/命令語句
     • 對于windows，也類似，如C\:\Windows\System32\cmd.exe:/c:echo %RANDOM%
2. TAIL
   • 如同Linux的tail命令，讀取文件的最后一行，用在這里，需要文件每一行只包含一個單獨的數值。借助tail，我們可以通過自定義腳本監控任意指標，只需要腳本的輸出滿足要求即可。
   • 顯而易見，TAIL后面的參數就是配置要讀取的文件的地址，測試執行時，ServerAgent將根據配置讀取所在服務器的指定文件。

叁.總結

本文先簡單的講解了JMeter性能測試資源監控插件的部署，然后從現有指標、曲線圖和自定義指標三個方面講解了插件使用過程中比較使用的細節問題，希望通過本文，讓大家能靈活運用這款插件來快速實現自己的測試需求。