CN102938710B - 用于大规模服务器的监控系统和方法 - Google Patents

Abstract

本发明公开了一种用于大规模服务器的监控方法，其包括采集每台被监控的服务器的运行数据；根据预先存储的运行数据过滤策略，从所采集的该被监控的服务器的运行数据中过滤出需要报警的运行数据；根据预先存储的报警策略，对过滤出的需要报警的运行数据进行报警；以及将报警结果存储在报警历史存储器中,以便查看并监控多台服务器的运行状况。本发明还公开了一种用于大规模服务器的监控系统。利用本发明，便于监控位于不同地点的大规模服务器，而且随着被监控的服务器的不断增加，可以扩展以适应所监控的服务器的大规模扩展。

Description

用于大规模服务器的监控系统和方法

技术领域

本发明涉及计算机技术领域，具体涉及一种用于大规模服务器的监控系统和方法。

背景技术

随着网络的快速发展，出现了需要为大量用户服务的网络系统。这些网络系统具有分布在各个地址的大量服务器，而这些服务器通常构建为集群的方式来为用户服务。随着提供服务的服务器越来越多，如何对这些服务器的性能进行监控成为目前需要迫切解决的问题。

目前比较普遍采用的监控系统主要有Cacti监控系统和Ganglia监控系统。

Cacti监控系统是基于PHP、MySQL、SNMP及RRDTool开发的网络流量监测图形分析工具。它用PHP语言实现，并通过RRDTool而使使用者感觉更方便。它主要是通过snmp获取数据，然后用RRDTool储存和更新数据，当用户需要查看数据的时候用RRDTool生成图表呈现给用户，但并不需要了解RRDtool复杂的参数。因此，snmp和RRDTool是cacti的关键。其中snmp关系着数据的收集，RRDTool关系着数据存储和图表的生成。

Cacti除了基本的snmp流量和系统资讯监控外，还可外挂Scripts及加上模板来作出各式各样的监控图。另外，MySQL配合PHP可以存储一些变量数据并对变量数据进行调用，如：主机名、主机IP、snmp团体名、端口号、模板信息等变量。

Cacti将snmp获取的数据存储在RRDTool生成的rrd文件中。RRDTool对数据的更新和存储就是对rrd文件的处理，rrd文件是大小固定的档案文件（Round Robin Archive），它能够存储的数据笔数在创建时就已经定义。因此，它存在着可扩展性差、可复用性低、可靠性低的问题，另外，由于只能存储少量的历史数据，所以难以查看长期的历史数据。

Ganglia监控系统是UC Berkeley发起的一个跨平台可扩展的，高性能计算系统下的开源集群监控系统，它是基于分层设计，用于测量数以千计的节点。Ganglia的核心包含gmond、gmetad以及一个Web前端。它主要用来监控系统性能，如：cpu、mem、硬盘利用率，I/O负载、网络流量情况等，通过曲线很容易见到每个节点的工作状态。

然而，Ganglia没有内置的通知系统，需要另外开发通知报警机制才能实现通知报警功能，另外，其采用RRDTool工具绘制图形，消耗服务器大量内存。还有，由于只能存储少量的历史数据，所以难以查看长期的历史数据。

现有的监控系统都没有考虑到在用于监控大规模服务器时会面临的负载问题，也没有考虑到如何使得监控系统可以扩展来适应所监控服务器的大规模扩展。此外，现有的监控系统没有考虑到当服务器的被监控数据越来越多时，如何对监控数据进行提取和分析，以便快速向管理员报警。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的用于大规模服务器的监控系统和相应的监控方法。

依据本发明的一个方面，提供了一种用于大规模服务器的监控系统，其包括：多个数据收集客户端，每个数据收集客户端布置在每台对应被监控的服务器中，适于采集所述被监控的服务器的运行数据，并发送该运行数据；信号过滤处理器，适于接收由所述数据收集客户端发送的运行数据，且根据预先存储的运行数据过滤策略过滤出需要报警的运行数据；报警处理器，其接收所述信号过滤处理器过滤出的需要报警的运行数据，且根据预先存储的报警策略进行报警；以及报警历史存储器，耦接到所述报警处理器，并存储所述报警处理器的报警结果的历史记录。

可选地，本发明的用于大规模服务器的监控系统还包括信号中转器。该信号中转器适于接收来自一个或者多个数据收集客户端所发送的数据，并将其转发给所述信号过滤处理器。

可选地，在本发明的用于大规模服务器的监控系统中，每个报警策略包括唯一的报警策略ID以及报警条件，而且所述报警处理器包括：数据存储模块，适于根据所述信号过滤处理器所过滤出的数据来构造报警数据表，所述报警数据表包括多个数据节点，每个数据节点上链接有环形双向链表，环形双向链表包括多个链表节点，其中每个数据节点由需要报警的运行数据中的机器域名和报警策略ID来标识，而与每个数据节点相关联的环形双向链表的每个链表节点中存储有具有相同机器域名和相同报警策略ID的需要报警的运行数据，所述多个链表节点根据其上的需要报警的运行数据的时间戳值大小进行链接排列；以及报警模块，根据每个数据节点中的报警策略ID选择相应的报警策略，并根据所选择的报警策略来确定与数据节点相关联的环形双向链表中的需要报警的运行数据是否达到所选择的报警策略中的报警条件，当确定满足报警条件时进行报警。

根据本发明的另一方面，提供了一种用于大规模服务器的监控方法。该监控方法包括：采集每台被监控的服务器的运行数据；根据预先存储的运行数据过滤策略，从所采集的该被监控的服务器的运行数据中过滤出需要报警的运行数据；根据预先存储的报警策略，对过滤出的需要报警的运行数据进行报警；以及将报警结果存储在报警历史存储器中,以便查看并监控多台服务器的运行状况。

根据本发明的用于大规模服务器的监控系统和方法可以监控位于不同地点的大规模服务器，而且随着被监控的服务器的不断增加，可以扩展以适应所监控的服务器的大规模扩展。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明的一个实施例的用于大规模服务器的监控系统的框图;

图2示出了根据本发明的一实施例的报警数据表的示意图；以及

图3示出了根据本发明的一个实施例的用于大规模服务器的监控方法。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本发明提供一种监控多台服务器的监控系统，其可以监控位于不同地点的大规模服务器，而且随着被监控的服务器的不断增加，可以扩展以适应所监控的服务器的大规模扩展。

图1示出了根据本发明的一个实施例的用于大规模服务器的监控系统100的框图。如图1所示，本发明的用于大规模服务器的监控系统100包括多个数据收集客户端111、信号过滤处理器130、和报警处理器150。

每个数据收集客户端111分别布置在一被监控的服务器110中，采集被监控的服务器110的运行数据，并将该运行数据发送给信号过滤处理器130。这里，被监控的服务器110可位于本地也可以位于远程。另外，为了清楚起见，图1中仅示出了一个被监控的服务器及置于其中监控其运行状况的一数据收集客户端111。

可选地，每个数据收集客户端111可以包括采集模块1111和发送模块1112。其中，采集模块1111对该数据收集客户端111所在的被监控的服务器110的各运行数据进行采样，并生成运行数据包。这里，采集模块1111所生成的运行数据包的结构可以为“信息长度+json格式的字符串”。json格式的字符串可以包括：表示采集各监控数据项的时间戳；各监控数据项的ID号；各监控数据项本次的值；以及各监控数据项的值的数据类型。例如，json格式的字符串可以采用如下格式：

上述字符串中的"time"表示采集当前数据的时间，“host”表示当前所监控的服务器，"data"后的部分为采集模块1111所生成的运行数据包的结构。在"data"部分中的("item_ID","item_value","data_type")中，

item_ID表示这个监控数据项的ID号；

item_value表示本次这个监控数据项取得的值；

data_type表示这个监控数据项的值的数据类型（其中data_type=1表示此监控数据项的采样结果是数值，data_type=2表示此监控数据项的采样结果是字符串）。

通常，将各监控数据项的ID号、其所代表的含义、以及监控数据项的值的数据类型制作成一个数据列表以统一进行管理。表一示出了这样的数据列表的一个例子：

表一

采样的监控数据项ID	含义	数据类型
			1	系统buffers大小	数值
……	……	……
			37	每秒merge写次数	数值
64	NIC0比特接收速率	数值
			……	……	……

发送模块1112将所述采集模块1111生成的运行数据包发送给信号过滤处理器130。例如，可以将采集模块1111生成的如下运行数据包发送给信号过滤处理器130：

0000000718{"time":"1331693080","data":[["37","12.22","1"],["64","14300","1"],……，["35","5.95","1"]]，"host":"mon1.ops.ccp.qihoo.net"}

其中，

0000000718表示这个数据包总长度为718；

time表示发送数据包的数据收集客户端所在的服务器时间；

data表示采样数据，采样数据列举在其后面的[]中，即，["37","12.22","1"]，["64","14300","1"]，……，["35","5.95","1"]。

host表示所监控的服务器110，其后为该服务器110的域名。

其中，["37","12.22","1"]表示一监控数据项在数据列表中的监控数据项ID号为37，采样该监控数据项得到的数据为12.22，该数据的值的数据类型是数值。从上述表一中可以查到，监控数据项ID37为“每秒merge写次数”。当采样到的数据为12.22时，表示被监控服务器110中在此时每秒merge写次数为12.22次。

另外，上述采集模块1111和发送模块1112可以采用Perl语言来实现，从而无需额外安装其他依赖，适合大规模部署。

信号过滤处理器130接收由数据收集客户端111发送的运行数据，根据预先存储的运行数据过滤策略过滤出需要报警的运行数据，并将满足运行数据过滤策略的数据转发至报警处理器150。

例如，一策略可以采用如下格式：

服务器的hostname#报警策略ID#报警组#监控数据项ID#监控数据项的英文名#阈值比较符号#阈值#多少时间内#多少次计数需要报警#最多报警多少次#报警策略名。

上述策略将运行数据过滤策略和报警策略设置在了一起，其中“#服务器的hostname#报警策略ID#报警组#监控数据项ID#监控数据项的英文名#阈值比较符号#阈值#”为运行数据过滤策略；“多少时间内#多少次计数需要报警#最多报警多少次#报警策略名”为报警策略，关于报警策略，后面再详细描述。

下面给出具体的一个策略的样例：

"mdb02v.add.vjc.qihoo.net#118#add_ops#22#SERVER_LOADAVG#>=#32#2#4#5#1\xb7\xd6\xd6\xd3\xb8\xba\xd4\xd8"。

其中，“mdb02v.add.vjc.qihoo.net#118#add_ops#22#SERVER_LOADAVG#>=#32#”为运行数据过滤策略。与上述给出的运行数据过滤策略的格式对比可知，在上述样例中，被监控的服务器的域名为mdb02v.add.vjc.qihoo.net，被监控的监控数据项ID为22，对应的监控数据项为SERVER_LOADAVG，当SERVER_LOADAVG的值高于32（即阈值比较符号为大于等于，阈值为32）时，需要把数据包传送至报警处理器。

这里，信号过滤处理器130只会用到运行数据过滤策略的一部分，即：“#服务器的hostname#报警策略ID#报警组#监控数据项ID#监控数据项的英文名#阈值比较符号#阈值#”。

另外，运行数据过滤策略可以存储于信号过滤处理器130中，也可以本发明的监控系统100根据需要另外配置一策略存储器170，将一个或者多个运行数据过滤策略存储在策略存储器170中。所述信号过滤处理器130根据其所接收到的运行数据中包含的信息，从所述策略存储器170中获取一个或多个对应的运行数据过滤策略，将所述运行数据中满足相应运行数据过滤策略的数据过滤出来并发送至报警处理器150。

经信号过滤处理器130过滤出来的数据不仅可以发送至报警处理器150并存储在其中，也可以本发明的监控系统100另外配置一与信号过滤处理器130耦接的报警数据存储器140，将经信号过滤处理器130过滤出来的数据存储在该报警数据存储器140中。

这时存储在报警处理器150或报警数据存储器140中的每条需要报警的运行数据可以包括：机器域名、报警策略ID、监控数据项ID、故障值、和时间戳。另外，每条需要报警的运行数据可以采用如下的数据结构：

机器域名#报警策略ID#监控数据项ID#故障值#时间戳。

下面给出一个需要报警的运行数据的样例：

"dlgame2.safe.bjt.qihoo.net#345#44886#0.000000#1341570490"

"dl10.safe.jjt.qihoo.net#345#44886#0.000000#1341568984"

其中，dlgame2.safe.bjt.qihoo.net表示被监控的服务器的域名；报警策略ID为345，监控数据项ID为44886，故障值=0.000000（其代表某一故障，也是来自运行数据包的数据监控值），时间戳为1341570490。

类似地，在需要报警的运行数据的样例"dl10.safe.jjt.qihoo.net#345#44886#0.000000#1341568984"中，dl10.safe.jjt.qihoo.net表示被监控的服务器的域名；报警策略ID为345，监控数据项ID为44886，故障值为0.000000（其代表某一故障），时间戳为1341568984。

由上面所述可知，域名为dlgame2.safe.bjt.qihoo.net的服务器和域名为dl10.safe.jjt.qihoo.net的服务器存在着同样的问题。

另外，每条需要报警的运行数据不限于包括如上所列数据项，实际上也可以根据需要包括其中的几项或者另外包括更多项。

报警处理器150接收信号过滤处理器130过滤出的需要报警的运行数据，根据预先存储的报警策略进行报警。当本发明的监控系统100配置有报警数据存储器140时，信号过滤处理器130过滤出的需要报警的运行数据先存储在报警数据存储器140中，这时，报警处理器150每隔一定时间从报警数据存储器140中读取数据。

如前面所述，所述报警策略可以与前面的运行数据过滤策略设置在一起，采用如前所述的格式：

服务器的hostname#报警策略ID#报警组#监控数据项ID#监控数据项的英文名#阈值比较符号#阈值#多少时间内#多少次计数需要报警#最多报警多少次#报警策略名。

其中，报警处理器150所采用的报警策略包括位于后面的部分“#多少时间内#多少次计数需要报警#报警策略名”的报警条件以及前面的报警策略ID，即，在一段预定的时间内出现故障值预定次数时需要报警。另外，也可以在该报警条件中进一步增设报警条件“最多报警多少次#”，即为“#多少时间内#多少次计数需要报警#最多报警多少次#报警策略名”。这样，当报警处理器150的报警次数超过某一次数时，就不再报警。在上述策略中，其中的“#服务器的hostname#报警策略ID#报警组#监控数据项ID#监控数据项的英文名#阈值比较符号#阈值#”是信号过滤处理器130所采用的运行数据过滤策略，这在前面已经进行了描述。

可选地，报警策略与运行数据过滤策略也可以不设置在一起，二者可以单独存储。另外，可选地，报警策略可以存储在策略存储器170中，也可以存储在报警处理器150中。为了便于对策略进行统一管理，可以将报警策略与运行数据过滤策略设置在一起并存储在策略存储器170中。

可选地，运行数据过滤策略与报警策略可以由工作人员通过网页从网页数据库存储的策略中调出而插入到策略存储器170中。具体地，如前所述，当数据收集客户端111将运行数据传送至信号中转器120中，信号中转器120将运行数据临时存储到临时显示数据存储器中，临时显示数据存储器中的运行数据可以传送至网页，以供工作人员进行实时监测，并根据所监测到的运行数据而从网页数据库中调用对应的策略并将其插入到策略存储器中。

可选地，报警处理器150可以包括数据存储模块1501和报警模块1502。数据存储模块1501可以每隔一定时间，读取信号过滤处理器130所过滤出的数据，根据信号过滤处理器130所过滤出的数据来构造报警数据表。

图2示出了根据本发明的一实施例的报警数据表200的示意图。如图2所示，报警数据表200包括多个数据节点210，每个数据节点210上链接有环形双向链表220，为了图示清楚起见，图2中将环形双向链表220画在报警数据表200之外，实际上，环形双向链表220位于报警数据表200之内。环形双向链表220上有多个链表节点。在报警数据表200中，每个数据节点210由需要报警的运行数据中的机器域名和报警策略ID来标识，而与每个数据节点210相关联的环形双向链表220的每个链表节点中存储有具有相同机器域名和相同报警策略ID的、需要报警的运行数据，多个链表节点根据其上的需要报警的运行数据的时间戳的值的大小在环形双向链表220中依次链接排列。

想特别说明的是，在信号过滤处理器130过滤出的需要报警的运行数据中，即使机器域名相同，但是报警策略ID不同，也会形成不同的数据节点210，即，同一服务器因为报警策略ID不同而会有不同的数据节点210。另一方面，即使报警策略ID相同，但是机器域名不同，也会形成不同的数据节点210。只有机器域名和报警策略ID都相同的数据位于一个数据节点210，并分布在与该数据节点210对应的一有序的环形双向链表220中。每当一个数据进入报警数据表200中，该数据就被分配到相应的数据节点210，并把该数据挂载到环形双向链表220中与该数据中的时间戳相对应的位置。

在环形双向链表220中，可以设定某一点为标准时间戳的链表节点，然后将各数据按时间戳的值从小到大或从大到小自标准时间戳的链表节点按顺时针或逆时针方向进行排列。例如，如图2所示，在环形双向链表220中，规定链表节点2200为标准时间戳的链表节点，链表节点按顺时针方向时间戳的值逐渐增大，从链表节点2200开始逆时针方向与其最邻近的链表节点2205为时间戳的值最大的链表节点；而从链表节点2200开始顺时针方向与其最邻近的链表节点2201为时间戳的值最小的链表节点。2202、2203、2204为其时间戳的值大于2201的时间戳的值而小于2205的时间戳的值的、且时间戳的值依次增大的三个数据。图2中只以环形双向链表220中包含5个数据为例，在实际中环形双向链表220中可以包含更少或更多的数据。每当有新的数据进入时，就根据其时间戳的值将其插入到环形双向链表220中的对应位置。

报警模块1502根据每个数据节点210中的报警策略ID选择相应的报警策略，并根据所选择的报警策略来确定与数据节点210相关联的环形双向链表220中的需要报警的运行数据是否达到所选择的报警策略中的报警条件，当确定满足报警条件时进行报警。例如，当报警条件为N分钟出现M次（其中N和M是大于等于1的整数）则进行报警时，从环形双向链表220中时间戳的值最大的地方开始依次取时间N分钟内的数据，将所取出的数据个数与M进行比较，如果所取出的数据个数大于或等于M，则表示达到报警条件，报警模块1502可以通过发Email和/或短信进行报警；如果所取出的数据个数小于M，则表示还不满足报警条件，不需要进行报警。由此可知，通过使用环形双向链表220可以很快地计算得知是否达到报警条件。

另外，根据本发明的用于大规模服务器的监控系统100还可以包括报警历史存储器160，该报警历史存储器160耦接到报警处理器150，存储报警处理器150的报警结果的历史记录。这里，报警历史存储器160可以由将数据存储在hbase数据库中，由于hbase数据库是一个分布式的数据库，能够很好地扩展存储。

另外，根据本发明的用于大规模服务器的监控系统100还可以包括信号中转器120。其中，信号中转器120主要负责数据的转发，其将来自一个或者多个数据收集客户端111的数据转发到信号过滤处理器130。通常，数据收集客户端111可能分布在位于不同地方的被监控的服务器110中，而且极有可能与信号过滤处理器130位于不同的地方，例如，数据收集客户端111位于内网中，而信号过滤处理器130位于外网中，另外，被监控的服务器110可能会有上千台甚至上万台，所以数据收集客户端111也相应地会有上千台甚至上万台，这样信号过滤处理器130接收的数据量会比较大，因此，通过在数据收集客户端111与信号过滤处理器130之间设置信号中转器120可以有效地实现数据在不同区域之间的传输，以保证数据能够被传输和/或可以被高质量地传输。另外，信号中转器120还可以把接收到运行数据进行缓存、分类汇总，然后传送至相应的信号过滤处理器130。

另外，根据本发明的用于大规模服务器的监控系统100还可以包括临时显示数据存储器180和历史数据存储器190。

临时显示数据存储器180与信号中转器120耦接，接收信号中转器120转发的数据并临时存储该数据，将运行数据实时显示在工作人员可以查看的网页上，由工作人员监测各服务器的运行状态；临时显示数据存储器180可以将数据存储在redis数据库中，因为redis数据库是一个key-value存储系统，其支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)和zset(有序集合)。使得能够利用key-value快速查询，利用链表结构（如前面所述的报警数据表200）实现报警。

历史数据存储器190与信号中转器120耦接，接收信号中转器120转发的数据并长期存储该数据,以供查询。

在图1所示的本发明的用于大规模服务器的监控系统100中，只以具有包括数据收集客户端111、信号中转器120、信号过滤处理器130、报警数据存储器140和报警处理器150的一组部件为例进行说明，实际上为了保证在即使出现故障时监控系统100也能正常运行，可以冗余设置包括数据收集客户端111、信号中转器120、信号过滤处理器130、报警数据存储器140、报警处理器150的另一组部件，该冗余设置的另一组部件中各部件之间的连接关系以及该另一组部件与其它部件之间的连接关系与前面所述的那组部件一样，这里不再详细描述。这样，当一组部件出现故障时，可以切换为另一组部件工作，从而保护监控系统的正常运行。

下面通过一个具体的例子对本发明进一步详细描述。

本发明对机器域名为mdb02v.add.vjc.qihoo.net的服务器110进行监控，在服务器110中设置有数据采集客户端111以收集该服务器110的运行数据，并将其以如下格式的数据包经信号中转器120转发给信号过滤处理器130：

0000000086{"time":"1331693080","data":[["22","24.42","1"]],"host":"mdb02v.add.vjc.qihoo.net"}。这里，0000000086表示这个数据包总长度为86；"time"表示发送数据包的数据收集客户端所在的服务器时间为1331693080；"data"的["22","24.42","1"]中，22表示监控数据项ID，24.42为采样该监控数据项得到的值，1表示该数据的值的数据类型是数值。

然后，信号过滤处理器130从策略存储器170中读取如下运行数据过滤策略和报警策略：

"mdb02v.add.vjc.qihoo.net#118#add_ops#22#SERVER_LOADAVG#>=#20#2#4#5#机器负载过高"。

该策略中各项的含义如下：

mdb02v.add.vjc.qihoo.net#，表示被监控的服务器的域名，即报警机器；

118#，表示报警策略ID为118，每个报警策略包括唯一的报警策略ID以及报警条件；

add_ops#，表示报警组，即报警策略ID所在的报警组；

22#，表示监控数据项ID为22，不同的监控数据项ID对应不同的监控的内容；

SERVER_LOADAVG#，表示监控数据项名称；

>=#，表示比较符号为>=；

20#，表示比较阈值为20；

2#，表示比较时间片（time slice）为2分钟,这里时间的单位为分钟；

4#，表示阈值次数为4；

5#，表示最大报警次数为5；

机器负载过高，表示报警策略名称

在上述策略中，前部分“mdb02v.add.vjc.qihoo.net#118#add_ops#22#SERVER_LOADAVG#>=#20#”为运行数据过滤策略，其表示对域名为mdb02v.add.vjc.qihoo.net的服务器的进行监控，其第22项的监控数据项表示被监控的服务器的机器负载是否出现异常，采用的报警策略对应的报警策略ID为118。当该服务器的机器负载大于等于20时，需要将该被监控的服务器的运行数据过滤出来，以“机器域名#报警策略ID#监控数据项ID#故障值#时间戳”的数据结构存储于报警数据存储器140中。根据该运行数据过滤策略，从前面数据采集客户端111所传送的数据包中包含的data″：[[″22","24.42","1"]]可知，监控数据项为22的监控数据项的值为24.42，这已经符合大于等于20的阈值条件，于是把这个数据包放到报警数据存储器140中。

在上述策略中，后部分“2#4#5#机器负载过高”为报警策略，其表示如果2分钟内有4次这样的情况出现，就发Email或短信进行报警，最多进行5次报警，报警内容为“机器负载过高”。

报警处理器150从策略存储器170中获取上述报警策略，每隔一定时间，从报警数据存储器140中读取需要报警的数据包，然后数据存储模块1501将读取的数据包根据机器域名mdb02v.add.vjc.qihoo.net和118（即，报警策略ID）构造hash值（即，数据节点），并将这个数据包按照时间戳的值的大小顺序地插入到与该数据节点对应的有序环形双向列表中，然后从环形双向列表220中时间戳的值最大的地方开始向时间戳的值变小的方向取时间在2分钟内的数据，如果取得的数据大于或者等于4条，报警模块1502访问报警接口发出短信报警，然后把报警结果存储到报警历史存储器160（mysql）中。环形双向列表中的链表节点的数量及每个链表节点上存储的运行数据随着时间的变化也可能会变化。报警处理器不断地根据报警策略从环形双向列表中获取数据，并在满足报警条件时进行报警。但根据前述的报警条件，当报警超过5次时，报警模块1502不再报警。

在本发明的监控多台服务器的监控系统中，数据收集客户端主动采集被监控的服务器的运行数据，避免了cacti无法采集其他机房内网机器数据的缺点，而且避免了snmp协议不够可靠，snmp协议无法采集足够精细数据的缺陷。

另外，本发明的监控多台服务器的监控系统采用信号中转器，通过信号中转器可以设置内网外网多路通道，从而使得数据收集客户端能够在复杂的网络环境中都能够采集到数据。例如在数据收集客户端只有内网，并且无法访问外网的情况下，可以通过信号中转器将数据收集客户端所采集的数据从内网传送至设置在外网中的信号过滤处理器。

还有，本发明的监控多台服务器的监控系统中的各部件可以根据需要相应地增设数台或更多台，以适应所监控的服务器的数量的扩展及产生的数量的巨增。

还有，本发明的监控系统支持监控数据项监控，使得工作人员能够很方便的设置报警处理整个服务器集群的异常情况。系统使用多种方式展示数据，使得工作人员能够轻松观察自己管理的集群服务器的当前状态。

总之，本发明的监控系统和监控方法能够实现消除单点、负载均衡、平行扩展、模块复用、可靠性强的有益效果。

本发明还提供一种监控多台服务器的监控方法，其监控网络中的多台服务器的运行状况，当出现异常时及时进行报警。本发明的监控方法甚至可以用于监控上千台甚至上万台服务器的运行状况，而且便于进一步扩展。

图3示出了根据本发明的一个实施例的监控多台服务器的监控方法300，其起始于步骤S310，在步骤S310，采集每台被监控的服务器的运行数据，具体地，对被监控的服务器的运行数据进行采样，并生成预定格式的运行数据包。所述预定格式可以为：“信息长度+json格式的字符串”，其中json格式的字符串包括：表示采集各监控数据项的时间戳；各监控数据项的ID号；各监控数据项本次的值；以及各监控数据项的值的数据类型。具体参照前面关于采集模块1111部分的描述。

随后，在步骤S320，根据预先存储的运行数据过滤策略，从所采集的该被监控的服务器的运行数据中过滤出需要报警的运行数据。每条需要报警的运行数据可以包括：机器域名、报警策略ID、监控数据项目ID、故障值、时间戳，并且可以采用数据结构：机器域名#报警策略ID#监控数据项ID#故障值#时间戳，具体参见前面关于需要报警的运行数据的描述。另外，关于运行数据过滤策略的说明，具体参见前面关于运行数据过滤策略的说明，为了简洁起见，这里不再详细描述。

随后，在步骤S330，根据预先存储的报警策略对过滤出的需要报警的运行数据进行报警。

具体地，首先，根据过滤出的需要报警的运行数据来构造报警数据表，报警数据表包括多个数据节点，每个数据节点上链接有环形双向链表，其中每个数据节点由需要报警的运行数据中的机器域名和报警策略ID来标识，而与每个数据节点相关联的环形双向链表的每个链表节点中存储有具有相同机器域名和报警策略ID的需要报警的运行数据，多个链表节点根据其上的需要报警的运行数据的时间戳的值的大小进行链接排列。

然后，根据每个数据节点中的报警策略ID选择相应的报警策略，并根据所选择的报警策略来确定与数据节点相关联的环形双向链表中的需要报警的运行数据是否达到所选择的报警策略中的报警条件，当确定满足报警条件时进行报警。具体地，报警策略中的报警条件可以包括监控数据项在预定时间段内出现超过第一预定阈值的次数达到或者多于第一预定次数就报警的信息，如前面所描述的，例如当报警策略为“2#4#机器负载过高”时，表示如果2分钟内有4次这样的情况出现，就发Email或短信进行报警。这时，根据环形双向链表中需要报警的运行数据的时间戳的值获取在2分钟内的链表节点,如果链表节点的数量大于或者等于所述4，则进行报警。

这里，每个报警策略包括唯一的报警策略ID以及报警条件。另外，关于报警策略的具体说明参见前面关于报警处理器的描述的部分，这里不再详细说明。

可选地，报警策略中的报警条件还可以包括报警次数达到第二预定次数不再报警的信息，这样，在步骤S330之后，还可以包括步骤S340，在步骤S340，确定报警次数是否达到第二预定次数，当报警次数达到第二预定次数时，则进入步骤S350，不再报警。例如，当报警策略为“2#4#5#机器负载过高”时，如在步骤S330中所述，2分钟内有4次这样的情况出现，就进行报警，在步骤S340中，当判断报警次数达到5次时，则进入步骤S350，不再报警，当判断报警次数未达到5次时，则执行步骤S330。

可选地，本发明的监控方法300还可以包括步骤S360：将报警结果存储在报警历史存储器中,以便工作人员查看并监控多台服务器的运行状况。这样，在工作人员不在现场而没有听到报警或者及时看到报警结果的情况下，可以通过查看报警历史存储器中存储的报警结果信息而很快得知是否有异常情况出现。

需要说明的是，图3所示的方法并不限定按所示的各步骤的顺序进行，可以根据需要调整各步骤的先后顺序，另外，所述步骤也不限定于上述步骤划分，上述步骤可以进一步拆分成更多步骤也可以合并成更少步骤。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器（DSP）来实现根据本发明实施例中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序（例如，计算机程序和计算机程序产品）。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (17)

1.一种用于大规模服务器的监控系统，包括：

多个数据收集客户端，每个数据收集客户端布置在每台对应被监控的服务器中，适于采集所述被监控的服务器的运行数据，并发送该运行数据；

信号过滤处理器，适于接收由所述数据收集客户端发送的运行数据，且根据预先存储的运行数据过滤策略过滤出需要报警的运行数据；以及

报警处理器，其接收所述信号过滤处理器过滤出的需要报警的运行数据，且根据预先存储的报警策略进行报警；并且，所述报警处理器包括：数据存储模块，适于根据所述信号过滤处理器所过滤出的数据来构造报警数据表，所述报警数据表包括多个数据节点，每个数据节点上链接有环形双向链表，所述环形双向链表包括多个链表节点，其中每个数据节点由需要报警的运行数据中的机器域名和报警策略ID来标识，而与每个数据节点相关联的环形双向链表的每个链表节点中存储有具有相同机器域名和相同报警策略ID的需要报警的运行数据，所述多个链表节点根据其上的需要报警的运行数据的时间戳值大小进行链接排列，以及报警模块，根据每个数据节点中的报警策略ID选择相应的报警策略，并根据所选择的报警策略来确定与数据节点相关联的环形双向链表中的需要报警的运行数据是否达到所选择的报警策略中的报警条件，当确定满足报警条件时进行报警；

报警历史存储器，耦接到所述报警处理器，并存储所述报警处理器的报警结果的历史记录。

2.如权利要求1所述的监控系统，还包括：

信号中转器，适于接收来自一个或者多个数据收集客户端所发送的数据，并将其转发给所述信号过滤处理器。

3.如权利要求2所述的监控系统，还包括：

临时显示数据存储器，连接到所述信号中转器，并且适于临时存储所述信号中转器转发的数据；以及

历史数据存储器，连接到所述信号中转器，并适于长期存储所述信号中转器转发的数据。

4.如权利要求1-3中任一个所述的监控系统，其中，

所述数据收集客户端包括：

采集模块，其对该数据收集客户端所在的服务器的各运行数据进行采样，并生成运行数据包；以及

发送模块，其发送所述采集模块生成的运行数据包。

5.如权利要求1-3中任何一项所述的监控系统，其中，

所述运行数据包括：

表示采集各监控数据项的时间戳；

各监控数据项的ID号；

各监控数据项本次的值；以及

各监控数据项的值的数据类型。

6.如权利要求1-3中任何一项所述的监控系统，还包括：

策略存储器，其存储有一个或者多个运行数据过滤策略；

其中，所述信号过滤处理器从所述策略存储器中获取所述一个或者多个运行数据过滤策略，将所述运行数据中满足该运行数据过滤策略的数据过滤出来并发送至报警处理器。

7.如权利要求6所述的监控系统，其中，

所述策略存储器还存储有一个或者多个报警策略，以及

所述报警处理器从所述策略存储器中获取所述一个或者多个报警策略，并根据所述一个或者多个报警策略判断是否需要对所述信号过滤处理器过滤出的需要报警的运行数据进行报警处理。

8.如权利要求1所述的监控系统，还包括：

报警数据存储器，耦接到所述信号过滤处理器,并存储所述信号过滤处理器过滤出的需要报警的运行数据。

9.如权利要求8所述的监控系统，其中，

所述报警数据存储器存储的每条需要报警的运行数据包括：机器域名、报警策略ID、监控数据项ID、故障值、和时间戳，其中，

机器域名是被监控是否存在异常的机器的域名；

报警策略ID对应于预定的报警策略；

监控数据项ID对应于被监控机器的一项运行指标；

故障值为监测到的机器的监控数据项的异常数据；和

时间戳为监测到机器的监控数据项的异常数据的时间。

10.如权利要求1所述的监控系统，其中所述报警策略中的报警条件包括监控数据项在预定时间段内出现超过第一预定阈值的次数达到或者多于第一预定次数就报警的信息，以及

所述报警模块根据环形双向链表中需要报警的运行数据的时间戳值获取在预定时间段内的链表节点,如果链表节点的数量大于或者等于所述第一预定次数，则进行报警。

11.如权利要求1或10所述的监控系统，其中，

当所述报警模块报警次数超过第二预定次数时，所述报警模块不再报警。

12.一种用于大规模服务器的监控方法，其包括：

采集每台被监控的服务器的运行数据；

根据预先存储的运行数据过滤策略，从所采集的该被监控的服务器的运行数据中过滤出需要报警的运行数据；

根据预先存储的报警策略，对过滤出的需要报警的运行数据进行报警；以及

将报警结果存储在报警历史存储器中,以便查看并监控多台服务器的运行状况；

其中，所述根据预先存储的报警策略对过滤出的需要报警的运行数据进行报警的步骤进一步包括：根据过滤出的需要报警的运行数据来构造报警数据表，所述报警数据表包括多个数据节点，每个数据节点上链接有环形双向链表，所述环形双向链表包括多个链表节点，其中每个数据节点由需要报警的运行数据中的机器域名和报警策略ID来标识，而与每个数据节点相关联的环形双向链表的每个链表节点中存储有具有相同机器域名和报警策略ID的需要报警的运行数据，所述多个链表节点根据其上的需要报警的运行数据的时间戳值大小进行链接排列；

并且，所述根据预先存储的报警策略对过滤出的需要报警的运行数据进行报警的步骤进一步包括：

根据每个数据节点中的报警策略ID选择相应的报警策略，并根据所选择的报警策略来确定与数据节点相关联的环形双向链表中的需要报警的运行数据是否达到所选择的报警策略中的报警条件，当确定满足报警条件时进行报警。

13.根据权利要求12所述的监控方法，所述采集该被监控的服务器的运行数据的步骤包括：

对被监控的服务器的运行数据进行采样，并生成预定格式的运行数据包。

14.根据权利要求12或13所述的监控方法，所述所采集的运行数据包括：

表示采集各监控数据项的时间戳；

各监控数据项的ID号；

各监控数据项本次的值；以及

各监控数据项的值的数据类型。

15.根据权利要求12所述的监控方法，其中

每条需要报警的运行数据包括：机器域名、报警策略ID、监控数据项目ID、故障值、和时间戳。

16.如权利要求12所述的监控方法，其中所述报警策略中的报警条件包括监控数据项在预定时间段内出现超过第一预定阈值的次数达到或者多于第一预定次数就报警的信息，

所述确定满足报警条件时进行报警的步骤包括：所述根据环形双向链表中需要报警的运行数据的时间戳的值获取在预定时间段内的链表节点,如果链表节点的数量大于或者等于所述第一预定次数，则进行报警。

17.如权利要求12所述的监控方法，其中所述报警策略中的报警条件还包括报警次数达到第二预定次数的信息，

所述确定满足报警条件时进行报警的步骤还包括：当报警次数达到第二预定次数时，则不再报警。