サーバーリソース監視プログラムのためのパフォーマンスモニタを使用して、2つの部分から構成され
ServerAgentは、リソース消費データの収集を担当し、テストサーバーに配備され、その機能は主にSIGARのHyperic社の認識に基づいています。
パフォーマンスモニタリスナは、プラグインのJMeter、前記リスナのように統合されます。
1.1 ServerAgentの展開
前提：ServerAgentは、バージョン上記JRE1.4サポートを実行する必要があります。
ダウンロード：公式からダウンロードしてください
展開：テストサーバーに置かダウンロードした.zip、アンパック、startAgent.sh（直接実行中の
Linuxの
）/startAgent.bat（
Windowsは、
単純なテキストプロトコルを使用して）、デフォルトのTCPプロトコルを使用して、データ伝送のためのJMeterで、することができますデフォルトのポート4444。もちろん、Linuxでは、私たちは通常、nohupを使用するなど、バックグラウンドでそれを置きます。
検証は：滑らかなテストプロセスを確保するために、我々は、通信ServerAgentが適切JMeterのテストサーバーとプレスにデプロイするかどうかを事前に確認することができます。10：52.430 [便利な方法は、通信、テスト入力した後、例えばテルネット192.168.18.10 4444として、JMeterのServerAgentプレスとのTelnet送信「試験」を使用することで、出力は通常、同様のINFO 2017年7月29日23 ServerAgentますkg.apc.p]（）：うん、私たちは、ログの「試験」コマンドを受信しました。
ポートを指定するスクリプトを実行するときは、$ ./startAgent.sh --tcp-ポート3450と、--tcp-xxxポートを追加することができ、この時点でも、ときJMeterPerfMonプラグイン対応するポートをバインドするように変更する必要があることに留意すべきです。詳細については、公式ドキュメントのダウンロードページを参照することができます。
1.2パフォーマンスモニタプラグインの使用
インストール：JMeter3.0後、JMeterの-プラグインが付属プラグインをインストールするには2つの方法があります。
第一の実施形態：公式サイトのJMeter-プラグインを検索し、パフォーマンスモニタをダウンロードするには、結果のパッケージは、リスナーで使用プラグから選ば瓶のJMeterインストールディレクトリのlib / extに/パスのJMeterの再起動、下に置かれています。
第二の方法： - 新しいJMeterのパフォーマンステスト3.0の時代：使用プラグインマネージャが、よく知られている国内の理由のため、多くの学生が問題を示さないことは、ここには、ネットワークのウィジェットは、私の以前の記事を参照して、起動しませんしません遭遇しましたJMeterのプラグインマネージャ
使用：、ポートServerAgentが取得して表示するために使用示すように、プラグイン選択パフォーマンスモニタリスナーは、試験計画2に添加し、そして参照してIP ServerAgentテストサーバの配備の構成を含む、3構成図します資源およびその他の項目。テスト開始後
パフォーマンスモニターウィジェットを使用して図2
観測データ記憶：GUIを使用してモードをデバッグする場合、試験開始後、直接データ収集のグラフによれば、対応するウィンドウで観察することができます。そして、設計、テストを保存するために、図3のアドレスでの構成データのファイル名の場所を計画する際に、監視データを表示、NO GUIモードを使用してテストの正式な実装にしてJMeterのテストマスタデータにあることを注意すべき、と同じように保存JMeterのテストおよびマスター・データに同じファイルを保存しないでください。テストの実行が完了した後、次いで、グラフィックディスプレイ監視データを表示するプラグインインタフェースでファイルをロードします。
II。高度な
同僚、そこに友人の技術的なグループから、私は意味の多くは様々な指標の学生のためにそこにあることを学んだ、パフォーマンスモニタプラグインのデータを示し、特に手段としては、特に明確ではないので、この部分について話します。グラフ表示データに加えて、注目すべきいくつかのポイントがあります。
2.1指標
モニタリング指標データについての疑問は、回答のほとんどは、メトリックパラメータ設定インターフェイスプラグインパフォーマンスモニターから求めることができます。私たちは、このようなCPU、メモリ、および他の指標などのサーバーが各タイプを監視するための、CPU用などのリソースの使用状況を反映するために異なる次元からの様々なデータがあることを知って、topコマンドでは、Linuxシステム上のアイドル、ユーザー、システム、およびその他のデータを見ることができます。
パフォーマンスモニタプラグは、特定のリソースメトリックパラメータの特定のデータ収集と表示のために設定されてもよいが、右上の赤い矢印4、ダブルクリック入力ボックスを示すような、入口に非常に目立たない、最後の側をクリックするため等プライマリ指標、その他のメトリックに分割されている特定の構成要素の各メトリックが、同一の構造にもよるがオープンボタンは、図4の中間赤矢印で示したインタフェースを開くために、主は一般に考えられて公式は、通常実際のです
仕事
より懸念し、より多くのインデックス・エントリが基準意義を持っている、追加のインデックスエントリを知っておく必要があるかもしれないいくつかの特別なシナリオです。
対応するグラフが掲載されていないここで簡単にリソース・アイテムの種類の主な指標のいくつかについて話、それは読書に影響を与え、あまりにも多くのスペースを取ります。
1、CPU：
各索引項目について、パーセント値はグラフ30に見られるようなデフォルト設定（組み合わせ）を代表するものであり、30％を占め、この時点での総CPU時間を表し、特定の時点での値です。
まずスコープ面積二は、CPUコアエリア内にある、我々は指定された個々のコアの監視を選択することができ、あなたがパー・プロセス・オプションで指定されたプロセスのCPU使用率を取得することができ、：注目に値する2つの便利な場所があります。
2、メモリ：
各指标项中，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 曲线图
曲线图配置：
插件界面的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性能测试资源监控插件的部署，然后从现有指标、曲线图和自定义指标三个方面讲解了插件使用过程中比较使用的细节问题，希望通过本文，让大家能灵活运用这款插件来快速实现自己的测试需求。