CN1756190A

CN1756190A - 分布式性能数据采集方法

Info

Publication number: CN1756190A
Application number: CN 200410081135
Authority: CN
Inventors: 沈明达; 李未; 郎昕培; 周刚
Original assignee: Beihang University
Current assignee: Beihang University; Beijing University of Aeronautics and Astronautics
Priority date: 2004-09-30
Filing date: 2004-09-30
Publication date: 2006-04-05
Anticipated expiration: 2024-09-30
Also published as: CN100518079C

Abstract

一种分布式性能数据采集方法，包括：a)定义性能数据的形式化的生成格式的步骤；b)获取性能数据的采集对象及其属性；c)在步骤a)和步骤b)的基础上，根据该性能数据的形式化生成格式生成性能采集任务；d)在步骤c)的基础上，实现性能采集任务到性能数据的转化；e)在步骤c)的基础上，对性能数据采集引擎各模块进行分布协调；f)在步骤d)和步骤e)的基础上，对采集的性能数据的利用和存储到数据库或平面文件中；g)将性能数据通过图形或报表的表现形式呈现给管理人员。根据本发明，通过系统中采集点的分布性，很好的适应了网络规模不断变化的需求，同时也为对被管理网络的流量特征、设备利用情况的研究、分析、预测提供了帮助。

Description

分布式性能数据采集方法

技术领域

本发明涉及性能数据采集方法，尤其涉及应用于IP网络由性能数据采集引擎的各模块执行的分布式性能数据采集方法。

背景技术

性能数据采集方法属于基于先进网络的大型网络测量和管理示范系统范畴，根据ISO(International Organization for standardiztion国际化标准组织)对网络管理的FCAPS定义，对一个大型的复杂网络进行管理，需要进行的性能管理将着眼于大规模IP网络中设备的性能数据的采集，存储，分析流程。

网络管理人员通过网络管理中的性能管理方式获得的性能数据，将有助于网络管理人员通过监控设备的流量和利用情况，发现网络中出现的异常，如设备的故障，设备遭受攻击或者病毒侵入等，而现有的网络管理工具对网络的监控力度不够，一般只提供对对单台或者少量设备的监控，并且对监控的性能数据类型也没有灵活的扩展。

由于网络中的性能数据类型多样，且随着设备类型数量的多样呈海量性的特点，因此不仅满足一般网管的需求，对网络流量特征的研究，预测，提供很大帮助，网络的规模的不断扩展也由采集系统中采集点的分布性能得到很好的解决的性能采集方法的提出已经势在必行。

发明内容

本发明正是为了解决上述问题而提出的。本发明的分布式性能数据采集方法，应用于IP网络由性能数据采集引擎的各模块执行，包括如下步骤：

a)定义性能数据的形式化的生成格式的步骤；

b)利用性能数据采集引擎中的配置数据采集模块TOPDISCOVER获取性能数据的采集对象及其属性的步骤；

c)在步骤a)和步骤b)的基础上，根据该性能数据的形式化生成格式通过性能数据采集引擎中的任务配置模块MISSION_CONFIG生成性能采集任务的步骤；

d)在步骤c)的基础上，通过性能数据采集引擎中的分布式性能采集模块DDCE获取该性能采集任务，并读入内存队列，由多线程实现性能采集任务到性能数据的转化的步骤；

e)在步骤c)的基础上，由性能数据采集引擎中的分布协调中心模块MANAGER根据任务分配算法给各采集点分配性能数据采集任务，并对性能数据采集引擎各模块进行分布协调的步骤；

f)在步骤d)和步骤e)的基础上，对采集的性能数据的利用和存储到数据库或平面文件中的步骤；

g)将性能数据通过图形或报表的表现形式呈现给管理人员的步骤。

根据本发明，通过系统中采集点的分布性，很好的适应了网络规模的不断变化的需求，同时也为对被管理网络的流量特征、设备利用情况的研究、分析、预测提供了很大的帮助。

附图说明

图1为根据本发明的分布式性能数据采集方法总流程图；

图2为性能数据采集任务中的计算公式经过逆波兰得到的后缀表达式计算流程图；

图3为性能采集任务的自动配置流程图；

图4为采集进程的总体结构框图；

图5为采集进程在初始化之后的主控线程的流程图；

图6为图5中采集进程启动时候的初始化的流程图；

图7为数据采集进程中线程函数的流程图；

图8为采集线程流程图；

图9为采集系统结构框图；

图10为分布协调中心MANAGER实施的任务分配算法一的流程图；

图11为分布协调中心MANAGER实施的任务分配算法二的流程图；

图12为控制模块CONTROLLER控制流程图；

图13为性能采集任务到性能数据的转化示意图；及

图14为说明一个任务如何被解释为一个性能数据的框图。

具体实施方式

下面参照附图对本发明的具体实施例进行详细的描述。

在IP网络管理中，性能数据的分类包括：响应时间，吞吐量，利用率，连通度，网络的扩展性。获取这些性能数据便于网络管理人员对网络进行现状监控，故障定位，和未来预测。而这些性能数据都不同程度的可以通过设备MIB信息得到反映。所有符合网管标准的IP设备，都应该：1)提供遵循RFC(Request For Comments，internet研究发展为目的的社区，在一系列的文档中阐述了许多协议和模型的描述，实验性的结论和回顾，几乎所有的internet标准协议都被写成了RFC.)标准的MIB-II(RFC1213定义的MIB的一个结点，该结点定义了所有标准网管协议相关的管理信息，MIB和SMI，SNMP协议并列为简单网络管理协议(simple networkmanagement protocol)框架的三个主要组成部分，MIB定义了可以通过网络管理协议进行访问的管理对象的集合，通常被当作是管理对象的虚拟数据库，管理对象的所有信息被以树形结构组织起来，其中每个信息对象在树上的一个结点可用OID来定位，每个信息对象对应一个具体的实例，每一个实例被绑定了一个值，SNMP协议，是为网络管理服务而定义的应用协议，是网络管理系统和运行在被管理对象上的代理程序进行异步请求和响应的协议，网络管理系统可以通过和代理交换SNMP协议报文，来查询代理所在的被管理对象上的MIB中的相关信息，SMI管理信息结构，是MIB中的信息对象定义和编码，以便协议传输的基础)；2)各厂商自定义的私有MIB信息(许多厂商为了方便用户管理，在MIB中加入了自定义的信息，这些信息一般在MIB中的PRIVATE结点底下)。

基于SNMP，针对网络管理程序为达到性能数据采集存储为目的，本发明提出一个通用的性能数据采集方法，由该方法定义的性能数据采集引擎适用于各种规模的IP网络，本发明实现的性能数据采集总流程如图1所示，包括如下步骤：a)定义性能数据的形式化的生成格式；b)利用性能数据采集引擎中的配置数据采集模块TOPDISCOVER获取性能数据的采集对象及其属性；c)在步骤a)和步骤b)的基础上，根据该性能数据的形式化生成格式通过性能数据采集引擎中的任务配置模块MISSION_CONFIG生成性能采集任务；d)在步骤c)的基础上，通过性能数据采集引擎中的分布式性能采集模块DDCE获取该性能采集任务，并读入内存队列，由多线程实现性能采集任务到性能数据的转化；e)在步骤c)的基础上，由性能数据采集引擎中的分布协调中心模块MANAGER根据任务分配算法给各采集点分配性能数据采集任务，并对性能数据采集引擎各模块进行分布协调；f)在步骤d)和步骤e)的基础上，对采集的性能数据的利用和存储到数据库或平面文件中；g)将性能数据通过图形或报表的表现形式呈现给管理人员。

以下对如图1中所示的分布式性能数据采集总流程进行详细描述。

1.1定义性能数据的形式化的生成格式

1)形式化的定义性能数据采集流程为一个2元组<采集对象，采集参数组>。

2)其中采集对象又对应一个4元组<对象编号，地址，版本，安全认证>。

√对象编号是每一个被监控对象在全网中的唯一编号。

√地址是监控的对象的访问方式，在IP网络中即指，面对的主要设备为网管范围内所有的IP设备如：主机，交换机，路由器等的IP地址。

√版本是使用的SNMP协议版本，迄今为止SNMP已经从V1，V2C发展到了V3C，新的版本不断加入了更好的协议操作方式，并加强了安全性。

√安全认证是保证协议安全运行的方式，现在SNMP中通常用一个SNMP COMMUNITY字段来作为访问的口令字段，在SNMP协议中指定该字段的值将使得代理能够鉴别管理者是否具有访问MIB的权限。

3)采集参数组则定义了具体的性能采集数据根据不同的采集数据类型，所需要的MIB采集OID点，和通过这些OID点计算得到最终性能数据所需要的计算方式，也以一个3元组的形式表示<OID组，计算公式，回存参数>。

√OID组是指获得一个性能数据所需要的MIB树上对应的若干个OID编号。

√计算公式是指由OID取得的值所计算得到性能数值的方式。

√回存方式是指性能数据在数据库，平面文件等介质中存放的格式。

1.2获取性能数据的采集对象及其属性

根据网络的配置管理要求，网管系统必须获取全网所监控设备的配置信息，这些配置信息也作为性能数据采集的基础和准备，使用SNMP协议可以从采集对象的MIB中获取所需要的配置信息，下表是具体性能数据所依赖的配置数据。

性能数据类型	公用需要的配置信息	各性能数据类型需要的配置信息
性能数据类型	公用需要的配置信息	各性能数据类型需要的配置信息	接口流量	IP地址(MIB中的ipAddrTable结点下)Community字段(网	MIB中的端口索引号(该号和物理端口的编号的对应方式遵从RFC2233)的规定Ifinterface-mib、ifmib-mib

设备利用率	络管理人员给定)支持的设备SNMP版本	主机HOST-MIB路由器交换机各厂家的私有MIB
设备利用率		主机HOST-MIB路由器交换机各厂家的私有MIB	协议使用情况	Tcp/ip/icmp/transmission/udp/snmp-mib

为了方便性能数据的存储，我们为所有性能数据指标对应的对象细化并编号，以下为一种建议的分类方式：子网，网段，主机端口，主机，交换机端口，交换机，路由器端口，路由器等，分别为其编制一种数据类型，

子网--网段

+--主机

+--主机端口

+--CPU

+--磁盘

+--交换机

+-交换机端口

+--CPU

+--路由器-路由器端口

每个对象类型将被赋予一个类型编号。这样所有的配置信息就可以按照数据类型来分类存放。

1.2.1获取性能数据采集任务中的采集对象--TOPODISCOVER

TOPODISCOVER是配置数据采集模块，将获取网络中所有被管理对象的属性信息。

√发现的采集对象将赋予全网唯一标识号(OBJECT_INSTANCE)由前缀和序列号组成，前缀标识了设备的类型，如路由器1100交换机1200等而序列号往往按照拓扑发现的顺序依次递增。

因此一个网络中的路由器可以被表示为

11002等，交换机端口15001、15002。从拓扑发现系统的网络设备配置信息表，OBJECT_INSTANCE定位一个设备的一条记录包括设备的IP和OID索引号，如果该设备的父设备有好多和该设备类型相同的兄弟设备，采集该设备性能数据时，即用OID索引来区分这些兄弟设备，比如采集交换机和所有交换机端口信息都在交换机的MIB库中，每个端口在交换机的MIB库中会有一个OID索引号，标识该端口信息所在MIB中的位置。

√SNMP版本通常采取最高版本，对数据支持最全最优先的方式，故因为SNMPV1最多支持32位数据类型，涉及到Gbit流量数值的IF-MIB(用64位计数器来统计流量的一个MIB结点)OID用SNMPV2C协议，其余的任务用SNMPV1。

√所有被管对象上的代理程序SNMP AGENT的社区READ-COMMUNITY将根据用户提供的一个列表进行试探。

TOPODISCOVER将不断的对网络的配置信息进行扫描，获得实时最新的配置信息，一旦有新的设备添加或者删除，将向任务配置模块发送格式如$object_instance：object_type：configure_type：的消息，分别定义了对象编号，对象所属的设备类型和需要对该设备进行的操作类型：删除任务还是添加任务，由于任务的增删不能及时反映到性能数据采集进程，因此必须周期性的由协调中心通知所有控制模块，重新启动所有采集进程。

1.2.2性能数据采集任务中的参数组--PROPERTY_OID

性能数据采集任务中的参数组将被存放在一张数据库表格PROPERTY_OID中，表格中的各个字段就是采集参数组的各个子参数。

√性能数据形式化定义中的OID组，标准MIB存储的被管对象信息相当齐全，这些信息可以通过查询MIB的OID得到，这些信息大多不能真正提供一个网络设备的性能状况(比如说MIB库中大量的是从系统初始化到当前时刻的某个设备信息的统计，管理人员更感兴趣的是一段时间内的变化情况，即两个时间点内的差值)，需要对OID结点请求到的原始进行处理、统计、分析，得到性能数据。

从RMON(MIB中的远程管理结点，提供了很多该RMON结点监控局域网内的统计信息)中参考设备端口的利用率这个性能数据的计算方法为：

UTILIZATION＝((PACKETS*(96+64)+OCTECTS*(8))/INTERVAL*107)*100％

如果不从RMON得到直接提供的这个性能数据，则需通过请求报文数PACKETS、字节数OCTECTS相应的OID，得到路由器端口的收包和收字节等原始数据，并通过以上公式计算得到。

整合成一个性能数据的原始数据列，以OID序列方式成为性能数据采集任务的参数。OID序列形式如OID1；OID2；OID3；OID4；.......这个OID序列是由任务描述表PROPERTY_OID中相应任务的OID前缀序列+端口索引号得到的。

例：路由器某个端口I/O流量入包的OID前缀序列为：

1.3.6.1.2.1.2.2.1.11；1.3.6.1.2.1.2.2.1.12；

这个端口在所有路由器端口中的索引编号为x，就可以得到实际能用的OID序列：

1.3.6.1.2.1.2.2.1.11.x；1.3.6.1.2.1.2.2.1.12.x；

√性能数据采集任务中的计算公式，性能数据采集任务中原始数据计算的公式，采取逆波兰的表示方法，对形如5+((8-2)*3-(2+2*(12-9)+3))的公式，经过逆波兰转化得到的后缀表达式为：

582-3*22129-*+3+-+

结果的计算用到了栈数据结构方式，

例：1+2*4-5转化成124*5+-

把逆波兰表达式的数和符号依次压栈并按照图2所示的后缀表达式计算流程得到计算结果，

例：1 2 4 * 5 + -




	1



2
2	1


	4
2	4
2	1



8
8	1


	5
8	5
8	1



13
13	1




	-12

计算公式和OID序列共同完成一个性能数据的计算。计算公式是形如g2_v0(操作数)g1_v0+(操作符)的逆波兰形式，运算之前，操作数会被OID取得的数值代替，操作数gn_vm符号中，n是采集周期数，m表示用OID序列第m个数值代替。

例：

1)计算交换机端口t1到t2时间内I/O平均入包数(个数/秒)的计算公式为：

((t2单播包+t2非单播包)-(t1单播包+t1非单播包))/(t2-t1)

2)端口收到单播包和非单播包的OID前缀序列为：

1.3.6.1.2.1.2.2.1.11；1.3.6.1.2.2.1.12；

3)加上该端口的索引号x；

1.3.6.1.2.1.2.2.1.11.x；1.3.6.1.2.2.1.12.x；

4)计算公式：((g2_v0+g2_v1)-(g1_v0+g1_v1))/t；

5)转化为任务中存储的计算公式：g2-v0 g2_v1+g1_v0 g1_v1+-t；

分别两个时间点取得OID的数值，第一周期用1.3.6.1.2.1.2.2.1.11.x，采集到的单播包的数值替代g1_v0符号，用1.3.6.1.2.1.2.2.1.12.x，采集到的非单播包的数值替代g1_v1符号，第二周期用1.3.6.1.2.1.2.2.1.11.x，的值代替g2_v0，1.3.6.1.2.1.2.2.1.12.x代替g2_v1，如果任务参数中采集间隔是T，两次采集oid的时间间隔T就可以代替t。

6)接下来按照压栈计算算法，得到结果就是性能数据交换机端口I/O平均入包数的值。

√数据回存数据库的方式，对SQL语句

insert into tablename values(object_instance，value0，taskid sequence，nextvalue)计算结束时，把table_name，object_instance，value0，taskid替换成性能数据存储表名，对象号，性能数据和任务号，执行插库操作。

√采集频率(INTERVAL)，两个周期差值的任务两次采集的时间间隔，在计算公式中直接代替t符号。一般网络流量监控程序中定义的采集频率为5分钟，10分钟，15分钟，许多网络设备上系统提供的CPU，LOAD等数据是一般也取这些时间间隔的平均值。这样一个采集对象每天产生的数据量为60/5*24＝288个。

1.3根据性能数据的形式化格式生成性能采集任务

由上节性能数据的各属性我们可以定义采集任务列表的各字段为<ip，community，version，cyckept，interval，oids，formula，sql>，下面描述如何把任务属性和采集对象组装成这些采集任务。

1.3.1性能数据到性能采集任务的抽象

一个性能数据可以抽象成一条任务，抽象成的任务达到了以下目的：

√便于向性能数据的转化

任务化决定了，一条任务是在一个时间点完成对一个性能数据的采集，还是在一个时间段完成对一批性能数据的采集。考虑到消息传递的简易度和任务调整的灵活性，如图13所示，本系统的一项任务完成以一种频率一个时间段内对一个性能数据指标的采集。

任务中的参数已经自包含转化得到性能数据的方法，即计算公式，采集层次的一个采集模块从获取任务列表之后，任务参数必须包含采集总时间、间隔，采集的设备对象，获得原始数据，计算性能数据的方法，数据库中性能数据存储表的位置和字段格式。

下表列举了从任务列表获得的参数：

图14说明了一个任务如何被解释为一个性能数据的。

1.3.2采集任务配置模块--MISSION_CONFIG

网络管理者通过任务配置模块MISSION_CONFIG把采集对象和性能数据参数结合起来，组装成被性能采集程序解释执行的性能采集任务。自动配置功能实现了默认任务参数为所有设备所有性能数据的批量配置任务，手动配置功能则加入了与管理者的交互，管理者使用手动配置可以选择为特定的设备或者特定的性能数据配置任务。系统初始时都将启用任务配置功能，因此配置时为任务分配的任务叫母任务，任务号为0，执行母任务的采集进程叫做母进程。自动配置时，采集模块将从全网络配置数据接口中获取采集任务分配模块获得待配置设备的OBJECT_INSTANCE编号，和设备的配置信息，包括采集任务中对应的IP和OID索引号，设备类型标识OBJECT_ID，根据OBJECT_ID可以从系统内部表PROPERTY_OID中查询到该设备对应的所有任务类型，以及这些任务类型对应的的任务的CYCLE(周期)，OIDS(该任务需要采集的OID序列)，FORMULA(公式)，和SQL(回存数据库用到的sql语句)，再加上自动配置时候默认的或手动设定的COMMUNITY(SNMP社区，自动配置时候默认配置为PUBLIC)，SNMP VERSION(SNMP版本，自动配置时默认配置为SNMPV1版本)INTERVAL(采集周期，自动配置时候默认配置为300seconds)LASTING TIME(持续时间，自动配置时默认为infinite)，即可以按照笛卡尔积：

IP×OID INDEX×CYCLE×OIDS×FORMULA×SOL×COMMUNITY×SNMPVERSION×INTERVAL的形式组合成性能采集任务。

图3为性能采集任务的自动配置流程图。手动配置即是在中间加上询问用户的过程，用户可以屏蔽自己不感兴趣的设备，SNMP版本或者性能数据类型的任务的配置。配置大部分性能采集任务时，系统的处理方法类似，主机多CPU和多磁盘任务比较特殊，这两种任务类型是操作系统相关的，不仅一个设备会配置多个性能数据采集任务，而且同一种任务类型不同的操作系统任务取的OID和计算公式也不一样。

1.4性能采集任务到性能数据的转化

DDCE模块获取到性能采集任务，并读入内存队列，由多线程从队列中获取任务，通过图4中的流程实现从性能采集任务到性能数据的转化。系统层次最底层的采集层分布着N个采集模块的进程，其中同一台采集机上一个控制模块可能会控制其中的一些进程。采集进程启动时候接受控制模块的启动参数作初始化工作，主控线程作性能数据采集任务的读取、控制消息的处理工作，即从数据库得到分配任务放入性能数据任务队列，然后启动采集线程把性能采集任务解释为性能数据。

性能采集任务的任务号，配置模块在配置任务的时候给任务分配的任务号(TASKID)为0，因此在任务存储表中大部分的任务是TASKID为0的母任务，当有新任务被加入或修改的时候，整个系统的协调模块会分配一个任务表中没有的TASKID(取现有所有TASKID中最大值加一)给这个任务，采集进程通过任务号就可从数据库中获得配置模块制作好的任务。

1.4.1数据采集进程--DDCE

图5为采集进程在初始化之后的主控线程的流程图。

采集进程在初始化之后的主控线程主要流程包括如下步骤：解析进程的参数为(任务号，任务类型，采集频率，采集总时间)；根据任务号、任务类型读入任务队列并根据任务数计算所需要采集线程数；根据采集频率设置TIMER，根据采集总时间设置周期数；启动线程数目相应的采集线程函数和回存线程，开始采集；判断是否收到消息；如果收到消息，收到WM_TIMER到一周期结束了，主线程把所有采集线程唤醒；转回判断是否收到消息的步骤；如果未收到消息，回存线程从结果队列中取出结果回存数据库；接受控制模块发出的关闭消息时1作数据库清理工作，2通知控制模块作相应的恢复工作；退出采集进程。

采集层的功能封装在可执行文件(COLLECTOR.EXE)中，协调层直接控制模块以SHELL(操作系统给进程传参的一种方式)参数的方式启动为采集进程。

采集层采集进程启动时接受协调层直接控制模块的控制模块SHELL传递的参数，参数格式为：

√任务号TASK_ID。

√所在采集控制模块分配到的任务类型MISSION_TYPE1，MISSION_TYPE2--->MISSION_TYPEN。

√采集频率INTERVAL。

√采集总时间LASTING TIME。

由于使用了TIMER机制，需要在主线程中创建一个窗体，窗体句柄作为START和RUN方法的参数调入，同时这个窗体也将接受关闭程序的消息。创建窗体的名字形式为TASK+A(TASKID)，例如母进程创建窗体，则调用createwindow(task0)。

图6为图5中采集进程启动时候的初始化的流程图。

采集进程启动时候的初始化流程包括如下步骤：设置数据库连接字符串的步骤；设置操作记录表用的sql语句的步骤；连接数据库的步骤；关闭数据库的步骤；设置线程数的步骤；主控线程读取任务队列的步骤；把主线程创建的窗体句柄传入采集线程的步骤；启动采集线程并进入周期性消息处理的步骤。

面向对象的封装，类missionmachine是对性能采集任务的封装，只要配置任务数据库表格式没变，这个类就能被很好的重用，尤其是扩展了采集总时间，采集频率，和采集线程几个参数。使得性能数据采集任务的定制更加灵活。

1.4.2采集进程中的线程函数

图7是数据采集模块流程图中的线程函数的展开。

线程函数展开的流程如下：开始判断任务堆栈是否不为空；如果不为空，则从任务堆栈中取任务；从被管对象取回oid对应原始数据(get_oid_group)；根据公式计算得到性能数据(computefunction)；把性能数据填充result数据结构，并放入队列；如果任务堆栈为空，则线程自己挂起自己。上述公式如果为单周期的计算公式，则直接计算；如果为双周期的计算公式，根据前后两次的采集结果计算，计算完后用第二次的采集结果替代前一次。

类missionmachine最主要的两个方法是FillAttri()和采集线程函数fnThread()。

√类missionmachine的方法Fillattr中，从数据库读取性能数据任务放入任务队列missionqueue中(一个标准模板库stl的stack存放的结果是任务mission)。我们使用堆栈来存放任务，是考虑到如果是FIFO的任务队列，那么SNMP响应越快的任务将在队列中不断提前，响应越慢或者超时的任务将不断后移，形成拖尾现象，这样使得队列完成的时间长度越来越长，最终可能超过采集周期，因此我们使用先进后出的堆栈不断来回倒任务，使得越快完成的任务在堆栈前顶端和底部，且会不断向中间压缩，实际情况这种效果很好。

√方法start中，采集线程函数fnThread和结果回存线程storagethread将被启动，通过missionqueue.pop()，多个fnThread线程函数从队列中争抢任务，然后进行任务的解释。采集函数fnthread使用SNMP++库，这个库把SNMP的所有信息结构进行了面向对象的封装。函数的流程如下：

1)解析从队列中弹出的任务，得到采集对象的IP地址，COMMUNITY，和OID序列。

2)用get_oid_group函数进行SNMP的REQUEST操作。

get_oid_group主要过程如图8所示。

3)至此oid序列结果已保存在vb数组中(vb是数值绑定，一个vb可以看成是一个<oid名，oid值>对)，调用计算函数ComputeFunction计算并把结算结果插入结果队列。计算函数ComputeFunction计算两个周期任务的时候，上一周期采集的值被保存，和本周期的采集值一起进行计算，计算完成之后，把本周期采集到的数值，保存供下一周期用。计算主要采用逆波兰式用栈结构计算mission中formula对应的计算公式，具体算法在”性能数据采集任务中的参数组”一节中已经讨论，不再赘述。

4)性能数据计算完毕后和数据库回存sql组成result结构，压入resultqueue(result的queue，这是一个FIFO的队列)；回存线程中弹出result结构，requltqueue.pop()，result中的性能数据以sql指定的方式回存数据库。具体在下节展开。

1.4.3性能采集任务结果的回存

回存线程函数storagethread不断对resultqueue进行查询。

√队列非空，则从队列中取出结果，由result结构中的性能数据值和当前时间代替sql中相应符号并完成插库操作。

√队列为空，至少在下一个周期第一次采集任务未完成之前，不会有结果插入结果队列，为防止对结果队列无谓的查询，睡眠一定时间。

实际情况中我们采用公平队列来存放回存的任务，也就是说，每个采集线程完成任务后，将依次获得一个递增回滚的队列号，根据这个队列存入结果队列，而一个队列对应的一个线程从中获取任务回存，这种机制使得所有任务队列能保持长度均匀，最大限度的保证了现有线程数能在最短时间内完成回存。

1.5性能数据采集引擎各模块的分布协调

下面参照图9对性能数据采集引擎各模块的分布协调进行描述。

TOPODISCOVER，MISSION_CONFIG，DDCE，MANAGER，CONTROLLER，DATAPROCESSOR，MISSIONBROWSER

其中TOPODISCOVER，MISSION_CONFIG，DDCE为性能采集系统的核心模块，配置信息采集模块，任务配置，分布式性能数据采集模块，前面已经介绍过这些模块的功能，包括配置数据的收集，采集任务的配置，和对该模块负责的网域中所有设备的轮询，把性能采集任务解释为性能数据，并存入数据库。

MANAGER为分布协调中心，负责性能采集任务的配置，在各个DDCE之间的任务分配，控制DDCE的启动和结束

CONTROLLER为控制模块，负责传递MANAGER和DDCE之间的通信消息。

MISSIONBROWSER为可以嵌入到其他网管系统的任务浏览模块，用户可以通过该模块实施性能采集任务的浏览，添加和修改。

采集任务的分布方式，能保证系统的容错性，各个管理域之间流量分离从而避免采集流量对骨干设备造成干扰，但是各个模块之间的协调必须通过互相通信来解决，协调中心监听来自接口层的消息，实现具体的任务协调功能。

系统分布特性的体现：

√透明性，对采集系统来说，只要控制模块启动并注册，即可接受协调中心的管理，控制模块必须满足的条件是，能把地址信息存入数据库，协调中心能够通过该地址能够与控制模块通信，并且控制模块能在文件系统中搜索到采集模块。

√容错性，TOPODISCOVER中提到，协调中心会周期性重新启动采集进程，此时如果协调中心与控制模块通信失败后，查询该模块负责采集的性能数据类型的所在的表如果没有采集数据或者最近的采集时间离现在已大大超过采集周期，认为该设备已经发生故障了，那么必须重新调用任务分配算法，然后再重新启动各个采集单元的采集进程。

√效率，在5钟采集周期的前提下，采集主机的CPU处理能力有限的情况下，为了满足网络规模不断增长的需要，只要不断加入新的采集点，注册控制模块就能分担掉新增加的任务量。

1.5.1分布协调中心实施的任务分配算法--MANAGER

MANAGER负责将任务被公平的分配到所有的采集点上，分配的算法必须考虑计算机处理能力的权重，和每种性能采集任务可能花费的时间长短所对应的权重，由于配置数据会根据网络实际的状况和被配置信息采集模块扫描到的周期不断更改，因此MANAGER将按照间隔一定时间周期对任务进行重新分配。分配算法将被重新调度。任务被首先按照自治域的编号，然后按照CONTROLLER进行分配。

一个中大规模的网络管理系统，一个采集周期内采集任务量往往会达到十万级，而性能数据任务类型也会有几十个，下面讨论协调层任务配置模块所有任务分布到采集机上的时候，应该遵循的原则，并给出了规划的目标函数：

原则：相同性能数据任务类型分配到一个采集点上，采集点分配的任务定义为其拥有的资源，则需作以下定义，某种任务类型的任务数目和任务解释时间的乘积决定了该资源的相对大小，平均资源为所有资源总和除以采集点数。

计算机按照计算能力承担任务数，计算能力的标准可以是CPU，内存大小。

目标函数：假设每台计算机的资源分配是RESOURCEi，承担的任务数为TASKi的话，总任务数是TOTALTASK，应使每台计算机承担的任务数与计算能力相当：

OBJECT＝MIN(TASKi-TOTALTASK*RESOURCEi/(RESOURCE1+….RESOURCEi))

算法描述

假设所有采集点的计算能力都是一样的，比如有相同CPU和内存资源，原则是每个采集点，作为任务的采集机，其使用的计算负载是相同的。

图10为任务分配算法一的流程图。下面参照图10对算法一进行描述：

有i个任务类型，每个任务的数目为Ni，每个任务的计算时间为Ti，采集点的数目为M，则每个采集点分配资源averageresource，得到总体的需计算的资源totalresource。

算法中以一定的粒度，为采集点分配资源，当资源超过平均资源时，则结束对它的分配，开始下一台采集点的分配，实际系统中考虑任务的亲和性，即当一台采集机由于故障停止采集只会影响到特定的几种类型任务的采集，把粒度划定为某种任务类型，即把为一台采集机分配的任务以一种任务类型的数目为递增数，当分配的任务超过系统所有采集任务的平均数时，继续下一台采集机任务的分配。

算法简化实际系统的采集任务数比较多，相对来讲每个任务的数在总任务数中占的比例比较小，因此颗粒度比较小，不容易出现一个消耗计算资源很大的任务(或者任务数很多，或者计算时间很长)把一台管理机填满的情况，实际计算的时间，SNMP通信的延时+CPU进行公式运算的时间，公式运算的时间有微小的差别，SNMP通信的时间的差别更微小，因此可以把Ti看成是一样的。

图11为任务分配算法二的流程图。下面参照图11对任务分配算法二进行描述。

算法一在采集机比较多的时候，平均能容纳资源数较小时，则当某些任务类型的任务数目比较多时，容易造成个别采集机任务数过多的不均衡状况。此时用时间复杂高但效果更好的算法二：

先把任务按照资源大小从大到小排列，剩余空间定义为平均资源减去该采集点已分配的资源数，取剩余空间最大的采集点，进行资源分配，由于任务数是收敛的，每次分配都是最佳的，因此可以在总体达到最佳，实际系统即采用了这种分配策略，可以达到较理想的结果。

分布式性能数据采集引擎的分布协调中心MANAGER进行的任务的迁移和协调工作时序包括如下工作：分布协调中心会周期性重新启动采集进程，分布协调中心判定某个采集点发生故障时，那么必须重新调用所述任务分配算法，然后再通知采集点，由控制模块CONTROLLER重新启动分布式性能采集模块TOPDISCOVER。

分布协调中心对任务浏览模块MISSIONBROWSER任务添加和修改请求作相应处理。

1.5.2任务浏览器--MISSIONBROWSER

增加任务，增加任务操作出现在两种时候，一种是系统进入初始运行状态前，必须由任务配置模块完成自动配置和手动配置，添加任务号为0的母任务，以便系统能正常运作，一种在系统运行中，管理者为特定设备添加特定性能数据采集任务时候。协调中心接受请求后会查询这些请求对应的控制模块，转发这些任务增加请求，控制模块然后启动相应的采集进程。

修改任务，修改任务发生在系统运行时，当管理者发现一些原先配置任务的任务参数比如频率，非母任务的运行总时间，SNMP版本等，需要被改变时，那么他们就会通过客户端提出改变任务的请求，协调中心会查询这些请求对应的控制模块，转发这些任务改变请求，控制模块处理消息时，如果这个性能数据只有母进程在采集，让母任务休眠，同时执行新的任务，如果对一条任务已有新任务在执行，把原先的任务删除，替代以新的任务。新任务执行完他的总周期的时候，新任务所在的进程将会向它的控制模块发送任务完毕通知，使得相应休眠的母进程被唤醒。

1.5.3控制模块启动流程--CONTROLLER

图12为控制模块的控制流程图。

控制模块CONTROLLER在开始的时候取得本机IP，创建共享内存段，并填入该IP值作为标识控制模块已经被启动的标志，从而以保证一台主机只能运行一个控制模块，模块等待用户输入端口号，把IP和端口组成的序偶在数据库中注册。

在数据库中查找通知协调中心的联系方式，通知其有新的控制模块注册并加入采集系统。

监听协调中心的协调请求，接受协调中心的报文，解析报文获取请求类型，对系统中出现的增加、修改或告警变频任务请求，进行相应的采集进程的启动，重启操作。

当该采集点需要退出系统，则用户直接关闭该控制模块，模块接受退出请求时先把该采集模块在数据库中作注销操作。

1.5.4性能数据处理模块--PROCESSOR

该模块负责对性能数据的转移，初步处理，并为性能采集提供适当的反馈。

√性能数据可以按照二级存储的方式存储在数据库中，一级存储的表格较小，只存储最近性能周期的数据，便于用户检索，二级表为所有的历史信息，表格大小，呈线性增长。性能数据处理模块必须负责信息的转移工作，对历史信息的清理和整合工作，

整合算法如下：

1)基于时域的方法

对一个性能数据的数据序列。a1，a2，a3，a4，a5…

定义一个系数阶跃系数为b如果(a2-a1)/a1＜b那么把a2纳入舍略的对象，然后算(a3-a1)/a1依次类推，如果(an-a1)a1＞b那么an替代a1的位置，计算(an+1-an)an＞b，这样我们得到的阶梯函数将比原来少大量的阶跃点，但是大的阶跃还是能够被捕获。

按照性能数据的定义，可以把所有被舍略的数据求平均值得到整个时间段内的平均流量，更能反映实际的流量状况。

2)基于频域的方法

用一个低频过滤器过滤，高频率信号。原来a1，a2，a3，a4，a5…

用10分钟的频率过滤得到a1，a3，a5，…，用15分钟的频率过滤得到a1，a4，a7…

上述方法会造成信息的损失，按照性能数据的定义，我们用a1+a2/2可以得到原来a1，a2时间段内和内的平均流量。用一个性能数值代替a1和a2所在时间段内的两个数值。

√性能数据初步处理，性能数据在转移途中可以经过一个过滤器，该过滤器定义了一定的规则，性能数据超过了过滤器定义的规则，由性能数据处理模块发送告警信息。管理人员可以定义不同的告警级别和对应的逻辑条件，按照级别从高到低的方式进行匹配，匹配成功了则发送告警，

例如：下表为告警条件匹配顺序

告警级别1 A：a1＜x＜a2
告警级别1 A：a1＜x＜a2	告警级别2 B：b1＜x＜b2
告警级别3 C：c1＜x＜c2	告警级别2 B：b1＜x＜b2

如果性能数值位于b1-b2中间，且不属于a1-a2的范围，那么将发送2级告警。在实际网管需求中需要对设备进行批量的设置告警，或者对所有的设备都设置告警，那么同一级别的告警单个设备的优先级应该大于批量设置大于所有该类型设备的，在实际实现中，可以把对批量设备的条件映射为对单个设备进行的群操作，

因此匹配的顺序为：

告警级别1 A0：a1＜x＜a2单个设备

告警级别1 A1：a5＜x＜a6所有设备
告警级别1 A1：a5＜x＜a6所有设备
告警级别2 B0：b1＜x＜b2单个设备
告警级别2 B0：b1＜x＜b2单个设备	告警级别2 B1：b5＜x＜b6所有设备
	告警级别2 B1：b5＜x＜b6所有设备
	告警级别3 C0：c1＜x＜c2单个设备
告警级别3 C1：c5＜x＜c6所有设备	告警级别3 C0：c1＜x＜c2单个设备

上表为加入对所有设备设置告警条件的匹配顺序。

√性能告警变频是加入了特定的反馈机制的特殊的修改任务请求。性能数据将被性能告警系统取出，与按照一定规则设定的阀值进行比较，如果发现有异常，为了验证这种异常，性能告警系统会通知性能数据采集系统，增加采集频率，使得告警系统对性能数据的捕捉更敏感。

例如某路由器端口的入包平均流量(PACKET PER SECOND是由前后两次比较入包数的差值除以采集周期得到)在一个周期内的数值达到0值，告警系统在捕获到这个异常后，希望这种异常最好通过密集采集能被马上排除，要求加大采集频率，如采集周期从默认周期300s缩短至30s，于是告警系统会向采集系统的协调层发送路由器端口入包流量任务的变频告警通知。变频告警和任务修改请求类似，加入反馈是由于告警系统在变频任务完毕时，为了识别变频任务需要回传告警系统提供的一个内部任务号作确认。

采集层直接控制模块与采集模块的联系最密切。直接控制模块功能被封装在可执行文件CONTROLLER.EXE中，一台采集主机上只能运行一个采集控制进程，从另一个角度来说，由于采集控制模块直接负责对采集层采集进程的调用，一台采集主机的计算资源，也由它来负责分配调度。

1.6性能数据的利用和存储。

性能数据无论被存储在数据库中，还是平面文件中，都必须遵循一定的格式，这样有利于给其他系统提供接口，也便于对数据进行进一步的分析处理。

每张性能数据存储表的表结构可以是以下方式：<性能数据对应对象编号，数值，采集时间>。而每张性能表的含义可以以下XML文件的形式对外提供接口，则性能数据存储表的DTD格式为：

<！ELEMENT性能数据存储表情况(表的描述*)>

<！ELEMENT表的描述(设备类型，性能数据描述，性能数据表表名)>

<！ELEMENT设备类型(#PCDATA)>

<！ELEMENT性能数据字段描述(#PCDATA)>

<！ELEMENT性能数据表表名(#PCDATA)>

1.7性能数据的表现

性能数据可以通过图形和报表两种表现方式呈现给网络管理人员。其中报表可以对最初的性能数据作一定的规整，比如做一天，一周，一个月的平均流量，一个设备所有接口的平均流量，一个子网所有设备的平均流量等，通过曲线作图，可以直观的观察某个设备对象在一段时间周期内性能数值变化的趋势。

根据本发明的分布式性能数据采集方法，其分布式的特性使采集系统具有透明性，容错性，高效率的优点，通过系统中采集点的分布性，很好的适应了网络规模的不断变化的需求，同时也为对被管理网络的流量特征、设备利用情况的研究、分析、预测提供了很大的帮助。

以上对本发明的分布式性能数据采集方法进行了详细的描述，本发明并不局限于上述实施例，很显然本领域的技术人员在对本发明进行审查或实践的过程中可以作出多种修改或改变，本发明旨在覆盖这些修改或改变。

Claims

1、一种分布式性能数据采集方法，由该方法定义的性能数据采集引擎适用于各种规模的IP网络，其特征在于：由该性能数据采集引擎的各模块执行的步骤，包括：

a)定义性能数据的形式化的生成格式的步骤；

2、如权利要求1所述的分布式性能数据采集方法，其特征在于：

所述数据采集引擎包括以下模块：分布协调中心MANAGER，作统一的性能任务分配和迁移，并集中协调其他模块的工作时序；分布式性能数据采集模块DDCE，用于配置数据的采集；控制模块COTROLLER，负责传递分布协调中心MANAGER和分布式性能数据采集模块DDCE之间的通信消息；任务浏览模块MISSIONBROWSER，用户可以通过该模块实施性能采集任务的浏览，添加和删除；配置信息采集模块TOPDISCOVER，获取网络中所有被管理对象的属性信息；任务配置模块MISSION_CONFIG，把采集对象和性能数据结合起来，组装成被性能采集程序解释执行的性能采集任务；性能数据处理模块PROCESSOR，负责对性能数据的转移，初步处理，并为性能数据采集提供适当的反馈；数据库模块DATABASE，用于存储性能数据，性能任务。

3、如权利要求1所述的分布式性能数据采集方法，其特征在于：

所述步骤a)中性能数据的形式化的生成格式被定义为一个二元组<采集对象，采集参数组>，所述采集对象又对应一个4元组<对象编号，地址，版本，安全认证>，所述采集参数组以一个3元组<OID组，计算公式，回存参数>的形式表示。

4、如权利要求1所述的分布式性能数据采集方法，其特征在于：

所述步骤c)中，包括自动配置功能和手动配置功能，自动配置功能可以由任务配置模块MISSION_CONFIG按照迪卡尔积：IP×OID INDEX×CYCLE×OIDS×FORMULA×SQL×COMMUNITY×SNMPVERSION×INTERVAL的形式，根据相应的性能数据对设备属性，采集参数的不同要求，自动地组合成性能采集任务，自动配置默认对全网所有被管理对象自动配上所有相关性能数据的采集任务，手动配置就上述任务的迪卡尔积形式中的每个属性，加入与用户的询问交互，允许用户调整这些属性的值。

5、如权利要求1所述的分布式性能数据采集方法，其特征在于：

在步骤d)中，系统层次的最底层分布着的N个采集进程(运行着的采集模块)做以下工作，

在采集进程启动时候接受控制模块的启动参数作初始化工作，

主控线程作性能数据采集任务的读取、控制消息的处理工作，

采集线程作性能采集任务到性能数据的解释工作。

6、如权利要求5所述的分布式性能数据采集方法，其特征在于，

所述采集进程启动时候的初始化流程包括如下步骤：

设置数据库连接字符串的步骤；

设置操作记录表用的sql语句的步骤；

连接数据库的步骤；

关闭数据库的步骤；

设置线程数的步骤；

主控线程读取任务队列的步骤；

把主线程创建的窗体句柄传入采集线程的步骤；

启动采集线程并进入周期性消息处理的步骤。

7、如权利要求5所述的分布式性能数据采集方法，其特征在于，

所述采集进程在初始化之后的主控线程主要流程包括如下步骤：

解析进程的参数为(任务号，任务类型，采集频率，采集总时间)；

根据任务号、任务类型读入任务队列并根据任务数计算所需要采集线程数；

根据采集频率设置TIMER，根据采集总时间设置周期数；

启动线程数目相应的采集线程函数和回存线程，开始采集；

判断是否收到消息；

如果收到消息，收到WM_TIMER到一周期结束了，主线程把所有采集线程唤醒；

转回判断是否收到消息的步骤；

如果未收到消息，回存线程从结果队列中取出结果回存数据库；

接受控制模块发出的关闭消息时1作数据库清理工作，2通知控制模块作相应的恢复工作；

退出采集进程。

8、如权利要求7所述的分布式性能数据采集方法，其特征在于，

所述采集线程函数展开的流程如下：

开始判断任务堆栈是否为空；

如果不为空，则从任务堆栈中取任务；

根据任务描述从被管对象取回oid对应原始数据(函数get_oid_group)；

根据公式计算得到性能数据(函数computefunction)；

采集的线程函数，采集性能数据把结果放入结果队列；

如果任务堆栈为空，则线程自己挂起自己；

上述公式如果为单周期的计算公式，则直接计算；如果为双周期的计算公式，根据前后两次的采集结果计算，计算完后用第二次的采集结果替代前一次。

9、如权利要求2所述的分布式性能数据采集方法，其特征在于：

所述分布协调中心MANAGER遵从性能数据分配算法将任务公平的分配到所有的采集机上，遵循的原则是：相同性能数据任务类型分配到一个采集点上，采集点分配的任务定义为其拥有的资源，则需作以下定义，某种任务类型的任务数目和任务解释时间的乘积决定了该资源的相对大小，平均资源为所有资源总和除以采集点数，所采取的分配算法为：

算法一，采集点被分配的资源超过它应获得的平均资源，则结束对它的分配，开始下一个采集点的分配；

算法二，把任务按照资源大小从大到小排列，剩余空间定义为平均资源减去该采集点已分配的资源数，取剩余空间最大的采集点，进行资源分配。

10、如权利要求9所述的分布式性能数据采集方法，其特征在于：

分布式性能数据采集引擎的分布协调中心MANAGER进行的任务的迁移和协调工作时序包括如下工作：

分布协调中心会周期性重新启动采集进程，分布协调中心判定某个采集点发生故障时，那么必须重新调用所述任务分配算法，然后再通知采集点，由控制模块CONTROLLER重新启动分布式性能采集模块TOPDISCOVER；

11、如权利要求2所述的分布式性能数据采集方法，其特征在于：

性能数据处理模块PROCESSOR做性能数据的初步处理，包括对历史信息的清理和整合工作，作性能数据初步处理，性能数据在转移途中经过一个过滤器，该过滤器定义了一定的规则，性能数据超过了过滤器定义的规则，由性能数据处理模块发送告警信息。