发明内容
本发明的目的是提供一种通用性能告警服务的方法和装置,解决各种类型的网络管理系统对于通用性能告警服务的易用性以及支持功能可扩展性需求。本发明采用的技术方案如下:
一种通用性能告警服务的方法和装置,包括步骤:
定义通用性能指标对象和通用告警规则对象的数据存储结构;
接收对网元的关键性能指标和告警规则的增、删、改配置信息,保存为通用性能指标对象和通用告警规则对象;
与数据服务提供方的北向接口建立通讯连接,收集与网元关键性能指标有关的性能数据;
对所收集性能数据做数据归一化处理;
根据归一化的性能数据,计算所配置网元关键性能指标的值;
判断计算出的性能指标值是否符合配置的告警规则,如果符合则生成性能告警,并保存为历史性能数据。
优选的,通用性能指标对象可按照类型定义为各个性能指标组。
优选的,从网管应用层设置配置文件或者提供用户交互界面,根据应用需求随时可对网元的关键性能指标和告警规则进行增、删、改配置。
优选的,所述告警生成规则可以包括阈值告警规则和/或趋势告警规则。
优选的,所述配置的告警规则还包括告警后处理规则,在根据告警生成规则生成性能告警后,进一步判断所生成性能告警是否符合配置的告警后处理规则,如果符合则进行告警后处理。
优选的,所述告警后处理规则可以包括告警级别筛选规则、告警抑制规则、风暴抑制规则和/或告警清除规则。
优选的,所述收集性能数据的方法可以是,访问数据库方式,通过SQL语句从数据服务提供方的数据库获取所述性能数据;读取文件方式,通过从数据服务提供方写的文件获取所述性能数据;通过建立消息队列缓冲机制,采用向数据服务提供方订阅和收发消息的方式获取所述性能数据。
优选的,将所产生的性能告警信息上报给网管应用层,便于呈现、通知或处理所述性能告警。
优选的,接收查询告警配置的请求或者查询性能告警的请求,从数据库中取出所配置的关键性能指标、告警规则或性能数据,返回给网管应用层。
本发明还提出一种提供性能告警服务的装置,包括:
通用性能数据定义单元,用于定义通用性能指标对象和通用告警规则对象的数据存储结构;
性能指标与告警规则配置接收单元,用于接收网管应用层配置的关键性能指标和告警规则,保存为通用性能指标对象和通用告警规则对象;
性能数据收集单元,与数据服务提供方的北向接口建立通讯连接,收集与网元关键性能指标有关的性能数据;
归一化处理单元,将性能数据收集单元收集来的性能数据的数据格式进行归一化处理,转为统一的数据类型和格式;
性能指标计算处理单元,根据所述配置的网元关键性能指标的计算表达式,并根据所述归一化处理的性能数据,计算关键性能指标的值;
告警判断与告警生成单元,根据性能指标与告警规则配置单元所设置的告警规则,以及由性能指标计算单元所计算出的关键性能指标值,判断关键性能指标值是否符合配置的告警规则,如果性能指标值符合告警规则,生成性能告警,并保存为历史性能数据。
优选的,还包括性能指标与告警规则配置设置单元,从网管应用层设置配置文件或者提供用户交互界面,根据应用需求随时可对网元的关键性能指标和告警规则的增、删、改进行配置。
优选的,所述性能告警生成规则可以包括阈值告警规则和趋势告警规则。
优选的,性能指标与告警规则配置单元还包括配置告警后处理规则,并包括告警后处理判断与生成单元,进一步判断所产生性能告警是否符合配置的告警后处理规则,如果符合则进行告警后处理。
优选的,所述告警后处理规则可以包括告警级别筛选规则、告警抑制规则、风暴抑制规则和告警清除规则。
优选的,性能数据订阅与收集单元还包括:通讯连接模块,用于与外部南向接口或数据采集系统建立通讯连接;访问数据库模块,通过SQL语句从数据服务提供方的数据库获取所述性能数据;读取文件模块,通过从数据服务提供方写的文件获取所述性能数据;消息队列缓冲模块,通过收发消息和消息队列缓冲机制,向外部数据服务提供方发出订阅请求与收集性能数据。
优选的,还包括告警上报单元,将所产生的性能告警信息上报给网管应用层,便于呈现、通知或处理所述性能告警。
优选的,还包括查询单元,用于接收网管应用层查询告警配置的请求,从数据库中取出所配置的关键性能指标和告警规则,返回给网管应用层。
本发明技术方案可作为各种类型的网络管理系统的中间件来使用,很好地解决了网络管理系统用户的易用性问题,不同运营商有不同的管理体制,建设网络管理系统时可以根据不同运营商的需求,建设满足自身管理需求的网络管理系统的应用,使用本发明技术方案就可以将网络管理系统的应用部分与内部的系统实现部分完全隔离开来。同时,本发明技术方案用于提供给各种类型的网络管理系统使用,为各种类型的网络管理系统提供了通用的访问入口和返回信息的出口,也提供了与外部数据采集系统接口建立通用连接的通讯机制,通过提供关键性能指标和告警规则的可配置性,解决了各种类型的网络管理系统根据自身的性能管理需求而定制性能告警的灵活性需要,通过设置关键性能指标和选择告警生成规则的搭配,解决了扩展性能告警类型的需要。通过设置和选择告警后处理规则,可以达到根据需要对满足告警生成规则的告警进行进一步筛选和过滤的目的,从而使用户仅关注一些有重要作用的告警。因此,本发明技术方案将有效节约运营商建设网络管理系统的成本。
具体实施方式
本发明通过通用性能告警服务系统来实现提供性能告警服务的方法,提供性能管理日常运维报表以及能根据性能指标值的变化情况进行性能告警。
下面参考图1说明本发明提供通用性能告警服务方法的基本流程。
步骤S101:定义通用性能指标对象和通用告警规则对象的数据存储结构;
网络设备的基本性能指标一般由设备生产厂家提供,用于评价设备的性能状态,例如IP网络设备的CPU主频、内存容量、端口流量、传输质量、设备和板卡性能参数等;为了综合评价的需要,还可以定义较为复杂的复合性能指标,通过给出对基本性能指标进行组合运算的表达式得到。另外,为了更好地组织和使用性能指标,还可以将性能指标按类型分组,定义为各个性能指标组。告警规则用于确定随性能指标值变化而发生告警事件的规则。预先定义用于存储通用性能指标对象和通用告警规则对象的数据结构是必要的,可以是面向对象的类结构或数据库表结构等形式。
步骤S102:接收对网元的关键性能指标和告警规则的增、删、改配置信息,保存为通用性能指标对象和通用告警规则对象。
该步骤将通过与设置配置信息程序的接口交互,获得配置信息,并将这些配置信息保存为通用性能指标对象和通用告警规则对象。通用性能告警服务系统的使用者,可以是话务网管系统、传输网管系统等各种网管系统的应用层,他们可以根据应用的需求预先定制所关注网元的关键性能指标,和基于这些指标的告警规则。定制的方式可以通过网管应用层程序直接预置为固定的定义;也通过网管应用界面根据需求随时进行灵活的设置等方式,在应用界面上设置对关注网元的关键性能指标进行增、删、改配置,并基于这些已经配置的指标进行告警规则的增、删、改配置。所述配置的告警规则至少包括告警生成规则。
本步骤接收网管应用层对其所关注网元的关键性能指标(KPI)的配置和告警生成规则的增加、修改和删除配置,并将配置结果保存为通用性能指标对象和通用告警规则对象。
步骤S103:与数据服务提供方建立通讯连接,收集所述性能数据。
为了获取到性能数据,需要与外部数据服务提供方建立通讯连接,数据服务提供方可以包括厂家的OMC、设备网元或处理后的性能数据等,厂家的OMC可能通过数据库、文件等接口向外吐数据。建立通讯连接之后收集数据的机制可以是通过数据库、文件或消息方式。一般通过建立南向接口的机制用于统一接口,通过该接口可以采集到厂家网管或设备的性能数据。因此在本步骤,一种收集性能数据的方式是,与数据服务提供方建立通讯连接,或者向其发出订阅与网元关键性能指标有关的性能数据的请求,数据服务提供方收到订阅请求后,响应并回发有关性能数据,之后收集所述性能数据;或者第二种方式是,通过SQL语句从数据服务提供方的数据库获取所述性能数据;或者第二种方式是,通过读取文件从文件获取所述性能数据。
步骤S104:对所收集性能数据做数据归一化处理。
从南向接口所收集来的性能数据的数据格式可能是多种多样的,为便于统一处理,需要进行归一化处理,转为统一的数据类型和格式。
步骤S105:根据归一化的性能数据,计算所配置网元关键性能指标的值。
根据所配置网元关键性能指标的计算表达式,以及经过归一化处理的性能数据,计算所配置网元关键性能指标的值。
步骤S106:判断计算出的网元关键性能指标值是否符合配置的告警规则,如果符合则生成性能告警,并保存到历史性能数据库中。
用计算出的网元关键性能指标值与所配置的告警规则进行匹配,如果性能指标值符合配置的告警规则,则生成满足关键性能指标的性能告警,并保存到历史性能数据库中,否则结束。
为解决了各种类型的网络管理系统根据自身的性能管理需求而灵活定制性能告警的配置性需要,基于以上的技术方案,可以通过定义配置文件,或者从网管应用层设置用户交互界面的方式配置关键性能指标和告警规则,根据应用需求随时可对网元的关键性能指标和告警规则的增、删、改进行配置。对于定义配置文件的方式,需要预先定义配置文件的语法格式,例如XML文件,要求配置人员会写配置文件,对于设置用户交互界面的方式,则对配置人员要求较低,可以直接根据界面形式和帮助信息进行配置,这样,关键性能指标就可以根据用户需要生成的告警信息来进行自定义,从而达到灵活定制性能告警的目的。
为详细说明本发明方法的实现过程,请参见图2如下实施例一。
步骤S201:定义通用性能指标对象类和通用告警规则对象类。
例如定义面向对象的类结构形式,通用性能指标对象类和通用告警规则对象类如下:
CLASS CommKPI{
KPI_Name VARCHAR;//KPI名称;
KPI_ID NUMBER;//KPI标识
KPI_Exp VARCHAR;//KPI计算表达式;
KPISQL VARCHAR;//KPI的SQL;
};
CLASS CommAlarmRule{
Rule_Name VARCHAR;//告警规则名称
KPI_Name VARCHAR;//KPI名称
NE_Type VARCHAR;//网元类型
NE_ID NUMBER;//网元ID
AlarmLeve l VARCHAR;//告警级别,可分为重大告警、严重
告警、一般告警等级别
TermofVal idi ty VARCHAR;//告警规则的有效期,包括开始
日期,结束日期,起始时间,结束时间
AlarmTopic VARCHAR;//告警标题
AlarmTXT VARCHAR;//告警正文
AlarmRule VARCHAR;//告警规则条件
};
所述通用性能指标对象类应至少包括性能指标名称、网元类型或标识、性能指标计算表达式;所述通用告警规则对象类应至少包括规则名称、相关性能指标名称或标识、所作用的网元类型、网元ID、告警规则的有效期、告警标题。以上所述类定义中的各项是对象类至少包括的基本要素,还可以根据应用需要添加更多的项。
所述定义的性能指标是用户根据应用需求定义的,这些KPI可以直接对应于基本KPI指标,也可以是根据多个基本KPI指标的计算表达式而得到的组合KPI指标。所述的基本KPI来源于设备厂家提供的不可再细分的基本性能指标数据,组合KPI指标中的计算表达式是基本KPI指标基于合法的加、减、乘、除等运算符运算而表示的,是无二义性的表达式。
一般情况下,性能指标的数量非常多,包括网元指标、业务指标等,因此对性能指标进行分类定义和操作管理是更好的技术方案。因此,所述通用性能指标对象类可以包括通用性能指标类和通用性能指标组类,例如:
CLASS CommKPIgroup{
KPIgroup_Name VARCHAR;//性能指标组名称;
KPIgroup_ID NUMBER;//性能指标组标识;
KPIgroup_Type VARCHAR;//性能指标组所属的类型(如按
照设备网元、业务等类型划分)
CollectPeriod VARCHAR;//性能数据采集周期;
KPIgroupSQL VARCHAR;//性能指标组通用SQL;
};
所述的性能数据采集周期用于指定获取数据的时间间隔;进一步增加了获取数据时间间隔的可配置性。所述的性能指标组通用SQL用于为数据库接口指定获取数据的条件等。
步骤S202:网管系统用户在网管应用层设置配置文件或者提供用户交互界面,对网元的关键性能指标和告警规则进行增、删、改配置。
如下是一个XML配置文件的实例。
<schema_kpi>
<schema>
<schema_ns>TPM-HOST-UNIX-CPU</schema_ns> //性能指标组标识
<schema_zhname>UNIX 主机CPU性能指标</schema_zhname> //性能
指标组名称
<schema_desc />
<ne_type>1001,1002,1004</ne_type> //指标组类型1001(路由器)
1002(交换机)1004(主机)
<subne_type>1</subne_type>//是否是子类型1 unix 3 Windows
<sql>select org_time,node_name as neName,:sql_exp as kpiValue
from iptpa_host_cpu where org_time>=:s canStartTime and a.org_time
<:scanStopTime</sql>//SQL通用表达式,用于获取指标数据信息
<interval>300</interval>//采集周期
</schema>
<kpis>
<kpi>
<kpi_enname>HSTHA100</kpi_enname> //KPI标识
<kp i_zhname>CPU利用率</kp i_zhname> //KPI名称
<kpi_exp>100-HSTHA03</kpi_exp> //KPI计算表达式
<sql_exp>100-cpuidletime</sql_exp> //SQL表达式
<sql_proc/> //指标调用存储过程
<kpi_format/> //指标格式
<notes/>
</kpi>
</kpis>
</schema_kpi>
网管系统用户还可以通过一个配置关键性能指标的界面,根据应用需求给指定网元配置关键性能指标KPI,通过添加、修改和删除的方式。可以增加一至多个性能指标,性能指标可以包括KPI名称和KPI标识、KPI计算表达式、sql表达式等。然后根据所配置的性能指标,配置相应的告警规则。
如图3所示是一个设置性能指标的用户界面的例子,通过该界面可以将性能指标的标识等参数输入系统。例如,添加一个主机CPU利用率的指标。用户在配置关键性能指标的界面选择添加,然后输入KPI名称:CPU利用率,性能指标标识:HSTHA100;然后输入性能指标表达式:100-HSTHA03;接着输入性能指标SQL:100-cpuidletime。
网管系统用户还通过一个配置告警规则的界面,给指定网元和KPI指标配置告警规则,一般包括规则名称、相关KPI指标、网元标识、所属的指标组类型、告警级别和规则条件。可以配置固定阈值告警规则、趋势告警规则、梯度告警规则等。所述固定阈值告警规则需要设置关键性能指标实际值在当前告警级别的阈值,设置当实际值达到当前告警级别的阈值时生成当前告警级别的阈值告警;所述趋势告警规则需要根据实际值对标准基线值的偏移设置阀值,设置关键性能指标在当前告警级别的趋势标记、基线、趋势次数,设置当实际性能指标达到当前告警级别的基线、并呈现所设置的趋势、且超过所设置的趋势次数时生成当前告警级别的趋势告警。所述梯度告警规则需要根据指标值的增长速率(梯度)设置多级告警标准阀值,当实际值的增长速率(梯度)超过标准值时,生成当前告警级别的趋势告警。
如图4所示是一个针对上述主机CPU利用率配置告警规则的用户界面的例子。
步骤S203:接收对网元的关键性能指标和告警规则的配置信息,并保存为通用性能指标对象和通用告警规则对象。
由于已经在步骤S201预先创建通用性能指标对象类,接收到关键性能指标和告警规则的增加配置数据后,首先做合法性检查,KPI名称是否合法,KPI计算表达式是否合法,检查合法后则生成一个新的通用性能指标对象,将所接收到的配置数据参数保存到通用性能指标对象的数据库表记录中。如果检查不合法则继续等待新的配置数据输入。如下表1是关于主机CPU占用率指标的一个KPI记录:
表1
字段名 |
字段类型 |
字段值 |
KPI_Name |
VARchar |
主机CPU占用率 |
KPI_ID |
NUMBER |
HSTHA100 |
KPI_Exp |
VARchar |
100-HSTHA103 |
KPISQL |
VARchar |
select org_time,node_name as neName,:sql_exp askpiValue from iptpa_host_cpu where org_time>=:scanStartTime and a.org_time<:scanStopTime |
如果用户在关键性能指标的界面选择修改并指定所修改KPI名称或KPIID,则性能告警服务系统将呈现该KPI名称或KPI ID的KPI数据记录,用户修改了一些参数之后保存。
如果用户在关键性能指标的界面选择删除某指定的KPI名称或KPI ID所在的记录,则性能告警服务系统将检查是否还有与指定的KPI名称相关的告警规则,如果没有,则删除这个KPI名称或清空KPI ID的KPI数据记录。如果还有与指定的KPI名称相关的告警规则存在,则不作删除处理。
配置告警规则可以与一个或多个关键性能指标相关,例如,配置主机A的阈值告警,用户在配置告警规则的界面选择添加,然后选择KPI名称:主机CPU占用率,选择网元类型:主机A,告警级别:严重告警,输入规则条件:主机CPU占用率>=60%则产生严重告警。又例如,配置主机B的组合阈值告警,用户在配置告警规则的界面选择添加,然后选择一个KPI名称:主机CPU占用率,再选择一个KPI名称:主机硬盘占用率,网元类型:主机B,告警级别:严重告警,输入规则条件:$KPI_Name>=60%且$主机硬盘占用率>=70%则产生严重告警。本步骤接收用户输入的信息,将所添加有关主机CPU占用率的告警规则保存到以下表2的阈值告警规则数据库表2中:
表2
字段名 |
字段类型 |
一个记录的字段值 |
另一个记录的字段值 |
RuleName |
VARchar |
主机CPU占用率阈值告警 |
组合阈值告警X |
KPI_Name |
VARchar |
主机CPU占用率 |
主机CPU占用率,主机硬盘占用率 |
NE_ID |
NUMBER |
0088 |
0088 |
NE_Type |
VARchar |
主机A |
主机A |
AlarmLevel |
VARchar |
严重告警 |
严重告警 |
TermofValidity |
VARchar |
20080101至20091231 |
20080101至20091231 |
AlarmTopic |
VARchar |
主机CPU占用率阈值告警 |
主机CPU占用率和硬盘的阈值告警 |
AlarmTXT |
VARchar |
当前@KPI_Name为@KPI_Value,网元类型为@NE_Type的@AlarmLevel级告警。 |
当前@KPI_Name为@kPI_Value,网元类型为@NE_Type的@AlarmLevel级告警。 |
AlarmRule |
VARchar |
$主机CPU占用率>=60% |
$主机CPU占用率>=60%且$主机硬盘占用率>=70% |
其中告警规则AlarmRule用逻辑表达式表示,表示当前设置的KPI值的匹配条件,其中$符号后为KPI名称;AlarmTopic和AlarmTXT为设置的告警标题和告警正文的格式模板,其中@KPI_NAME和@KPI_Value为通配符,在生成告警时可自动替换为对应的KPI名称和KPI值。
告警规则设置之后,性能服务系统就从数据库中读取用户设置的规则信息,根据这些信息按网元类型或网元ID分类,封装成规则集,形如<Key,RuleSet>;规则集由规则组成,规则包含用户设置的条件和满足条件对应的结果两部分,如:
When$HSTHA100>60%&&$HSTHA100<70%
Then AlarmLevel=‘严重告警’,AlarmTXT=‘当前@KPI_Name为@kPI_Value,网元类型为@NE_Type的@AlarmLevel级告警’。
之后如果告警规则进行了修改或删除,则规则也会相应立即更新。
然后,将生成的规则集加载到系统中。后续将根据这些规则对收集过来的性能数据进行处理。
又例如:接收到一个主机CPU占用率的趋势告警规则配置,保存到趋势告警规则对象类的数据记录表中,如表3:
表3
字段名 |
字段类型 |
字段值 |
RuleName |
VARchar |
主机CPU占用率阈值告警 |
KPI_Name |
VARchar |
Unix主机CPU利用率 |
NE_ID |
NUMBER |
0088 |
NE_Type |
VARchar |
主机A |
AlarmLevel |
VARchar |
严重告警 |
TrendFlag |
BOOL |
0:下降;1:上升 |
BaseLine |
DOUBLE |
60% |
TrendTimes |
int |
5 |
TermofValidity |
VARchar |
20080101至20091231 |
AlarmTopic |
VARchar |
主机CPU占用率阈值告警 |
AlarmTXT |
VARchar |
当前@KPI_Name为@Kpi_Value,网元类型为@NE_Type的@Alarm_Level级告警。 |
AlarmRule |
VARchar |
$主机CPU占用率>60% |
表3中与阈值告警规则不同的是,多了一个趋势标记TrendTag、基线BaseLine和趋势次数TrendTimes。TrendTag用于设置发出告警的条件满足上升还是下降趋势。趋势告警用于判断所述KPI_Name的性能数据如果大于基线BaseLine达到TrendTimes次以上且呈TrendFlag设置的趋势,就会发出趋势告警。
步骤S204:与数据服务提供方的北向接口建立通讯连接,收集与网元关键性能指标有关的性能数据。
从外部数据服务提供方的北向接口可以获取被管网络设备的配置数据、性能数据或告警数据等,本步骤通过消息订阅方式实现性能告警服务系统获得当前性能数据。首先要与外部数据服务提供方的北向接口建立连接,并向其发出订阅与网元关键性能指标有关的性能数据的消息请求,数据服务提供方收到请求后,将所述与网元关键性能指标有关的性能数据收集起来,返馈给性能告警服务系统。性能告警服务系统可以通过多种方式获得性能数据,例如消息队列缓存机制、定时轮询方式等。数据服务提供方收到订阅请求后,可回应或者定期回发有关性能数据。
步骤S205:对所收集数据做数据归一化处理。
由于收集来的性能数据来自不同的设备或不同的网元系统,数据格式可能是多种形式的,因此需要将收集来的数据封装为统一格式的数据存储结构,例如下面的PMSDATA数据类对象,
CLASS PMSDATA{
NE_ID NUMBER;//网元ID
NE_Type VARCHAR;//网元类型
CollBeginTime VARCHAR;//采集开始时间
CollEndTime VARCHAR;//采集结束时间
CollPeriod VARCHAR;//采集周期
KPI_List(KPI_Name VARCHAR,KPI_Value NUMBER);//KPI列表
};
这里的KPI_List中包含的是基本KPI_Name和基本KPI_Value。
又例如:系统经过处理转换成PMSDATA对象,如表4:
步骤S206:针对归一化后的性能数据,按照所配置的关键性能指标KPI表达式公式,计算关键性能指标值KPI。
将数据服务提供方发送过来的性能数据进行归一化后的实时处理,从步骤S203保存在通用性能指标对象的纪录中取出各KPI_Name的KPI计算表达式,计算KPI的值。如KPI计算表达式项为NULL,则该KPI_Name对应的值就是发送过来的性能数据值,即上述步骤S205中从KPI_List中获得的KPI_Name对应的KPI_Value,如主机A的CPU占用率为70%,主机A的硬盘占用率为75%。如KPI计算表达式项不为NULL,由各项基本KPI按照计算公式组合,则从KPI_List中获得基本KPI_Name对应的基本KPI_Value,按照表达式的定义计算出表达式的值。
步骤S207:判断所计算出的网元关键性能指标值是否符合配置的告警生成规则,如果符合则生成性能告警,否则结束。
由于一个KPI可能对应于多个和多种告警生成规则,阈值告警、组合阈值告警、趋势告警等,要按照所配置的多个告警生成规则逐一匹配。例如,可以先进行阈值告警规则的匹配,如果性能指标值符合阈值告警规则,生成告警,否则再进行趋势告警规则的匹配,如果性能指标值符合趋势告警规则,生成告警,将生成的告警保存到历史性能数据库中,否则结束。
如果一个组合阈值告警规则是,主机CPU占用率>=60%且主机硬盘占用率>=70%则产生严重告警,根据步骤S206得到的主机A的CPU占用率为70%,主机A的硬盘占用率为75%,就将生成严重告警。从有关的告警规则数据记录中读取生成告警的标题和告警正文,将生成的告警信息封装为如下对象类,保存到历史数据库。
CLASS AlarmInfo{
NE_ID;//网元ID
NE_Type;//网元类型
AlarmLevel;//告警级别
AlarmTopic;//告警标题
AlarmTXT;//告警正文
};
对于归一化后的性能数据对象PMSDATA,首先使用网元ID或网元类型获得对应的规则集,然后从该规则集中按告警级别逐条读取规则,并将PMSDATA中的性能指标数据与规则条件When进行对比,如果条件满足则将规则的结果装载进告警对象中,如果不满足,则继续读取下一条规则,直至最后,如果仍没有相匹配的规则,则不装载。装载的告警对象如表5所示:
表5
产生的告警对象的告警标题和告警正文中使用的变量,如@KPI_Name、@KPI_Value等,根据PMSDATA性能指标数据和用户配置的指标信息进行替换,如使用指标名$HSTHA100替换变量@KPI_Name,使用PMSDATA中指标列表KPI_List对应的Value替换@kpi_Value。最终产生具体的告警对象。如最终AlarmInfo对象为表6所示:
表6
以上流程是完成本发明的主要步骤。
为使告警处理得到进一步的优化处理,还提出更加优选的技术方案为:
在步骤S202和203中还可以配置和接收告警后处理规则,例如包括告警级别筛选规则、告警抑制规则、风暴抑制规则和/或告警清除规则等。可以在通用告警规则基础上做进一步规定,例如表7-告警抑制规则表中,增加抑制开始时间、抑制结束时间、有效开关,表8-告警风暴抑制规则表中,增加风暴抑制开始时间、风暴抑制结束时间、有效开关。
表7
字段名 |
字段类型 |
字段值 |
规则名称 |
VARchar |
丢包率抑制告警 |
KPI名称 |
VARchar |
Unix主机cpu利用率 |
网元ID |
VARchar |
0088 |
告警级别 |
VARchar |
严重告警 |
抑制开始日期 |
DATE |
2009-11-03 23:10:00 |
抑制结束日期 |
DATE |
2009-12-03 08:30:00 |
有效开关 |
BOOL |
是 |
风暴抑制周期 |
INTERGER |
10(秒) |
表8
字段名 |
字段类型 |
字段值 |
规则名称 |
VARchar |
Unix主机cpu利用率风暴抑制规则 |
KPI名称 |
VARchar |
Unix主机cpu利用率 |
网元ID |
VARchar |
0088 |
告警级别 |
VARchar |
严重告警 |
风暴抑制开始日期 |
DATE |
2009-11-03 23:10:00 |
风暴抑制结束日期 |
DATE |
2009-12-03 08:30:00 |
有效开关 |
BOOL |
是 |
风暴抑制周期 |
INTERGER |
20秒 |
步骤S208:根据步骤S207所生成的告警,进一步判断所生成性能告警是否符合配置的告警后处理规则,如果符合则生成符合告警后处理规则的告警并将其保存到历史性能告警数据库中,转步骤S209,否则结束。
根据配置的告警抑制规则来判断生成告警的KPI名称、网元Id、告警级别在当前时间段内是否被抑制。
根据配置的风暴抑制规则来判断生成告警的KPI名称、网元Id、告警级别在风暴抑制时间内重复发出的告警将被抑制。
步骤S209:将所产生的性能告警信息上报给网管应用层,便于呈现、通知或处理所述性能告警。
需要补充说明的是,基于以上技术方案进行扩充,还可进一步查询告警,当接收查询告警配置的请求或者查询性能告警的请求后,从历史性能告警数据库中取出所配置的关键性能指标、告警规则或性能数据,返回给网管应用层。
请参考图5,是本发明实施例二,用另一种形式的流程图来说明网管应用层、性能告警服务器和数据服务提供方三者之间的通讯联系,以及各部分的实现功能,过程S301、S303、S304、S305、S306、S307都在性能告警服务器上实现,过程S302和S308在网管应用层实现,过程S305在数据提供服务方实现。
S301:定义通用性能指标对象类和通用告警规则对象类。
S302:在网管应用层上设置对网元的关键性能指标和告警规则的增、删、改配置。
S303:接收对网元的关键性能指标和告警规则的增、删、改配置信息。
S304:与外部数据服务提供方建立通讯连接,发出订阅与网元关键性能指标有关的性能数据的消息请求,并收集所述性能数据。
S305:在数据服务提供方上响应连接,采集并回发与网元关键性能指标有关的性能数据。
S306:对所收集性能数据做数据归一化处理。
S307:判断计算出的性能指标值是否符合配置的告警规则,如果符合则产生性能告警,上报给网管应用层,并保存为历史性能数据。
S308:在网管应用层上呈现/通知/处理告警。
本发明还提出一种提供性能告警服务的装置,其基本组成结构实现原理图参见图6,包括:
通用性能数据定义单元101,用于定义通用性能指标对象和通用告警规则对象的数据存储结构,即预先定义用于存储通用性能指标对象和通用告警规则对象的数据结构。可以是面向对象的类结构或数据库表结构等形式。
性能指标与告警规则配置接收单元102,用于接收网管应用层配置的关键性能指标和告警规则,按通用性能数据定义单元101所定义的通用性能指标对象类和通用告警规则对象类保存为通用性能指标对象和通用告警规则对象。通过与设置配置信息程序的接口交互,获得配置信息,并将这些配置信息保存为通用性能指标对象和通用告警规则对象。
性能数据收集单元103,与数据服务提供方的北向接口建立通讯连接,根据性能指标与告警规则配置接收单元102得到的关键性能指标配置,收集与网元关键性能指标有关的性能数据;
归一化处理单元104,将性能数据收集单元103收集来的性能数据的数据格式进行归一化处理,转为统一的数据类型和格式。
性能指标计算处理单元105,根据性能指标与告警规则配置接收单元102所接收的配置网元关键性能指标的计算表达式,并根据归一化处理单元104归一化处理的性能数据,计算关键性能指标的值;
告警判断与告警生成单元106,根据性能指标与告警规则配置接收单元102所配置的告警规则,以及由性能指标计算单元105所计算出的关键性能指标值,判断关键性能指标值是否符合配置的告警规则,如果性能指标值符合告警规则,生成性能告警,并保存到历史性能数据库中。
为了解决各种类型的网络管理系统根据自身的性能管理需求而灵活定制性能告警的配置性需要,基于以上的技术方案,更好的技术实现方案是,从网管应用层设置配置文件或者设置用户交互界面的方式配置关键性能指标和告警规则,参见本发明实施例三所示的图7技术方案,增加一个性能指标与告警规则配置设置单元107,用于根据应用需求随时可对网元的关键性能指标和告警规则的增、删、改进行配置。这样关键性能指标就可以根据用户需要生成的告警信息来进行自定义,从而达到灵活定制性能告警的目的。以上各单元的实现实施例参见上述实施例一所述的过程,这里不再赘述。
通用性能指标对象和通用告警规则对象的定义可以通过前述步骤S201所述的面向对象的类结构形式。所述通用性能指标对象类应至少包括性能指标名称、网元类型或标识、性能指标计算表达式;所述通用告警规则对象类应至少包括规则名称、相关性能指标名称或标识、所作用的网元类型、网元ID、告警规则的有效期、告警标题。以上所述类定义中的各项是对象类至少包括的基本要素,还可以根据应用需要添加更多的项。
所述定义的性能指标是用户根据应用需求定义的,这些KPI可以直接对应于基本KPI指标,也可以是根据多个基本KPI指标的计算表达式而得到的组合KPI指标。所述的基本KPI即由设备厂家提供的不可再细分的基本性能指标数据,组合KPI指标中的计算表达式是基本KPI指标基于合法的加、减、乘、除等运算符运算而表示的,是无二义性的表达式。
一般情况下,性能指标的数量非常多,包括网元指标、业务指标等,因此对性能指标进行分类定义和操作管理是更好的技术方案。因此,所述通用性能指标对象类可以包括通用性能指标类和通用性能指标组类。
网管系统用户可以通过性能指标与告警规则配置设置单元107配置关键性能指标和告警规则,根据应用需求给指定网元配置关键性能指标KPI,通过在网管应用层设置配置文件或者提供用户交互界面,对网元的关键性能指标和告警规则进行增、删、改配置。实施例参见前述步骤S202所述的过程。可以增加一至多个关键性能指标。然后根据所配置的关键性能指标,配置相应的告警规则,一般包括规则名称、相关KPI指标、网元类型、告警级别和规则条件。配置的通用告警规则可以包括门限阈值规则、趋势告警规则等。所述阈值告警规则还需要设置关键性能指标在当前告警级别的阈值,设置当关键性能指标达到当前告警级别的阈值时生成当前告警级别的阈值告警;所述趋势告警规则还需要设置关键性能指标在当前告警级别的趋势标记、基线、趋势次数,设置当关键性能指标达到当前告警级别的基线、并呈现所设置的趋势、且超过所设置的趋势次数时生成当前告警级别的趋势告警。
性能数据收集单元103还可以包括:
通讯连接模块,用于与数据服务提供方建立通讯连接;
访问数据库模块,通过SQL语句从数据服务提供方的数据库获取所述性能数据;
读取文件模块,通过从数据服务提供方写的文件获取所述性能数据;
消息队列缓冲模块,通过收发消息和消息队列缓冲机制,向外部数据服务提供方发出订阅请求与收集性能数据。
归一化处理单元104,将来自不同的设备、不同的网元系统的性能数据通过性能数据订阅与收集单元103收集过来后封装为统一格式的数据存储结构,参见前述的PMSDATA数据类对象。
性能指标计算处理单元105,按照所配置的关键性能指标KPI表达式公式,用归一化处理单元104归一化后的性能数据,计算关键性能指标值KPI。
当性能告警生成之后,为便于将其进行呈现、通知或进一步处理,基于上述的技术方案,参见本发明实施例五所示的图8所示的技术方案,增加告警上报单元108,将所产生的性能告警信息上报给网管应用层,便于呈现、通知或处理所述性能告警。
参见本发明实施例五所示的图9,基于以上的技术方案,还可以将性能指标与告警规则配置接收单元102接收并保存的关键性能指标对象和告警规则对象进一步保存到数据库109中,那么性能指标计算处理单元105和告警判断与告警生成单元106则直接从数据库109取出配置数据即可,当然还可以将告警判断与告警生成单元106生成的性能告警也保存到数据库109中。
基于以上技术方案还可以进一步扩充实现查询告警的功能,参见图9中还增加了告警查询单元110,用于从网管应用层接收到查询告警配置的请求或者查询性能告警的请求后,从数据库109中取出所配置的关键性能指标、告警规则,以及保存的历史性能数据,返回给网管应用层。
以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。