CN102664759A - 非稳态告警消息的过滤方法和设备 - Google Patents
非稳态告警消息的过滤方法和设备 Download PDFInfo
- Publication number
- CN102664759A CN102664759A CN2012101317490A CN201210131749A CN102664759A CN 102664759 A CN102664759 A CN 102664759A CN 2012101317490 A CN2012101317490 A CN 2012101317490A CN 201210131749 A CN201210131749 A CN 201210131749A CN 102664759 A CN102664759 A CN 102664759A
- Authority
- CN
- China
- Prior art keywords
- alarm
- network element
- element device
- alarm information
- unstable state
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
本发明实施例公开了一种非稳态告警消息的过滤方法和设备,通过应用本发明实施例的技术方案,可以在网元设备启动后,对于网元设备在非稳态告警过滤时间区间内所接收到的所有告警消息(非稳态告警消息)进行过滤处理,从而,可以将网元设备启动初期由非稳态向稳态进行转换的过程中所形成的大量告警消息进行过滤,避免告警风暴等情况对系统所造成的巨大负担,降低网元设备与网管系统之间的通信流量,提高网元设备处理和告警上报过程的效率和准确性,避免大量非必要告警消息的处理所耗费的人工和系统成本。
Description
技术领域
本发明涉及通信技术领域,特别涉及一种非稳态告警消息的过滤方法和设备。
背景技术
网元设备在启动完成的一段时间T内,设备处于非稳态,通常会上报大量由管理对象状态不稳定导致的告警消息,在该时间段结束后,设备状态由非稳态转为稳态,由于被告警对象的故障恢复,一部分这样的告警消息又会被清除。
由于网元系统内的告警源必须及时上报当前设备内的告警,这样就会导致在网元设备启动初期告警风暴的产生。
网元设备系统在非稳态期间将会处理大量的告警产生、告警清除消息,直接影响到网元设备内OAMS(Operation and Management Subsystem,操作维护子系统)告警处理模块的处理负担和处理效率,也增加了网元与OMC(Operations & Maintenance Center,操作维护中心)网管系统之间的通信压力。如果OAMS告警处理模块在短时间内频繁上报告警消息给OMC网管系统,OMC网管系统呈现给用户的告警界面就会频繁出现告警抖动的情况,这对用户通过OMC网管系统告警界面监控设备状态带来了不便。
在现有的技术方案中,无过滤的直接上报方案是一种最简单的非稳态期间告警上报方法,在网元设备非稳态期间,当告警源检测到所监测的对象状态变为故障或出现异常时,直接上报告警消息至网元内OAMS告警处理模块,告警处理模块进行简单的预处理后,再将告警上报至OMC网管系统。对这种情况下的告警处理过程,OAMS告警处理模块未做过滤处理,只要收到告警源上报的告警消息,OAMS告警处理模块就及时上报至OMC网管系统。如图1所示,为现有技术中的无过滤的直接上报方案的流程示意图。
在实现本发明的过程中,发明人发现现有技术中至少存在以下问题:
现有技术中的无过滤的直接上报方案最大的缺陷就是没有提供特定的告警过滤处理,使得一些在设备处于非稳态期间频繁上报的告警产生和告警清除消息没有被合理有效的处理,就直接上报给OMC网管系统,呈现给运维人员,这对网管系统对告警的处理和呈现带来了很大的性能负担,若同一时间网元设备内对象频繁故障又恢复,这使得OMC网管系统告警监控界面不断出现告警抖动,一些原本无需运维人员关注的告警消息被呈现在OMC网管系统的告警界面上,给运维人员对告警的监控和设备的快速维护带来了不便。
发明内容
本发明实施例提供一种非稳态告警消息的过滤方法和设备,解决现有的技术方案中不能对非稳态期间所频繁上报的告警消息进行合理有效的过滤处理,从而对正常的告警处理和性能实现造成巨大负担的问题。
为达到上述目的,本发明实施例一方面提供了一种非稳态告警消息的过滤方法,至少包括以下步骤:
网元设备启动后,所述网元设备将自身在非稳态告警过滤时间区间内接收到的所有告警消息进行缓存,并进行识别;
所述网元设备根据所述识别的结果,分别判断各告警消息是否属于待过滤告警消息;
如果判断结果为是,所述网元设备对所述告警消息进行过滤;
如果判断结果为否,所述网元设备在所述非稳态告警过滤时间区间结束后,将所述告警消息发送给网管系统。
另一方面,本发明实施例还提供了一种网元设备,包括:
计时模块,用于在所述网元设备启动后,对非稳态告警过滤时间区间进行计时;
识别模块,用于将所述网元设备在所述非稳态告警过滤时间区间内接收到的所有告警消息进行缓存,并进行识别;
判断模块,用于根据所述识别模块所进行识别的结果,分别判断各告警消息是否属于待过滤告警消息;
过滤模块,用于对所述判断模块的判断结果为是的告警消息进行过滤;
发送模块,用于在所述非稳态告警过滤时间区间结束后,将所述判断模块的判断结果为否的告警消息发送给网管系统。
与现有技术相比,本发明实施例所提出的技术方案具有以下优点:
通过应用本发明实施例的技术方案,可以在网元设备启动后,对于网元设备在非稳态告警过滤时间区间内所接收到的所有告警消息(非稳态告警消息)进行过滤处理,从而,可以将网元设备启动初期由非稳态向稳态进行转换的过程中所形成的大量告警消息进行过滤,避免告警风暴等情况对系统所造成的巨大负担,降低网元设备与网管系统之间的通信流量,提高网元设备处理和告警上报过程的效率和准确性,避免大量非必要告警消息的处理所耗费的人工和系统成本。
附图说明
图1为现有技术中的无过滤的直接上报方案的流程示意图;
图2为本发明实施例所提出的一种非稳态告警消息的过滤方法的流程示意图;
图3为本发明实施例所提出的一种具体场景中的非稳态告警消息的过滤方法的原理示意图;
图4为本发明实施例所提出的一种具体应用场景下的非稳态告警消息的过滤方法的流程示意图;
图5为本发明实施例所提出的一种网元设备的结构示意图。
具体实施方式
如背景技术所述,网元设备处于非稳态期间,告警源在短时间内会检测并上报大量的告警产生消息,并且有可能在非稳态期间,以及网元设备转为稳态之后,检测到大量的告警清除消息,这就会导致网元设备在瞬间频繁上报告警消息。
如果网元设备内对这些告警消息不做相应的处理就直接上报给OMC网管系统,便会导致OMC网管系统的告警监控界面在瞬间呈现过多的告警信息给用户,也可能会出现某些告警刚刚上报了产生消息又很快被清除的情况,这给OMC网管系统告警的处理、监控、呈现带来很大的性能压力和考验。
同时,告警界面出现告警的频繁抖动(在指定的时间范围内,频繁产生、清除达到指定的次数的告警消息,即在限定时间内,抖动次数达到一定值,即认为是告警抖动),会使设备运维人员无法准确的获知网元设备当前状态。
为了克服这样的缺陷,本发明实施例提出了一种非稳态告警消息的过滤方法,对网元设备在非稳态期间上报的大量告警消息进行过滤处理后,只将用户真正关心的告警消息上报至OMC网管系统,从而,可以将网元设备启动初期由非稳态向稳态进行转换的过程中所形成的大量告警消息进行过滤,避免告警风暴等情况对系统所造成的巨大负担,降低网元设备与网管系统之间的通信流量,提高网元设备处理和告警上报过程的效率和准确性,避免大量非必要告警消息的处理所耗费的人工和系统成本。
如图2所示,为本发明实施例所提出的一种非稳态告警消息的过滤方法的流程示意图,该方法具体包括以下步骤:
步骤S201、网元设备启动后,所述网元设备将自身在非稳态告警过滤时间区间内接收到的所有告警消息进行缓存,并进行识别。
在具体的处理场景中,本步骤的处理具体包括以下步骤:
(1)所述网元设备初始化完成后,对非稳态告警过滤时间区间进行计时。
需要进行说明的是,此处所提及的非稳态告警过滤时间区间的长度可以根据实际的需要进行设置,其作用在于确定进行过滤的告警消息的接收时间范围。
考虑到需要过滤的告警消息主要是因为网元设备从非稳态向稳态转换过程中所产生的,可以对非稳态告警过滤时间区间的长度按照以下两种方式进行设置:
方式一、直接将网元设备启动后达到稳态所需要的时间的长度设置为非稳态告警过滤时间区间的长度。
通过这样的方式,可以将网元设备在非稳态所接收到的所有告警消息均划分为待识别的对象,而且,网元设备由非稳态向稳态切换的时间可以通过具体实现过程的时间统计来获取,这样的设置方案实现简便,便于操作。
方式二,分别确定网元设备启动后达到稳态所需要的时间的长度,以及网元设备在达到稳定时间后可能接收到待过滤告警消息的保护时间的长度,以两者时间的长度之和作为非稳态告警过滤时间区间的长度。
这样的方式主要是考虑到在非稳态期间所检测到的故障,有可能随着网元设备转换到稳态而得到恢复,因此,这样的故障所触发的告警消息(包括检测到该故障所触发的告警产生消息,以及该故障清除所触发的告警清除消息)显然是不需要进行处理的,因此,对于网元设备切换到稳态后的一段时间内所触发的告警清除消息来讲,一方面,其自身并不需要被上报给网管系统进行处理,另一方面,在网元设备非稳态期间其所对应的告警产生消息也不需要上报给网管系统进行处理。
基于上述考虑,按照方式二进行非稳态告警过滤时间区间的设定,不仅可以将网元设备在切换到稳态之后的一段时间内所接收到的告警消息纳入过滤范围,将一些不需要上报处理的告警消息过滤,而且,可以以这些告警消息为依据,对网元设备在非稳态时期所接收到的告警消息进行更加准确的过滤。
当然,上述的保护时间的长度可以是根据实际场景模拟得出的,或者根据常规状态下的统计数据进行归纳计算而得出的,也可以是一个按照一定规则所预设的数值,其具体长度变化,以及设置规则的调整并不会影响本发明的保护范围。
需要说明的是,非稳态告警过滤时间区间的设定是为了确定过滤告警消息的时间区间,在能够满足具体场景的需要的情况下,具体采用上述的那种方式进行非稳态告警过滤时间区间的设置,并不会影响本发明的保护范围。
(2)所述网元设备将自身在该计时超时前接收到的所有告警消息在非稳态告警的过滤缓存中进行缓存,并对所缓存的所有告警消息进行重复校验。
此处所提及的“非稳态告警的过滤缓存”具体可以是网元设备所预留的独立缓存空间,也可以是网元设备在物理存储空间或内存中动态调整后所出现的存储空间,其具体形式的变化并不会影响本发明的保护范围。
在实际的应用场景中,上述的重复校验的内容主要是告警消息的告警编号、告警对象,以及告警上报类型的识别和比较。
当然,其他的内容也可以作为相应的重复校验的内容,在能够达到相同的技术效果的前提下,这样的变化并不影响本发明的保护范围。
步骤S202、所述网元设备根据所述识别的结果,分别判断各告警消息是否属于待过滤告警消息。
如果判断结果为是,则执行步骤S203;
如果判断结果为否,则执行步骤S204。
考虑到网元设备在由非稳态向稳态切换的过程中的非稳态告警消息所可能出现的主要形式,本步骤的判断过程可以分为三个方面。
判断过程一、重复告警产生消息的判断过程。
网元设备在启动初期,处于不稳定状态,告警源可能会对同一故障对象重复上报告警产生消息,这些重复告警产生消息并不需要全部上报给OMC网管系统。因此,网元设备需要在接收到告警源上报的告警消息后,在非稳态告警的过滤缓存中对该告警消息进行重复校验和过滤处理。
当所述网元设备识别到自身在非稳态告警过滤时间区间所接收到的一个告警消息与一个或多个其他告警消息的告警编号相同,告警对象相同,且告警上报类型同为告警产生时,所述网元设备确定所述告警消息与所述一个或多个其他告警消息互为重复告警产生消息,属于待过滤告警消息。
判断过程二、成对告警消息的判断过程。
成对告警消息是指告警编号、告警故障对象相同、告警上报类型不同(分别为告警产生和告警清除)、并且依次(告警产生在前、告警清除在后)上报的两条告警消息。成对告警消息分别上报了同一个告警故障的产生和清除,表示该故障已经不再存在,因此不需要进行进一步的处理。
网元设备在启动时,某些管理对象(例如:小区)默认处于故障状态,此时告警源会检测并上报告警产生消息,网元设备启动成功后的一定时间内,这些对象被激活,此时告警源又会检测并上报告警清除消息,由于故障已经恢复,该告警消息是不需要呈现给运维人员的,需要将这样的成对告警消息进行过滤。
当所述网元设备识别到自身在非稳态告警过滤时间区间所接收到的两个告警消息的告警编号相同,告警对象相同,但告警上报类型分别为告警产生和告警清除,并且所述网元设备接收到告警产生的告警消息的时间早于接收到告警清除的告警消息的时间时,所述网元设备确定两个所述告警消息为成对告警消息,属于待过滤告警消息。
判断过程三、非法告警清除消息的判断过程。
在网元设备内,告警源未向网元设备上报告警产生消息,就上报了某对象的告警清除消息,则该告警清除消息为非法告警清除消息。
当所述网元设备识别自身在非稳态告警过滤时间区间接收到一个告警上报类型为告警清除的告警消息,但在接收到所述告警消息之前,没有接收到具有相同告警编号,相同告警对象,且告警上报类型为告警产生的告警消息时,所述网元设备确定所述告警消息为非法告警清除消息,属于待过滤告警消息。
通过上述的三个判断过程,分别确定了不同类型的非稳态告警消息,为后续的处理过程确定了相应的过滤对象。
需要说明的是,上述的三个判断处理过程,分别是针对不同类型的告警消息进行判断的过程,没有必然的先后顺序关系,其执行顺序的变化,以及是否同时执行,均不会对本发明的保护范围产生影响。
步骤S203、所述网元设备对所述告警消息进行过滤。
对应前述的不同类型的非稳态告警消息,本步骤所采用的过滤方式也存在相应的区别。
对于确定的一组重复告警产生消息(若干条告警产生消息),网元设备保留该组重复告警产生消息中最后一次上报的有效告警产生消息,并将其他重复告警产生消息进行丢弃,然后,网元设备在非稳态告警过滤时间区间结束后,将所保留的有效告警产生消息发送给网管系统。
对于确定的一对成对告警消息(一条告警产生消息和一条告警清除消息),网元设备则直接将这两条告警消息进行丢弃。
对于确定的非法告警清除消息(若干条告警产生消息),网元设备则直接将所确定的全部的非法告警清楚消息进行丢弃。
步骤S204、所述网元设备在所述非稳态告警过滤时间区间结束后,将所述告警消息发送给网管系统。
对于正常的告警消息,则需要上报给网管系统进行正常的处理。
与现有技术相比,本发明实施例所提出的技术方案具有以下优点:
通过应用本发明实施例的技术方案,可以在网元设备启动后,对于网元设备在非稳态告警过滤时间区间内所接收到的所有告警消息(非稳态告警消息)进行过滤处理,从而,可以将网元设备启动初期由非稳态向稳态进行转换的过程中所形成的大量告警消息进行过滤,避免告警风暴等情况对系统所造成的巨大负担,降低网元设备与网管系统之间的通信流量,提高网元设备处理和告警上报过程的效率和准确性,避免大量非必要告警消息的处理所耗费的人工和系统成本。
下面,结合具体的应用场景,对本发明实施例所提出的技术方案进行说明。
本发明实施例所提出的非稳态告警消息的过滤方案的详细思路如下:
在网元设备初始化成功后的一定时间T(该时长可以根据不同单板类型配置)内,对网元设备内告警源检测并上报的告警消息进行延时过滤处理后,上报至OMC网管系统。
其具体的过滤处理包括:重复告警产生消息过滤、成对告警消息过滤、非法告警清除消息过滤三个方面。
其具体方案的原理示意图如图3所示,其中的OAMS告警处理单元即在网元设备中承担非稳态告警消息过滤功能的功能单元,在实现相同功能的情况下,其具体的物理实体在本实施例中不做限定。
在本发明实施例所提出的技术方案中,当网元设备初始化完成,部署在不同单板上的OAMS告警处理模块在接收到本板的初始化完成指示消息后,启动非稳态过滤定时器,定时器时长设为T(即非稳态告警过滤时间区间的时长,根据不同单板类型配置),在该定时器超时之前,不向OMC网管系统上报告警消息。
在非稳态过滤定时器未超时之前,当OAMS告警处理模块收到告警源上报的告警消息时,不允许这些告警消息上报至OMC网管系统,而是依次在非稳态告警的过滤缓存中,对当前接收到的告警消息进行重复告警产生消息过滤、成对告警消息过滤、非法告警清除消息过滤等处理。
在完成上述的全部过滤步骤处理后,仍然存在的告警消息被认为是有效告警,将有效的告警消息保存在非稳态告警的过滤缓存中,待非稳态过滤定时器超时后,对非稳态告警的过滤缓存中的告警消息进行上报处理。
在本实施例中,基于处理效率的考虑,首先会进行告警消息的类型识别,然后,根据告警消息的不同类型分别进行相应的判断处理过程,相应的具体过程描述参见以下说明。
如图4所示,为本发明实施例所提出的一种具体应用场景下的非稳态告警消息的过滤方法的流程示意图,该方法具体包括以下步骤:
步骤S401、网元设备初始化完成,启动非稳态过滤定时器。
其中,该定时器时长设为T,即前述非稳态告警过滤时间区间的时长,其具体的长度可以根据不同单板类型配置。
需要说明的是,在本发明实施例所提出的技术方案中,非稳态告警消息的过滤处理,可以是基于网元设备中不同的单板类型处理的。
网元设备中不同功能的单板,启动完成后从非稳态转为稳态的时间也不同,因此,处于非稳态的时长应该根据单板功能类型不同而有所差异。
为了确保网元设备内的告警消息能在设备进入稳态后及时上报至OMC网管系统,本发明实施例所提出的技术方案中,对非稳态告警过滤时间区间的时长采用可配置的方式。即在网元设备启动之前,对各个不同类型的功能单板,需要根据实际工作中的启动成功的时间进行非稳态告警过滤时间区间的时长配置。
步骤S402、网元设备判断非稳态过滤定时器是否超时。
如果没有超时,则表示当前仍需要对非稳态告警消息进行过滤,执行步骤S403;
如果超时,则表示当前不再需要对非稳态告警消息进行过滤,执行步骤S411。
步骤S403、网元设备接收到告警源上报的告警消息。
步骤S404、网元设备将接收到的告警消息依次在非稳态告警的过滤缓存中进行缓存。
即按照接收到告警消息的先后顺序进行缓存,这样的处理可以方便后续的过滤处理,例如,对于成对告警消息的判断处理过程,依次缓存的方式方便了告警产生消息和告警清除消息接收顺序的识别。
步骤S405、网元设备识别所缓存的告警消息的告警上报类型。
如果告警上报类型是告警产生消息,则执行步骤S406;
如果告警上报类型是告警清除消息,则执行步骤S408。
需要说明的是,此步骤是前述的步骤S201中的重复校验中的一个子过程,这样做的考虑主要是按照不同的告警上报类型进行区分的话,相应的后续处理可以更有针对性,例如,不会对告警产生消息进行非法告警清除消息的判断和过滤处理,也不会对告警清除消息进行重复告警产生消息的判断和过滤处理。
步骤S406、网元设备将该告警产生消息与已缓存的其他告警产生消息进行比较,判断是否为重复告警产生消息。
即执行前述的判断过程一,由于比较的范围均为告警产生消息,因此,可以直接按照告警编号相同,告警对象相同的标准来确定重复告警产生消息。
如果判断结果为是,则执行步骤S407;
如果判断结果为否,则表示本告警产生消息不是已缓存的告警产生消息的重复告警产生消息,在此种情况下,则该告警产生消息当前为正常告警消息(由于成对告警消息中的告警产生消息的接收时间必然先于告警清除消息的接收时间,因此,在步骤S404按照接收先后顺序进行缓存的情况下,当前的告警产生消息不可能与已经缓存的告警清除消息组成成对告警消息),因此,对于此告警产生消息的处理即告结束,该告警产生消息可以继续保存在非稳态告警的过滤缓存中,然后可以返回步骤S402,继续执行后续的处理。
步骤S407、网元设备保留该告警产生消息,并将之前保存的与该告警产生消息相重复的告警产生消息进行丢弃。
本步骤执行完成后,则表示本告警产生消息所对应的已缓存的重复告警产生消息已被过滤,在此种情况下,该告警产生消息当前为正常告警消息(由于成对告警消息中的告警产生消息的接收时间必然先于告警清除消息的接收时间,因此,在步骤S404按照接收先后顺序进行缓存的情况下,当前的告警产生消息不可能与已经缓存的告警清除消息组成成对告警消息),因此,对于此告警产生消息的处理即告结束,该告警产生消息可以继续保存在非稳态告警的过滤缓存中,然后可以返回步骤S402,继续执行后续的处理。
步骤S408、网元设备将该告警清除消息与已缓存的告警产生消息进行匹配,判断是否为非法告警清除消息。
即执行前述的判断过程三,由于进行匹配的范围为已缓存的告警产生消息(由于步骤S404中告警消息的缓存顺序是按照接收顺序进行的,所以,这些告警产生消息的接收时间必然早于本告警清除消息的接收时间),因此,可以直接按照是否存在告警编号相同,告警对象相同的标准来确定非法告警清除消息的不存在或者存在。
如果在已缓存的告警产生消息中,网元设备确定不存在与该告警清除消息具有相同的告警编号和告警对象的告警产生消息,则判断该告警清除消息为非法告警清除消息,即判断结果为是,则执行步骤S409;
如果在已缓存的告警产生消息中,网元设备确定存在与该告警清除消息具有相同的告警编号和告警对象的告警产生消息,则判断该告警清除消息不是非法告警清除消息,即判断结果为否,则执行步骤S410。
步骤S409、网元设备直接将该告警清除消息进行丢弃。
本步骤执行完成后,对于此告警消息的处理即告结束,可以返回步骤S402,继续执行后续的处理。
步骤S410、网元设备确定该告警清除消息和已缓存的与其相匹配的告警产生消息为成对告警消息,将这两条告警消息进行丢弃。
此过程即为前述的判断流程二,在本实施例中,基于按照接收时间先后所进行的依次缓存,以及按照告警上报类型的分类处理,可以将之前的判断流程二和判断流程三合并在一起执行,即网元设备所接收到的告警清除消息,要么在步骤S408判断结果为是的情况下,被确定为非法告警清除消息,通过步骤S409进行丢弃,要么在步骤S408判断结果为否的情况下,被步骤S410确定为成对告警消息,和与其相匹配的告警产生消息一起被丢弃。
通过以上的各步骤的处理,对所有的重复告警产生消息,与告警清除消息组成成对告警消息的告警产生消息,以及所有告警清除消息进行了过滤。
因此,通过前述的各步骤,完成对所有非稳态告警消息的过滤处理后,在前述的非稳态告警的过滤缓存中,当前只剩下了正常的告警产生消息,或者,完全没有剩下任何的告警消息,有效地过滤了不需要进行上报处理的告警消息。
在步骤S402判断非稳态过滤定时器超时后,向网管系统上报的告警消息被大幅的减少了。
步骤S411、网元设备将非稳态告警的过滤缓存中所剩余的所有告警消息,以及非稳态过滤定时器超时后所接收到的告警消息,向网管系统进行上报。
至此,网元设备进入正常的告警消息处理流程。
需要说明的是,上述的处理过程对前述的判断过程一至三的执行方式进行了优化处理,基于告警上报类型的区分处理,以及告警消息的依次缓存实现了相应处理过程的合并,提高了相应的处理效率,但是,在实际应用中,也可以不进行这样的优化,而是直接将前述的判断过程一至三按照先后顺序或者同时执行,这样的同样可以达到相同的技术效果,只是其在对每一个告警消息进行判断处理时,需要进行匹配或者判断的其他告警消息的数量会有所提高,但这并不影响最终对非稳态告警消息的过滤处理,因此,同样属于本发明实施例的保护范围。
与现有技术相比,本发明实施例所提出的技术方案具有以下优点:
通过应用本发明实施例的技术方案,可以在网元设备启动后,对于网元设备在非稳态告警过滤时间区间内所接收到的所有告警消息(非稳态告警消息)进行过滤处理,从而,可以将网元设备启动初期由非稳态向稳态进行转换的过程中所形成的大量告警消息进行过滤,避免告警风暴等情况对系统所造成的巨大负担,降低网元设备与网管系统之间的通信流量,提高网元设备处理和告警上报过程的效率和准确性,避免大量非必要告警消息的处理所耗费的人工和系统成本。
为了实现本发明实施例的技术方案,本发明实施例还提供了一种网元设备,其结构示意图如图5所示,至少包括:
计时模块51,用于在所述网元设备启动后,对非稳态告警过滤时间区间进行计时;
识别模块52,用于将所述网元设备在所述非稳态告警过滤时间区间内接收到的所有告警消息进行缓存,并进行识别;
判断模块53,用于根据所述识别模块52所进行识别的结果,分别判断各告警消息是否属于待过滤告警消息;
过滤模块54,用于对所述判断模块53的判断结果为是的告警消息进行过滤;
发送模块55,用于在所述非稳态告警过滤时间区间结束后,将所述判断模块53的判断结果为否的告警消息发送给网管系统。
在实际的应用场景中,
所述计时模块51,具体用于在所述网元设备启动后,开始进行非稳态告警过滤时间区间的计时;
所述识别模块52,具体用于将所述网元设备在所述非稳态过滤定时器超时前接收到的所有告警消息在非稳态告警的过滤缓存中进行缓存,并对所缓存的所有告警消息进行重复校验。
需要说明的是,对应前述的判断过程一,
所述判断模块53,具体用于在所述识别模块52识别到所述网元设备在非稳态告警过滤时间区间所接收到的一个告警消息与一个或多个其他告警消息的告警编号相同,告警对象相同,且告警上报类型同为告警产生时,确定所述告警消息与所述一个或多个其他告警消息互为重复告警产生消息,属于待过滤告警消息;
所述过滤模块54,具体用于保留所述判断模块53所确定的所述重复告警产生消息中最后一次上报的有效告警产生消息,并将其他所述重复告警产生消息进行丢弃;
所述发送模块55,具体用于在所述计时模块51所计时的非稳态告警过滤时间区间结束后,将所述过滤模块54所保留的所述有效告警产生消息发送给网管系统。
对应前述的判断过程二,
所述判断模块53,具体用于在所述识别模块52识别到所述网元设备在非稳态告警过滤时间区间所接收到的两个告警消息的告警编号相同,告警对象相同,但告警上报类型分别为告警产生和告警清除,并且所述网元设备接收到告警产生的告警消息的时间早于接收到告警清除的告警消息的时间时,确定两个所述告警消息为成对告警消息,属于待过滤告警消息;
所述过滤模块54,具体用于对所述判断模块53所确定的成对告警消息进行丢弃。
对应前述的判断过程三,
所述判断模块53,具体用于在所述识别模块52识别到所述网元设备在非稳态告警过滤时间区间接收到一个告警上报类型为告警清除的告警消息,但在接收到所述告警消息之前,没有接收到具有相同告警编号,相同告警对象,且告警上报类型为告警产生的告警消息时,确定所述告警消息为非法告警清除消息,属于待过滤告警消息;
所述过滤模块54,具体用于对所述判断模块53所确定的非法告警清除消息进行丢弃。
需要进一步指出的是,所述非稳态告警过滤时间区间的长度,具体为:
所述网元设备启动后达到稳态所需要的时间的长度;或,
所述网元设备启动后达到稳态所需要的时间,与所述网元设备在达到稳定时间后可能接收到待过滤告警消息的保护时间的长度之和。
相应的具体说明参见前述的步骤S201,在此不再重复描述。
与现有技术相比,本发明实施例所提出的技术方案具有以下优点:
通过应用本发明实施例的技术方案,可以在网元设备启动后,对于网元设备在非稳态告警过滤时间区间内所接收到的所有告警消息(非稳态告警消息)进行过滤处理,从而,可以将网元设备启动初期由非稳态向稳态进行转换的过程中所形成的大量告警消息进行过滤,避免告警风暴等情况对系统所造成的巨大负担,降低网元设备与网管系统之间的通信流量,提高网元设备处理和告警上报过程的效率和准确性,避免大量非必要告警消息的处理所耗费的人工和系统成本。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明实施例可以通过硬件实现,也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解,本发明实施例的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或网络侧设备等)执行本发明实施例各个实施场景所述的方法。
本领域技术人员可以理解附图只是一个优选实施场景的示意图,附图中的模块或流程并不一定是实施本发明实施例所必须的。
本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中,也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块,也可以进一步拆分成多个子模块。
上述本发明实施例序号仅仅为了描述,不代表实施场景的优劣。
以上公开的仅为本发明实施例的几个具体实施场景,但是,本发明实施例并非局限于此,任何本领域的技术人员能思之的变化都应落入本发明实施例的业务限制范围。
Claims (15)
1.一种非稳态告警消息的过滤方法,其特征在于,至少包括以下步骤:
网元设备启动后,所述网元设备将自身在非稳态告警过滤时间区间内接收到的所有告警消息进行缓存,并进行识别;
所述网元设备根据所述识别的结果,分别判断各告警消息是否属于待过滤告警消息;
如果判断结果为是,所述网元设备对所述告警消息进行过滤;
如果判断结果为否,所述网元设备在所述非稳态告警过滤时间区间结束后,将所述告警消息发送给网管系统。
2.如权利要求1所述的方法,其特征在于,所述网元设备启动后,所述网元设备将自身在非稳态告警过滤时间区间内接收到的所有告警消息进行缓存,并进行识别,具体为:
所述网元设备初始化完成后,开始进行非稳态告警过滤时间区间的计时;
所述网元设备将自身在所述计时超时前接收到的所有告警消息在非稳态告警的过滤缓存中进行缓存,并对所缓存的所有告警消息进行重复校验。
3.如权利要求1所述的方法,其特征在于,所述网元设备根据所述识别的结果,分别判断各告警消息是否属于待过滤告警消息,具体包括:
当所述网元设备识别到自身在非稳态告警过滤时间区间所接收到的一个告警消息与一个或多个其他告警消息的告警编号相同,告警对象相同,且告警上报类型同为告警产生时,所述网元设备确定所述告警消息与所述一个或多个其他告警消息互为重复告警产生消息,属于待过滤告警消息。
4.如权利要求3所述的方法,其特征在于,当所述网元设备确定所述告警消息与所述一个或多个其他告警消息互为重复告警产生消息,属于待过滤告警消息时,所述网元设备对所述告警消息进行过滤,具体为:
所述网元设备保留所述重复告警产生消息中最后一次上报的有效告警产生消息,并将其他所述重复告警产生消息进行丢弃;
所述网元设备在所述非稳态告警过滤时间区间结束后,将所保留的所述有效告警产生消息发送给网管系统。
5.如权利要求1所述的方法,其特征在于,所述网元设备根据所述识别的结果,分别判断各告警消息是否属于待过滤告警消息,具体包括:
当所述网元设备识别到自身在非稳态告警过滤时间区间所接收到的两个告警消息的告警编号相同,告警对象相同,但告警上报类型分别为告警产生和告警清除,并且所述网元设备接收到告警产生的告警消息的时间早于接收到告警清除的告警消息的时间时,所述网元设备确定两个所述告警消息为成对告警消息,属于待过滤告警消息。
6.如权利要求5所述的方法,其特征在于,当所述网元设备确定两个所述告警消息为成对告警消息,属于待过滤告警消息时,所述网元设备对所述告警消息进行过滤,具体为:
所述网元设备对所述成对告警消息进行丢弃。
7.如权利要求1所述的方法,其特征在于,所述网元设备根据所述识别的结果,分别判断各告警消息是否属于待过滤告警消息,具体包括:
当所述网元设备识别自身在非稳态告警过滤时间区间接收到一个告警上报类型为告警清除的告警消息,但在接收到所述告警消息之前,没有接收到具有相同告警编号,相同告警对象,且告警上报类型为告警产生的告警消息时,所述网元设备确定所述告警消息为非法告警清除消息,属于待过滤告警消息。
8.如权利要求7所述的方法,其特征在于,当所述网元设备确定所述告警消息为非法告警清除消息,属于待过滤告警消息时,所述网元设备对所述告警消息进行过滤,具体为:
所述网元设备对所述非法告警清除消息进行丢弃。
9.如权利要求1至8中任意一项所述的方法,其特征在于,所述非稳态告警过滤时间区间的长度,具体为:
所述网元设备启动后达到稳态所需要的时间的长度;或,
所述网元设备启动后达到稳态所需要的时间,与所述网元设备在达到稳定时间后可能接收到待过滤告警消息的保护时间的长度之和。
10.一种网元设备,其特征在于,包括:
计时模块,用于在所述网元设备启动后,对非稳态告警过滤时间区间进行计时;
识别模块,用于将所述网元设备在所述非稳态告警过滤时间区间内接收到的所有告警消息进行缓存,并进行识别;
判断模块,用于根据所述识别模块所进行识别的结果,分别判断各告警消息是否属于待过滤告警消息;
过滤模块,用于对所述判断模块的判断结果为是的告警消息进行过滤;
发送模块,用于在所述非稳态告警过滤时间区间结束后,将所述判断模块的判断结果为否的告警消息发送给网管系统。
11.如权利要求10所述的网元设备,其特征在于,
所述计时模块,具体用于在所述网元设备启动后,开始进行非稳态告警过滤时间区间的计时;
所述识别模块,具体用于将所述网元设备在所述非稳态过滤定时器超时前接收到的所有告警消息在非稳态告警的过滤缓存中进行缓存,并对所缓存的所有告警消息进行重复校验。
12.如权利要求10所述的网元设备,其特征在于,
所述判断模块,具体用于在所述识别模块识别到所述网元设备在非稳态告警过滤时间区间所接收到的一个告警消息与一个或多个其他告警消息的告警编号相同,告警对象相同,且告警上报类型同为告警产生时,确定所述告警消息与所述一个或多个其他告警消息互为重复告警产生消息,属于待过滤告警消息;
所述过滤模块,具体用于保留所述判断模块所确定的所述重复告警产生消息中最后一次上报的有效告警产生消息,并将其他所述重复告警产生消息进行丢弃;
所述发送模块,具体用于在所述计时模块所计时的非稳态告警过滤时间区间结束后,将所述过滤模块所保留的所述有效告警产生消息发送给网管系统。
13.如权利要求10所述的网元设备,其特征在于,
所述判断模块,具体用于在所述识别模块识别到所述网元设备在非稳态告警过滤时间区间所接收到的两个告警消息的告警编号相同,告警对象相同,但告警上报类型分别为告警产生和告警清除,并且所述网元设备接收到告警产生的告警消息的时间早于接收到告警清除的告警消息的时间时,确定两个所述告警消息为成对告警消息,属于待过滤告警消息;
所述过滤模块,具体用于对所述判断模块所确定的成对告警消息进行丢弃。
14.如权利要求10所述的网元设备,其特征在于,
所述判断模块,具体用于在所述识别模块识别到所述网元设备在非稳态告警过滤时间区间接收到一个告警上报类型为告警清除的告警消息,但在接收到所述告警消息之前,没有接收到具有相同告警编号,相同告警对象,且告警上报类型为告警产生的告警消息时,确定所述告警消息为非法告警清除消息,属于待过滤告警消息;
所述过滤模块,具体用于对所述判断模块所确定的非法告警清除消息进行丢弃。
15.如权利要求10至14中任意一项所述的网元设备,其特征在于,所述非稳态告警过滤时间区间的长度,具体为:
所述网元设备启动后达到稳态所需要的时间的长度;或,
所述网元设备启动后达到稳态所需要的时间,与所述网元设备在达到稳定时间后可能接收到待过滤告警消息的保护时间的长度之和。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2012101317490A CN102664759A (zh) | 2012-05-02 | 2012-05-02 | 非稳态告警消息的过滤方法和设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2012101317490A CN102664759A (zh) | 2012-05-02 | 2012-05-02 | 非稳态告警消息的过滤方法和设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN102664759A true CN102664759A (zh) | 2012-09-12 |
Family
ID=46774178
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2012101317490A Pending CN102664759A (zh) | 2012-05-02 | 2012-05-02 | 非稳态告警消息的过滤方法和设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102664759A (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102882723A (zh) * | 2012-09-28 | 2013-01-16 | 烽火通信科技股份有限公司 | 通信网络中告警时序错差的处理方法及装置 |
CN103401700A (zh) * | 2013-07-18 | 2013-11-20 | 大唐移动通信设备有限公司 | 一种频次抖动告警的处理方法和设备 |
CN105450443A (zh) * | 2015-11-12 | 2016-03-30 | 上海斐讯数据通信技术有限公司 | 用于网络设备告警信息的冗余处理装置及其方法 |
CN108831131A (zh) * | 2018-06-28 | 2018-11-16 | 北京百悟科技有限公司 | 一种报警事件的处理方法、装置及计算机可读存储介质 |
CN115150247A (zh) * | 2022-05-27 | 2022-10-04 | 山东浪潮科学研究院有限公司 | 告警消除方法及装置 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101582807A (zh) * | 2009-07-02 | 2009-11-18 | 北京讯风光通信技术开发有限责任公司 | 一种基于北向接口实现网络管理的方法及系统 |
US7711811B1 (en) * | 2003-03-26 | 2010-05-04 | Sprint Communications Company L.P. | Filtering approach for network system alarms based on lifecycle state |
CN101958803A (zh) * | 2010-09-09 | 2011-01-26 | 中兴通讯股份有限公司 | 基于通讯网络的告警压缩系统及方法 |
CN102263670A (zh) * | 2011-08-29 | 2011-11-30 | 大唐移动通信设备有限公司 | 一种告警消息的上报处理方法及装置 |
-
2012
- 2012-05-02 CN CN2012101317490A patent/CN102664759A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7711811B1 (en) * | 2003-03-26 | 2010-05-04 | Sprint Communications Company L.P. | Filtering approach for network system alarms based on lifecycle state |
CN101582807A (zh) * | 2009-07-02 | 2009-11-18 | 北京讯风光通信技术开发有限责任公司 | 一种基于北向接口实现网络管理的方法及系统 |
CN101958803A (zh) * | 2010-09-09 | 2011-01-26 | 中兴通讯股份有限公司 | 基于通讯网络的告警压缩系统及方法 |
CN102263670A (zh) * | 2011-08-29 | 2011-11-30 | 大唐移动通信设备有限公司 | 一种告警消息的上报处理方法及装置 |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102882723A (zh) * | 2012-09-28 | 2013-01-16 | 烽火通信科技股份有限公司 | 通信网络中告警时序错差的处理方法及装置 |
CN102882723B (zh) * | 2012-09-28 | 2014-12-24 | 烽火通信科技股份有限公司 | 通信网络中告警时序错差的处理方法及装置 |
CN103401700A (zh) * | 2013-07-18 | 2013-11-20 | 大唐移动通信设备有限公司 | 一种频次抖动告警的处理方法和设备 |
CN103401700B (zh) * | 2013-07-18 | 2017-08-25 | 大唐移动通信设备有限公司 | 一种频次抖动告警的处理方法和设备 |
CN105450443A (zh) * | 2015-11-12 | 2016-03-30 | 上海斐讯数据通信技术有限公司 | 用于网络设备告警信息的冗余处理装置及其方法 |
CN108831131A (zh) * | 2018-06-28 | 2018-11-16 | 北京百悟科技有限公司 | 一种报警事件的处理方法、装置及计算机可读存储介质 |
CN115150247A (zh) * | 2022-05-27 | 2022-10-04 | 山东浪潮科学研究院有限公司 | 告警消除方法及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102664759A (zh) | 非稳态告警消息的过滤方法和设备 | |
CN105430681A (zh) | 异常自动上传及恢复方法、装置及移动终端 | |
CN104079724B (zh) | 一种手机卡掉卡恢复方法及应用手机卡的移动终端 | |
CN101588246A (zh) | 防范分布式阻断服务DDoS攻击的方法、网络设备和网络系统 | |
CN102404141B (zh) | 一种告警抑制的方法及装置 | |
EP2800024A1 (en) | System and methods for identifying applications in mobile networks | |
CN101916499B (zh) | 一种智能报警装置及智能报警方法 | |
CN104579746A (zh) | 双链路传输控制方法及装置 | |
CN106301544B (zh) | 光网络单元onu掉电告警信息的处理方法及装置 | |
CN105208590A (zh) | 移动终端操作系统卡顿异常的检测恢复方法及移动终端 | |
CN114006771B (zh) | 一种流量检测方法及装置 | |
CN109918261B (zh) | 故障监听方法、装置、设备及计算机可读存储介质 | |
CN101296135A (zh) | 故障信息的处理方法和装置 | |
CN111193664A (zh) | 计算机网络的链路备份方法及装置 | |
CN102045181A (zh) | 一种终端脱网故障的处理方法和装置 | |
CN104104542B (zh) | 一种基于rs485的实时智能排障方法 | |
CN101989933A (zh) | 一种故障检测的方法和系统 | |
CN108566363A (zh) | 基于流式计算的暴力破解确定方法和系统 | |
CN110677480A (zh) | 一种节点健康管理方法、装置和计算机可读存储介质 | |
CN101247265A (zh) | 一种告警处理方法、装置和系统 | |
CN107888424A (zh) | 告警信息识别方法及装置、网络管理系统 | |
CN101350735A (zh) | 一种告警同步方法 | |
CN110224872B (zh) | 一种通信方法、装置及存储介质 | |
CN102325171B (zh) | 一种监控系统中数据的存储方法及其系统 | |
CN103761157A (zh) | 一种基于多任务巡检策略实现系统容错机制的方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20120912 |