| 在系统测试，尤其是性能测试或者是稳定性测试的过程中，我们往往需要对测试环境的健康状况，资源消耗情况(如CPU利用率，内存利用率，DB连接数等)，网络流量(如Socket个数，网络带宽)等进行实时监控。而随着应用规模的扩大以及拓扑结构的复杂化，比如云计算，我们的测试环境也变得越来越复杂，单单一套测试环境就可能由数个或者数十个分布在各地的网络设备或运行着不同操作系统平台，中间件或数据库等软件或服务的服务器。所以对于测试人员或环境监控人员来讲，一款能够集中监控所有目标机，且能灵活地定制监控指标，以及图表展示的监控软件将大大地提高工作效率。Cacti就是一个能够完全满足以上需求的系统和网络监控开源软件。它集数据采集，存储，图表定制和显示为一体。它由SNMP服务获取数据，用RRDTool储存和绘图，用PHP生成前管理端界面给用户。 本文从Cacti的主要功能以及工作机制介绍入手，重点讲解了在Cacti中如何根据应用系统的需要，设计监控模板并完成与目标测试机的关联部署，从而实现灵活地自定义监控。最后分享了利用Cacti在性能测试和稳定性测试中的实践，以及监测诊断性能问题的技巧。 1.Cacti背景介绍 Cacti的主要功能有： 数据定时采集。Cacti支持两种数据输入渠道,一种是通过SNMP服务，一种是用户自己编写脚本。Cacti数据采集器会定时地获取SNMP数据或运行用户脚本，并将采集的数据更新到RRD环状数据库文件中。 图表实时绘画与显示。Cacti采用高性能的绘图引擎RRDTool，定时刷新与显示图表。在绘制前Cacti还可以对数据进行简单算术或逻辑运算。用户不仅可查看当前数据，还可按照每年，每月，每周等不同视角查看图表。 树状的主机和图像管理。在Cacti中，主机和图表以层次清晰的树形结构管理。树的根节点为项目名称，子节点为监控的主机，孙子节点为为该主机定制的一系列图表。 用户和权限管理。Cacti允许管理人员创建新用户，并赋予不同层次的权限，比如管理用户可以配置或修改图表的定义，而普通用户则只有权查看。 模板定义和导入导出。Cacti提供三种类型模板，用户可以根据模板快速配置，提高效率。Cacti支持用户自定义模板，或导入外部模板。 快捷定制。Cacti用户无需明白绘图引擎RRDTool的众多参数, 只要在Cacti管理界面上操作即可轻易地定制出想要的图表。 Cacti的体系架构介绍 在介绍Cacti的系统体系结构之前，我们先对Cacti中用到的一些重要技术做概要介绍。 RRD(Round Robin Database)数据库 RRD为环状数据库，它按照“循环”round-robin的方式进行存储。该类型数据库存放的记录个数是一定的，当写入最后一条数据后，新到的数据会覆盖之前的数据，所以不会有数据库溢出的风险，维护成本也较低。这种数据库适用于与时序有关的应用。 RRD Tool RRDTool是Tobi Oetiker为替代另一个非常流行的监控工具MORTG而编写的软件。它是一个存储和绘制时序数据的高性能工具。除了Cacti之外，很多工具如Nmon,
OpenNMS等也是基于RRDTool之上。 SNMP协议 Cacti利用SNMP协议接收数据。SNMP是简单网络管理协议的缩写，任何支持SNMP协议的路由器、服务器、主机、打印机等设备都可以加入Cacti的监控范围。 Cacti的架构 整个Cacti系统由前后台4个部分组成(如图1)： Cacti页面——由PHP生成。页面分管理控制台和图形显示两大块。管理控制台供用户设置各种模板，创建图形，管理用户等。图形显示页面按照用户定义的树形结构管理所有图形，并实时绘制图形。 SNMP采集工具——Unix下使用 Net-SNMP软件包自带的数据获取方法(snmpget和snmpwalk等程序。 RRDTool——用来存储性能数据并实时绘制图像。性能数据保存在RRD文件中。 MySQL数据库——储存RRDTool绘图所需的信息，如模板、RRA、主机信息等。MySQL数据库并不保存性能数据。
Cacti背景介绍 ▲图1 Cacti系统体系架构图 Cacti的优势 Cacti与同类型软件相比，有其重要的优势: 使用RRD存储格式，适用于实时应用，维护成本低; RRA (Round Robin Archive)使得用户能够基于不同的时间间隔(年，月，周，日)查看数据。 一个图形上能绘制任意个数据源，方便比较参考; 支持基于模板的配置，提高配置效率。 数据存储与绘图分开，减轻系统负载; RRDTool可以在绘制图像前对数据进行基本的算术和逻辑运算。 界面操作简单易用，用户不用关心底层RRDTool复杂的参数设置。
2.在Cacti中实现自定义监控 如上面所总结的，Cacti本身灵活易用，能够辅助用户根据自己需求轻松地定制监控的内容和图表展现形式。下面我们对实现自定义监控的重要步骤做更详细的介绍。 分析应用类型，总结监控需求 在Cacti配置前，重要的一步是分析和整理需求。比如哪些目标设备会被加入监控范围;每个设备运行的操作系统是什么，是否支持SNMP协议?设备上是否设置防火墙?每个设备的应用类型是什么，Web服务器，数据库，或应用服务器?对每种类型的设备，你关注的性能指标有哪些?什么样的图表形式能够更清楚地展现数据和及早发现问题。 开启SNMP服务 Linux默认安装了SNMP服务。在被监控主机上，查看snmpd.conf，修改COMMUNITY设置，将Cacti服务器加入可信任主机范围。
重新启动SNMP服务：
Windows 2003缺省没有安装SNMP协议。要启动SNMP协议支持，只需在控制面板选择添加 Windows
组件，然后选择管理和监视工具，简单网络管理协议 (SNMP)即可完成。 接下来类似地，需要在SNMP的服务设置中(如图2)把Cacti服务器加入到该监控机器的可信任主机列表中，并赋予Cacti服务器只读权限。
▲图2 修改SNMP的安全设置
要注意的是，如果在监控设备上安装了防火墙，还需在防火墙把SNMP对应的161 端口打开。 定义或导入模板 接下来在Cacti中，我们就可以按照创建设备->创建数据源->创建图像->创建管理树的顺序进行设置，具体步骤会在2.4节做详细介绍。实际上，用户并不用每次都从零开始创建，而是可以利用Cacti中预定义的三种类型模板，数据源模板，图表模板，主机模板，或按照模板原样复制或是基于模板做裁减，从而加快配置效率。用户可以自定义模板也可导入现成的模板定义文件。 定义数据模板 数据模板是对不同设备中一些具有共同特点的数据源定义进行归纳。比如对大多数设备我们都会查看CPU空闲率，CPU使用率，内存总大小，可用内存，缓冲池大小和网络端口流量等性能参数，且它们在各个设备的计算方式都一致，所以我们可以为这些性能指标创建相应的模板。下面列出了一些常用到的数据模板。
▲图3 创建数据模板
用户可以点击控制台左边导航菜单“Data Template”，然后在右边页面上点击“Add”按钮来添加一个新的数据模板。数据模板定义由以下几部分组成，如图4。对于大多数项，用户都可以通过选项Use
Per-Data Source Value的选择来决定数据源中该项是否继承模板中定义的值。 1.数据模板名称。 2.数据源。 数据源名称：通常，我们在数据模板名称前加前缀”|host_description|”作为数据源名称。在创建数据源的时候，关键字”|host_description|”会被所关联的主机信息替换。 数据源输入方式：用来定义Cacti如何获取数据，Cacti提供了多种输入方式，包括：Get SNMP
Data，Get Script Data，Get Script Server Data等。 RRA：Cacti允许用户以多种视图查看存放的数据，比如可以查看每周，每月，每年的数据汇总情况。该项就是用来定义多长时间RRDTool做一次汇总。每个汇总对应一个RRA文件。 RRD数据更新频率，默认为5分钟。 3.数据项。 内部数据源名称： RRDTool用此名称从RRD文件中区分该数据源。 最大最小限制，如果采集的数据超过设定的数值区间，RRDTool会存储字符U(表示未知数据)。 数据类型：Cacti预设了4中数据类型：COUNTER, GAUGE,ABSOLUTE，DERIVE。 心跳设置：通常设为600 4.数据自定义。该部分用来设置数据输入所需的参数。比如选择SNMP获取CPU内核使用率时，我们需要指定该性能参数对应的OID代码。 
▲图4 数据模板的组成
定义绘图模板 同样地，我们可以创建图表模板，使得应用该模板创建的图像具有一致的显示样式，图例，数据源等。用户可以点击控制台左边导航菜单“Data
Template”，然后在右边页面上点击“Add”按钮添加一个新的图像模板。如图所示，图像模板定义由以下几部分组成： 1.图像模板名称：模板名称需唯一，且表意清晰。 2.显示格式设置： 图像名称：图像命名的规范通常是在图像模板名称附加前缀”|host_description|”。在创建一副新图表时，关键字”|host_description|”会被所关联的主机信息所替换。 图片输出格式: 支持PNG, SVG, GIF三种格式。 宽度，高度，自动收放设置等。 Y轴上限，下限以及基准值的设置。 3.数据项设置： 数据条目设置：通过“Graph Template Items”，可以选择图中具体显示的图例及颜色设置。 数据源：通过“Graph Item Inputs”添加，并与数据条目做关联。 
▲图5 绘图模板样例ucd/net-Memory
Usage
定义设备模板 在监控不同类型的设备时，用户关注的性能指标也不一样。比如对于交换机，路由器等网络设备，我们关注进入或流出的网络流量;对于应用服务器，我们关注JVM
Heap的使用和线程池等;对于数据库服务器，我们关注死锁，连接数等。而设备模板的创建就是基于设备分类，把不同类型的设备以及与其相关的绘图模板和数据查询建立关联。如图6，我们为所有WebSphere
应用服务器定义了名称为Websphere V6 PMI的模板，该模板包括4个监控WebSphere性能状态的图形。当用户根据此模板创建一个新的监控设备时，相应的数据源和绘图也会与该设备关联，节省了很多配置时间。 
▲图6 设备模板Websphere V6
PMI的定义
模板导入 实际上，用户在多数情况下无需自定义模板，除了Cacti默认自带的模板之外，很多开源社区提供了足够丰富的模板资源供用户下载，一套模板通常是一个包含了数据模板和图表模板定义的XML文件。用户可通过Cacti界面导入模板。 
▲图7 模板导入图
在导入时，注意选项“Import RRA Settings”，默认为不覆盖原有的RRA设置，为了防止在模板导入的过程中，全局RRA定义文件被覆盖，推荐选择默认选项。在导入时，Cacti同时会做版本检查，只有在当前模板定义的Cacti的版本等于或高于当前Cacti版本时，导入才会成功。
关联目标机和模板，创建管理树 当模板创建完后，就可以应用模板创建数据源，图表和主机信息了，这个过程其实就是将模板和监控主机关联的过程。用户也可以在模板的基础上，根据需求做相应地调整。 第一步，将每个目标设备加入监控设备列表中。 
▲图8 设备列表
图9列出了与创建设备有关的信息，它分为三个部分：被监控主机的一些主要信息，与该设备关联的图像模板，关联的数据查询。 
▲图9 创建设备
第二步，创建数据源 通过Associated Data Queries界面，增加数据源。 
▲图10 关联数据源
第三部，创建图表 通过Associated Graph Templates界面，创建图表信息。 
▲图11 关联绘图模板
第四步，创建管理树 在上图的界面点击旁边的create Graphs for this host.为刚刚创建的主机创建图形。 Management->Graph Trees->add 新建图形树。创建完了一级目录后，进入一级目录，单击ADD创建二级目录。
3.Cacti在性能测试和稳定性测试中的应用 在性能测试和稳定性测试中，往往需要实时监控系统的各方面信息，获取到准确的统计信息，以便通过某些参数的异常变化及时发现系统的性能问题。同时，为了保证测试的准确性，也要求监控工具能够尽量少的占用系统资源。使用Cacti能够很好的平衡这两个要素，通过自定义模板，可以将我们需要监控的信息进行有序的组织，以友好的图表化方式显示。同时，由于借助于snmp服务，Cacti的controller可以单独部署在其它的机器上，这样对被监控机的资源占用也减少到了最小。 在性能测试中，我们运用Cacti成功的发现了一些性能问题，现列举实例如下。 DB2锁等待问题 在应用运行过程中，通过对数据库锁信息的监控，发现Lock-Wait Time突然增长，这说明存在锁等待的情况，并且锁等待时间已经影响到了应用的正常操作，造成了性能问题。 
▲图12 Cacti监控DB2锁
通过运行db2pd -db dbname –applications命令列出所有当前正在使用数据库的application，发现以下application处于lock-wait的状态。 
继续运行db2pd -db dbname -locks wait命令，会只转储出处于等待状态的锁信息。通过所示的信息我们可以判断出锁的类型为行锁，正在试图请求NS锁。TbspaceID表示的信息为表空间ID，TableID表示的信息为表ID。通过TbspaceID和TableID可以进一步确定发生锁等待的表。 
继续执行db2 "select tbspace,tabschema,tabname,tableid,tbspaceid
from syscat.tables where tbspaceid=2 and tableid=266"命令，可以返回相应的表名。这样我们就缩小了范围，可以通过对此部分代码走查发现产生问题的代码。 资源瓶颈 在较少并发用户的测试中，通过Cacti监控发现CPU使用率一直处于80%以上，成为影响负载测试继续执行的瓶颈。 
▲图13 Cacti监控CPU使用率
在查看RPT的报告数据，我们也发现有一个页面的响应时间远远高于其他页面。 
▲图14 RPT性能报告—页面响应时间
首先，我们检查了内存和I/O的使用情况，两者都处于一个相对正常的水平。所以，我们可以判断出此处的高CPU占用率不是由于内存和I/O资源紧张所导致的。之后，我们继续对应用服务器JVM的堆使用情况进行了分析。在整个测试过程中，JVM的堆使用率不超过初始化最大值的75%，并且GC工作平稳，所用CPU时间不超过总时间的15%。所以，也可以排除由应用服务器JVM资源引发性能问题的可能。通过对线程池和数据库连接池的检查发现仍有空余资源，所以这也不是导致性能问题的因素。之后我们对系统中的各个进程进行了详细的分析，注意到进程db2sysc和db2agent占用了较多的CPU资源。于是，我们激活了数据库快照监控，并用DB2
PE对执行的SQL语句进行了抓取。发现部分SQL语句花费了较长的时间。进一步分析access plan表明，在这些语句中存在着全表扫描的现象，并且所操作为一个拥有百万行数据的表。这样就导致了整体的性能下降。 
▲图15 Access Plan
在建立有效地索引之后，解决了全表扫描问题，SQL执行速度得到了很大的提高，同时也使前端页面的响应时间降低到了原来的10%，而CPU利用率也降回到正常的水平，保障了负载测试继续进行。 在稳定性测试中，我们常常需要保持较长时间的负载，以确定应用中是否存在各种资源泄漏问题。通过Cacti实施资源监控，可以方便的查看各个时间段内资源的使用情况，并且图表化的方式使得资源使用趋势一目了然。下面列举两个稳定性测试中的实例来说明Cacti的重要作用。 内存泄露 从Cacti对JVM资源使用情况的监控信息可以看到JVM的使用率随着时间不断升高。正常情况下，在达到稳定负载之后，JVM的使用率应该保持在一个相对平稳的范围内，不应该随着时间上升。对性能测试工程师而言，这样的情况往往意味着应用中可能存在内存泄露的情况。为了获取更多的信息进行验证，我们将负载逐渐停止并同时监控JVM的使用率信息。如果应用中不存在内存泄露，那么JVM的使用率会随着负载的减小而逐渐降低，并在负载完全停止后很短的一段时间内恢复到执行测试前的水平。可是，随着负载的减小，JVM的使用率丝毫没有降低，并且在负载停止后较长的一段时间内仍然保持着很高的利用率。这就肯定了我们关于应用中存在着内存泄露的推断。 
▲图16 Cacti监控JVM资源使用情况
为了定位内存泄露，我们在测试执行过程中针对WAS进程产生了javacore dump文件。通过工具进行分析，可以看到如图17中所示的线程状态统计。其中有6028个线程处于等待条件状态，占了所有线程总数的99%以上。 
▲图17 线程分析图
同时，对线程执行方法也做了相应的分析。从下图中可以看到当前的堆栈中调用最多的方法是java/lang/Object.wait(Native
Method)。占线程总数的99%以上。 于是，我们进一步展开，对java/lang/Object.wait(Native Method)的内容进行分析。并且进一步结合代码，确认了问题是由调用的第三方接口所引起。后来安装了最新的fixpack得以解决。 
▲图18 方法分析图
TCP连接泄露 在应用运行过程中，前台用户操作响应时间逐渐变慢。通过Cacti的监控图观察到CPU、内存、I/O和网络的使用情况均为正常。但是从TCP连接状态的监控图(图19)中发现处于close
wait状态的tcp连接有逐渐上升的趋势，没有正常释放。为了排除环境的个体配置差异导致的问题，我们在另外一套测试环境中以相同的负载运行了同样的脚本，在监控结果中发现了同样的现象。这就说明极有可能是应用代码中出现了问题。 
▲图19 Cacti监控TCP连接
在协同开发人员一起对相应部分的代码进行走查发现，这个TCP连接没有释放的问题是由调用第三方API导致。在与相应的产品部门做过沟通后，更换了新的版本解决了此问题。 4.总结 Cacti是性能测试过程中有力的监控工具。通过Cacti对所需的参数进行自定义式监控，可以让我们能够在性能测试早期及时发现问题，从而降低了修改的成本，提高了应用系统的稳定性。
|
