•  

   

  

   

  零.引言

  我们对被测应用进行性能测试时，除了关注吞吐量、响应时间等应用自身的表现外，对应用运行所涉及的服务器资源的使用情况，也是非常重要的方面，通过实时监控，可以准确的把握不同测试场景下服务器资源消耗情况的变化，对于应用性能分析有着重要的作用，同时也是调整测试场景设计的重要依据。对于使用JMeter执行性能测试的朋友，可能大都知道中就有用于服务器资源监控的插件，同时也有不少同学会选择类似的独立监控方案。

  之所以决定写这篇文章，一是因为在使用JMeter作为性能测试工具的情况下，使用专为其设计的插件会更方便，二是对于普通互联网公司的性能测试方案，这款插件所提供的功能已经可以满足其资源监控方面的大多数需求，而最重要的一点，是在技术群里发现虽然很多同学知道或者在用这款插件，但是对于一些概念和细节，并不了解，导致不能很好的满足自己的需求，而现在网络上介绍这款插件的博客文章，大都是Quick Start式的入门文章，并不能解答这些同学的疑问。

  注：本文使用的JMeter版本为当前最新release版本3.2。

  壹.基础

  本来PerfMon插件的安装部署不是本文的重点，但为了保持文章的完整性，这里还是进行简单的介绍。有基础的同学可以跳过。

  使用PerfMon进行服务器资源监控的方案由两部分来实现

  1. ，部署在被测服务器，负责资源耗用数据的采集，其功能实现主要基于hyperic的。
  2. ，以插件形式集成到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之后，有两种方式安装所包含的插件。 使用：如图2所示，在Listener中选择PerfMon插件，添加到测试计划中，然后参考图3进行配置，包括配置部署了ServerAgent的被测服务器的IP、ServerAgent使用的端口、要获取和展示的资源项等。测试启动后
    • 第一种方式：到搜索PerfMon并下载，将得到的jar包放置于JMeter安装目录的lib/ext/路径下，重启JMeter，从Listener中选择使用插件。
       

      

      图1 插件下载
    • 第二种方式：使用Plugins Manager，不过由于国内众所周知的原因，很多同学可能遇到网络不通不能展示插件的问题，这里就不展开了，可参考我之前的文章：
  •  

    

    图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性能测试资源监控插件的部署，然后从现有指标、曲线图和自定义指标三个方面讲解了插件使用过程中比较使用的细节问题，希望通过本文，让大家能灵活运用这款插件来快速实现自己的测试需求。

。