CN102480390A - 用于系统监控的方法和装置 - Google Patents

Abstract

本发明涉及IT系统性能管理技术领域。更具体地，本发明涉及对复杂IT系统进行按需监控的技术。根据本发明的一个方面，提供了一种用于系统监控的方法，包括：监控所述系统的客户端的性能参数；根据所述客户端的性能参数判断是否需要对所述客户端直接调用的服务端点进行监控；如果判断结果为是，定位需要被监控的所述服务端点；以及监控所述服务端点的性能参数。

Description

用于系统监控的方法和装置

技术领域

本发明涉及IT系统性能管理技术领域。更具体地，本发明涉及对复杂IT系统进行按需监控的技术。

背景技术

系统监控是IT系统管理中的一项至关重要的任务。通过系统监控，系统管理员可以了解系统的运行状态并找出系统中存在的问题，及时解决问题从而确保系统的正常运行或符合服务水平协议(SLA)所规定的要求。

随着云计算(Cloud Computing)技术、面向服务体系架构(SOA)技术的迅速发展，在IT系统中往往存在多个应用集成起来向用户提供服务。例如在一项网络银行服务中，其后台可能存在多个支撑该网银服务的应用，比如数据库服务、帐务查询服务、转账服务、跨行结算服务等。要试图对网络银行服务进行整体监控并在系统出现问题时迅速定位导致问题的应用，则需要为其中每个应用部署并激活相应的监控代理。部署数量庞大的监控代理会带来大量的资源消耗，并且这些监控代理在运行时还会消耗大量的运算资源，甚至直接导致整个IT系统无法正常运行。由此可见，确定部署监控代理的范围是至关重要的。换句话说，必须在IT系统性能以及部署监控所导致的资源消耗两个方面取得平衡。

现有技术中存在解决上述问题的技术方案。系统管理员可以通过手动地调整系统监控的范围来实现灵活地部署监控模块的目的。然而，这需要系统管理员对IT系统要有深入的了解，但这实际上是很难实现的(尤其在云计算环境下)，并且基于人的主观意志来判断监控的范围也很容易出错。进一步，对于复杂IT系统而言，手动调整监控范围是及其费时的，很有可能系统在手动调整完成之前或者系统对手动调整结果进行响应之前就崩溃了。

现有技术中还存在另外一种解决上述问题的技术方案。根据该技术方案，根据监测到的系统关键性能指标(KPI)来改变监控级别，例如一级至三级。但是，监控级别仅仅意味着监控的粒度或精细度(详细信息监控抑或概要信息监控)的差别，无论启动哪个监控级别实质上都是在监控复杂IT系统中的每一个应用或子服务，其并没有改变监控的范围(横向改变)而只是改变了监控的粒度(纵向改变)。

因此，需要一种真正以问题为导向的自动调整IT系统监控范围的技术方案。

发明内容

考虑到上述存在的问题，本发明的目的之一在于提供一种以问题为导向的自动调整IT系统监控范围的方法和装置。本发明的又一目的在于提供一种以迭代的方式自动调整IT系统监控范围的方法和装置。

根据本发明的一个方面，提供了一种用于系统监控的方法，包括：

监控所述系统的客户端的性能参数；根据所述客户端的性能参数判断是否需要对所述客户端直接调用的服务端点进行监控；如果判断结果为是，定位所述服务端点；以及监控所述服务端点的性能参数。

根据本发明的一个实施例，上述方法进一步包括：如果所述客户端的性能参数不满足预定的与所述客户端相关的服务水平标准，则需要对所述客户端直接调用的服务端点进行监控；以及如果所述客户端的性能参数满足预定的与所述客户端相关的服务水平标准，则不需要对所述客户端直接调用的服务端点进行监控。

根据本发明的另一方面，提供了一种用于系统监控的装置，包括：客户端监控装置，用于监控所述系统的客户端的性能参数；判断装置，用于根据所述客户端的性能参数判断是否需要对所述客户端直接调用的服务端点进行监控；定位装置，用于当如果判断结果为是时，定位所述服务端点；以及服务端监控装置，用于监控所述服务端点的性能参数。

通过本发明的方法和系统，可以实现以问题为导向灵活且自动地调整监控范围的目的，从而降低了大规模部署监控所导致的资源消耗，还避免了手动调整系统监控范围过程中产生的困难及高出错率。

附图说明

通过对结合附图所示出的实施方式进行详细说明，本发明的上述以及其他特征将更加明显，本发明附图中相同的标号表示相同或相似的部件。在附图中，

图1示出了根据本发明一个实施例的用于系统监控的方法的流程图；

图2示出了根据本发明又一实施例的用于系统监控的方法的流程图；

图3示出了根据本发明一个实施例的用于系统监控的装置的框图；

图4示出了根据本发明又一实施例的用于系统监控的装置的框图；

图5示出了根据本发明一个实施例的以迭代方式调整系统监控范围的示意图。

具体实施方式

在下文中，将参考附图通过实施方式对本发明提供的用于确定要被物化的节点的方法和系统进行详细地描述。

图1示出了根据本发明一个实施例的用于系统监控的方法的流程图。图1所示的方法从步骤101开始。在步骤101中，监控客户端的性能参数。对于一个复杂的IT系统而言，其中包含客户端和多个子服务或子应用，在所有的子服务或子应用上均部署监控无疑是浪费的。因此在图1所示的方法初始阶段仅监控客户端的性能参数。根据本发明的一个实施方式，客户端的性能参数是关键性能指标KPI，包括但不限于响应时间、出错率、连接错误、吞吐量等能够表征客户端性能的参数。本领域技术人员应当知晓，监控性能参数可以通过部署监控代理并激活监控代理来实现。

接下来，图1所示的方法进行至步骤102。在步骤102中，根据在步骤101中监控得到的客户端性能参数，判断是否需要对该客户端所直接调用的服务端点进行监控。根据本发明的一个实施方式，判断的依据可以是预定义的服务水平标准(SLA)。例如，如果预定义的客户端的SLA规定：响应时间不得超过0.5ms，那么如果在客户端监控得知响应时间为0.8ms，则在步骤102中确定需要对该客户端所直接调用的服务端点进行监控。需要指出的是，由于对于客户端而言，其并不会直接调用IT系统所包含的所有子服务或子应用，例如客户端通常不会直接调用最底层的数据库应用，这是因为IT系统内具有逐级调用的关系。本发明的关键点之一就在于，当监控到客户端的性能参数不能满足要求时，仅在客户端所直接调用的那个需要被监控的服务端点上部署并激活监控，也就是逐级确定系统的监控范围。如果客户端直接调用了多个服务端点，那么可以根据监控到的客户端的性能参数来确定究竟需要在哪个服务端点上启动监控，而不是需要在客户端直接调用的所有服务端点上均启动监控。本领域技术人员应当理解，具体的判断标准可以根据IT系统的具体情况进行变化，利用SLA判断仅是本发明提出的一种可能的实施方式。

当在步骤102中的判断结果为是时，在步骤103中定位客户端所直接调用的服务端点。根据本发明的一个实施方式，定位客户端所直接调用的服务端点是指确定要向该服务端点部署或激活哪一个特定的监控代理。由于不同的应用需要使用不同的监控代理对其进行监控，因此要正确地部署并激活监控代理必须首先确定该服务端点的地址标识并确定在该服务端点上运行的具体应用的名称及版本号。在下文中将结合图2具体描述定位客户端所直接调用的服务端点的方式。

接下来图1所示的方法进行至步骤104。在步骤104中，监控该客户端所直接调用的服务端点的性能参数。至于具体的方式和可能选取的性能参数类似于在步骤101中对客户端的监控，在此不再赘述。

需要强调的是，“客户端”与“服务端点”实质上是相对的概念，在步骤104中所监控的服务端点相对于其直接调用的下级服务端点而言就成了新的“客户端”，以此类推。当在步骤104中监控由客户端所直接调用的服务端点时，如果判断需要对该服务端点所直接调用的下级服务端点进行监控，则迭代式地重复步骤102至104。这样的迭代过程在下文结合图2进行的文字描述部分将得到更深入地说明。

当然本领域技术人员应当理解，即使没有后续迭代式重复的操作，通过图1所示的方法也可以实现按照需要以问题为导向逐级部署监控的技术效果——先仅在客户端部署监控，一旦监控到有问题则向其直接调用的服务端点部署相应的监控。从而避免了降低了大规模部署监控所导致的资源消耗，还避免了手动调整系统监控范围过程中产生的困难及高出错率。

图2示出了根据本发明又一实施例的用于系统监控的方法的流程图。图2所示的方法从步骤201开始，在步骤201中监控客户端的性能参数，这相当于图1所示的方法中的步骤101，在此不再赘述。

接下来，在步骤202中，判断监控到的客户端的性能参数是否符合预定义的服务水平标准SLA。如果判断结果为是，则说明IT系统运行正常，从而无需部署更多的监控，因此返回至步骤101继续保持对客户端的性能参数的监控。如果判断结果为否，说明IT系统的性能出现问题，而当前由于仅仅在客户端上部署了监控，因此无法确定究竟问题存在于哪个具体的子应用上，因此需要通过扩大监控范围——部署新的监控，来找到出现问题的准确位置。

因此，如果在步骤202中的判断结果为否，则在步骤203中确定该客户端所直接调用的服务端点IP地址和端口号。根据本发明的一个实施方式，服务端点的IP地址和端口号信息是从在客户端部署的监控代理中取得的。下面给出了Service Endpoint的一个例子，通过解析WebService的WSDL文件<service>标签，中的<port>标签的<location>标签会得到这个服务的Service′s Resource Locator(服务资源定位器)，该SRL唯一标志了该服务FOOSAMPLEService

<service name＝″FOOSAMPLEService″>

  <port name＝″SimplePort″binding＝″wsdlns:SimpleBinding″>

   <soap:address

location＝″http://carlos:8080/FooSample/FooSample.asp″/>

   </port>

</service>

但是，仅仅得到了客户端所直接调用的服务端点的IP地址和端口号(或服务资源定位器)并不能确定要将什么样的监控代理部署到该服务端点。还需要确定在服务端点上所运行的应用的信息(步骤204)。根据本发明的一个实施方式，在服务端点上运行的应用的信息包括应用的名称及版本号。根据本发明的一个实施方式，获取在服务端点上运行的应用的信息是通过利用在步骤203中获得的服务端点的IP地址和端口号，向所述服务端点发出查询请求，以获得服务于该服务端点的TCP端口的进程，从而获得在该服务端口上运行的应用的名称及其版本号。本领域技术人员应当理解，关于具体的查询请求的发送方式及格式，依赖于不同的系统环境。例如，通过远程执行，查询在该IP和端口上监听的执行程序，比如WAS的Java.exe全路径执行名，然后得到软件名称和版本信息。

接下来，图2进行至判断步骤205。在步骤205中，判断对应于在所述服务端点上运行的确定版本的应用的监控代理是否已经被部署。如果判断结果为否，则在步骤206中部署相应的监控代理，并且在步骤207中激活该相应的监控代理，以启动对所述服务端点的性能参数的监控。如果判断结果为是，在直接在步骤207中激活已经部署(但是处于灭活)状态的相应的监控代理，以启动对所述服务端点的性能参数的监控。需要指出的是，之所以可能存在监控代理已经被部署但是处于灭活状态的情况，是因为在之前可能对该服务端点进行过监控，但是由于监控到客户端的性能参数已经恢复正常，因此根据本发明的一个实施方式，无需继续对该服务端点进行监控，从而将相应的监控代理灭活(有可能在灭活后删除监控代理的部署，也有可能尚未删除监控代理的部署)。还需要指出的是，根据本发明的一个实施方式，在步骤205中通过将在步骤204中获取的软件名称和版本信息与预定的监控代理信息元数据表中的信息进行比对，从而找出相应的监控代理，进而根据所找出的匹配的监控代理信息来判断该监控代理是否已经被部署(该比对的步骤未在图2中示出)。下面的表1给出了一个监控代理信息元数据表的实例：

应用名称	监控代理
		WAS 5.3.0.0	ITCAM for WAS 5.0
WAS 6.1.0.0	ITCAM for WAS 6.0
		..	...

表1

在步骤207中激活客户端所直接调用的服务端点的监控代理后，在步骤208中监控该服务端点的性能参数。并且类似于步骤202，在步骤209中判断是否需要对该服务端点所直接调用的下级服务端点进行监控。如果步骤209的判断结果为否，则返回至步骤208，继续保持对该服务端点的性能参数进行监控。如果步骤209的判断结果为是，则返回至步骤203，重复进行步骤203至步骤209的操作，以此类推，从而以迭代的方式按照需要，以问题为导向逐级调整监控代理的部署范围。

需要强调的是，虽然在图2中仅示例性地示出了一次迭代的过程，但是本领域技术人员完全可以基于同样的原理，根据图1或图2所示的方法实现从客户端开始逐级迭代地调整系统监控范围的技术方案。服务端点相对于其直接调用的下一级服务端点即为“客户端”，而“客户端”相对于直接调用它的上级节点即为“服务端点”。

还需要强调的是，虽然在图1、图2以及上文中仅示出并说明了由客户端开始逐级扩大系统监控范围的流程，但是本发明所提出的动态迭代逐级调整系统监控范围的技术方案不仅仅是从无到有地扩大系统的监控范围，还包括基于同样的原理而动态迭代逐级缩小系统监控范围。在复杂IT系统尤其是云计算环境下，对系统的监控需求通常是处于动态变化的过程中，以图2所示的方法为例，如果在步骤202中监控得知当前客户端的性能参数已经满足SLA的要求，并且当前正在对客户端所直接调用的服务端点进行监控，那么处于节省系统资源的考虑就可以停止对客户端所直接调用的服务端点进行监控。

图3示出了根据本发明一个实施例的用于系统监控的装置的框图。图3所示的系统在整体上由系统300表示。具体地，系统300包括客户端监控装置301，用于监控所述系统的客户端的性能参数；判断装置302，用于根据所述客户端的性能参数判断是否需要对所述客户端直接调用的服务端点进行监控；定位装置303，用于当如果判断结果为是时，定位所述服务端点；以及服务端监控装置304，用于监控所述服务端点的性能参数。进一步，装置300包含的模块301至304分别对应于图1所示的方法中的步骤101至104，在此不再赘述。

图4示出了根据本发明一个实施例的用于系统监控的装置的框图。图4所示的系统在整体上由系统400表示。具体地，系统400包括客户端监控装置401，用于监控所述系统的客户端的性能参数；第一判断装置402，用于根据所述客户端的性能参数判断预定的SLA是否得到满足；服务端点定位装置403，用于在第一判断装置的判断结果为否的情况下确定服务端点的IP地址和端口号；应用信息获取装置404，用于获取在服务端点运行的应用信息；第二判断装置405，用于判断相应的监控代理是否已经被部署到该服务端点；监控部署装置406，用于在第二判断装置405的判断结果为否的情况下，向该服务端点部署相应的监控代理；监控激活装置407，用于激活在服务端点上部署的监控代理；服务端点监控装置408，用于监控所述服务端点的性能参数；以及第三判断装置409，用于判断是否需要对服务端点所直接调用的下级服务端点进行监控。进一步，图4所示的装置中的模块401至409分别对应于图2所示的方法中的步骤201至209，在此不再赘述。

图5示出了根据本发明一个实施例的以迭代方式调整系统监控范围的示意图。如图5所示，实线箭头和虚线箭头均表示IT系统内部的调用关系。例如，从“client”节点指向“server”节点的箭头表示“client”节点直接调用“server”节点，也就是说，“client”节点相对于“server”节点而言是“客户端”，而“server”节点相对于“client”节点而言是“客户端”直接调用的“服务端点”。实线箭头表示最终部署的监控范围，而虚线箭头则表示虽然存在这样的调用关系，但是根据本发明提供的技术方案，无需在虚线箭头指向的节点上部署监控。举例而言，首先在“client”节点上部署监控代理，以监控“client”节点的性能参数，发现“client”节点对其所直接调用的“server”节点的响应时间(response time)为800ms，大于SLA中规定的500ms，从而接下来在“server”节点上部署监控代理，以监控“server”节点的性能参数。进一步，当监测得知“server”节点所直接调用的下级“ND2”节点对“server”节点所发出请求的响应时间为900ms，大于SLA中规定的600ms，而“ND1”节点对“server”节点所发出请求的响应时间为500ms，小于SLA中规定的600ms，从而确定只需在“ND2”节点上部署监控代理，而无需在“ND1”节点上部署监控代理。以此类推，最终确定在“client”、“server”、“ND2”、“M2”以及“DB1”节点上部署监控代理，最终找出导致“client”节点性能降低的原因是“DB1”节点中出现了问题。

通过以上对具体实施例的描述，本领域技术人员可以理解，上述的系统、装置和方法可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本实施例的装置、服务器及其单元可以由诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用由各种类型的处理器执行的软件实现，也可以由上述硬件电路和软件的结合实现。

虽然以上结合具体实例，对本发明的利用远程应用处理本地文件的系统及方法进行了详细描述，但本发明并不限于此。本领域普通技术人员能够在说明书教导之下对本发明进行多种变换、替换和修改而不偏离本发明的精神和范围。应该理解，所有这样的变化、替换、修改仍然落入本发明的保护范围之内。本发明的保护范围由所附权利要求来限定。

Claims (16)

1.一种用于系统监控的方法，包括：

监控所述系统的客户端的性能参数；

根据所述客户端的性能参数判断是否需要对所述客户端直接调用的服务端点进行监控；

如果判断结果为是，定位需要被监控的所述服务端点；以及

监控所述服务端点的性能参数。

2.如权利要求1所述的方法，其中根据所述客户端的性能参数判断是否需要对所述客户端直接调用的服务端点进行监控，包括：

如果所述客户端的性能参数不满足预定的与所述客户端相关的服务水平标准，则需要对所述客户端直接调用的服务端点进行监控；以及

如果所述客户端的性能参数满足预定的与所述客户端相关的服务水平标准，则不需要对所述客户端直接调用的服务端点进行监控。

3.如权利要求1或2所述的方法，其中如果判断结果为是，定位所述服务端点包括：

确定所述客户端所直接调用的服务端点的IP地址及端口号；以及

根据所述IP地址及端口号，获取关于在所述服务端点运行的应用的信息。

4.如权利要求3所述的方法，其中监控所述服务端点的性能参数包括：

根据所获取的在服务端点运行的应用的信息，判断与所述应用相对应的监控代理是否已经被部署在所述服务端点；

如果判断结果为是，则激活与所述应用相对应的监控代理；

如果判断结果为否，则向所述服务端点部署并激活与所述应用相对应的监控代理；以及

通过所述监控代理来监控所述服务端点的性能参数。

5.如权利要求1所述的方法，其中监控所述系统的客户端的性能参数包括：

向所述系统的客户端部署并激活监控代理；

通过所述监控代理来监控所述客户端的性能参数。

6.如权利要求1至5任一所述的方法，进一步包括：

根据所述服务端点的性能参数判断是否需要对所述服务端点直接调用的下级服务端点进行监控；

如果判断结果为是，定位需要被监控的所述下级服务端点；以及

监控所述下级服务端点的性能参数。

7.如权利要求3所述的方法，所述应用的信息包括所述应用的名称以及版本号。

8.如权利要求4所述的方法，其中根据所获取的在服务端点运行的应用的信息，向所述服务端点部署与所述应用相对应的监控代理包括：

根据所获取的在服务端点运行的应用的信息，在监控代理元数据映射表中查找对应于该应用的监控代理；以及

向所述服务端点部署所查找到的监控代理。

9.一种用于系统监控的装置，包括：

客户端监控模块，用于监控所述系统的客户端的性能参数；

第一判断模块，用于根据所述客户端的性能参数判断是否需要对所述客户端直接调用的服务端点进行监控；

服务端点定位模块，用于当判断结果为是时，定位需要被监控的所述服务端点；以及

服务端点监控模块，用于监控所述服务端点的性能参数。

10.如权利要求9所述的装置，其中第一判断模块被进一步配置为：

如果所述客户端的性能参数不满足预定的与所述客户端相关的服务水平标准，则需要对所述客户端直接调用的服务端点进行监控；以及

如果所述客户端的性能参数满足预定的与所述客户端相关的服务水平标准，则不需要对所述客户端直接调用的服务端点进行监控。

11.如权利要求9或10所述的装置，其中服务端点定位模块被进一步配置为：

确定所述客户端所直接调用的服务端点的IP地址及端口号；以及

根据所述IP地址及端口号，获取关于在所述服务端点运行的应用的信息。

12.如权利要求11所述的装置，其中服务端点监控模块被进一步配置为：

根据所获取的在服务端点运行的应用的信息，判断与所述应用相对应的监控代理是否已经被部署在所述服务端点；

如果判断结果为是，则激活与所述应用相对应的监控代理；

如果判断结果为否，则向所述服务端点部署并激活与所述应用相对应的监控代理；以及

通过所述监控代理来监控所述服务端点的性能参数。

13.如权利要求9所述的装置，其中客户端监控模块被进一步配置为：

向所述系统的客户端部署并激活监控代理；

通过所述监控代理来监控所述客户端的性能参数。

14.如权利要求9至13任一所述的装置，进一步包括：

第二判断模块，用于根据所述服务端点的性能参数判断是否需要对所述服务端点直接调用的下级服务端点进行监控；

下级服务端点定位模块，用于当判断结果为是时，定位需要被监控的所述下级服务端点；以及

下级服务端点监控模块，用于监控所述下级服务端点的性能参数。

15.如权利要求11所述的方法，所述应用的信息包括所述应用的名称以及版本号。

16.如权利要求12所述的装置，其中服务端点监控模块被进一步配置为：

根据所获取的在服务端点运行的应用的信息，在监控代理元数据映射表中查找对应于该应用的监控代理；以及

向所述服务端点部署所查找到的监控代理。

Images