CN102045204A - 一种故障处理系统及方法 - Google Patents

Abstract

本发明公开了一种故障处理系统及方法，克服现有技术中对故障进行告警时不够灵活的缺陷。该方法包括：任务检测模块检测到网元设备上的任务处理出现故障时产生EB消息；故障检测模块检测到网元设备上的系统运行出现故障时产生EB消息；EB事件处理模块将全部EB消息发送给告警输出模块，并根据告警处理模块的处理能力将部分EB消息发送给告警处理模块；告警输出模块将EB事件处理模块发送过来的EB消息转换为告警消息并发送；告警处理模块处理EB事件处理模块发送过来的EB消息。本发明的一个实施例把故障检测和告警输出分为两个任务，通过EB事件把二者联系起来，使得故障检测和告警输出更加灵活高效。

Description

一种故障处理系统及方法

技术领域

本发明涉及网络管理技术，尤其涉及一种故障处理系统及方法。

背景技术

随着通信技术的发展，网络规模不断扩大，网络复杂性也在不断增加。现代通信网络复杂度的增加以及对自动化管理的要求，需要对出现的故障能够进行高效的管理。

网络设备(网元设备)在运行过程中，出现软硬件的故障时，会把相应的故障数据生成告警消息传输到用户检测显示端(网管设备)，通知用户何种网元设备的何种位置出现了何种问题。若引起该告警的故障已经被修复，则生成相应的告警恢复信息传输到用户检测显示端以通知给用户。由此可见，告警消息一般分为两种：告警产生和告警恢复。

一般的故障检测分为两种方式：一种是轮询的方式，另一种是中断的方式。轮询的方式就是通过中央处理器(Central Processing Unit，简称CPU)定时读取故障状态指示的标志进行告警；中断的方式就是当故障发生时，产生告警中断，CPU则停止正在处理的任务来响应中断，进行告警的处理。

在现有技术中，故障检测和告警输出一般都在同一个任务中完成，检测到告警事件后就进行告警输出处理。告警输出一般采用简单网络管理协议(Simple Network Management Protocol，简称为SNMP)的异常情况(trap)的方式把告警消息输出到网管设备。

图1为现有技术通过SNMP协议通知告警的示意图。如图1所示，网元侧的任务A在检测到告警后，采用SNMP协议向网管侧的SNMP协议服务器发送告警。网元侧的告警任务也可以主动检测告警，在告警任务检测到告警之后，也采用SNMP协议向网管侧的SNMP协议服务器发送告警。网元侧在检测到告警之后，也可以在网元侧直接进行告警处理；如图1所示，任务B检测到告警后，直接对告警进行处理。

SNMP是目前网管系统中常用的标准通讯协议，采用管理者(Manager)/代理(Agent)架构，其中网管设备作为Manager，网元设备作为Agent。网元设备通过SNMP协议中定义的trap消息发送网元告警或者告警恢复信息到网管设备。

SNMP协议一般采用UDP协议来发送和接收SNMP消息，由于UDP协议具有不可靠性，所以有可能存在告警消息无法及时、正确地送到网管设备的情况。现有技术一般采用在SNMP协议下增加确认机制等方法来解决这个问题。

本发明的发明人在实现本发明的过程中，发现现有技术至少存在如下缺陷：

1)告警处理方式不够灵活；由于故障检测和告警输出在同一个任务中完成，检测到告警事件就进行相应的告警输出处理，这种故障检测和告警输出绑定在一起的处理方式不够灵活；

2)通用性差，资源利用率不高；不同的告警之间无法共用相同的资源，比如利用软件实现告警时，增加新的告警时一般需要完整地增加与该告警相应的代码，代码改动较大；而且，如果不同的任务均检测到告警，也必须各自实现告警输出；

3)告警的输出方式比较单一，一般只采用SNMP协议中定义的trap消息输出告警；为了保证输出告警的可靠性，现有技术虽然在SNMP协议中加入了确认机制，能够一定程度上可以解决可靠性问题，但是同时丧失了故障告警通用性。

另一方面，由于网络环境或网元设备不稳定等原因，某种告警可能会频繁地出现告警产生-告警恢复-告警产生-告警恢复-...，这种问题一般称之为闪断告警。闪断告警一般会导致网管界面频繁刷新，显示大量重复告警消息，给用户定位故障带来困难。现有技术都是不区分地对所有的告警采取某种的处理方法，过滤掉多余的告警消息，以避免告警闪断所带来的弊端。

另外，现有技术对所有告警都将其视为闪断告警并据此进行针对性处理。实际上，有的告警不可能成为闪断告警，因此也就没有必要将其作为闪断告警进行处理。

而且，现有技术对于闪断告警的处理方法，也还存在着各种不同的不足之处。

一种现有技术对告警产生和告警恢复分别进行处理，各自判定重复周期；两条告警产生的时间间隔小于预定重复周期，就保留第一条告警产生并且过滤掉第二条告警产生；两条告警恢复间的时间小于预定重复周期，就保留第一条告警恢复并且过滤掉第二条告警恢复。这种技术有可能出现告警已经恢复但是告警状态仍然是告警产生的情况。例如：告警重复周期设为1秒，两条告警产生时间点分别为：第0秒和第1.2秒，两条告警恢复时间点分别为：第0.8秒(对应于第0秒的告警产生)和第1.6秒(对应于第1.2秒的告警产生)，在第0秒和第1.2秒发送两条告警产生，但只在第0.8秒发送1条告警恢复，这样用户得到的信息是第二次告警产生还并没有恢复，但是实际告警已经恢复了。反过来，可能还会向用户发送一条告警产生和两条甚至更多的告警恢复，导致用户可能会产生不明所以的疑问。因此这种现有技术容易漏掉告警产生或者告警恢复，导致用户所得到的告警状态并不准确。

另一种现有技术是通过告警频率来判断闪断告警的开始和结束。但是在实际应用中，存在着开始和结束的判断过程中，可能又发送了好几个重复告警了。因此，这种现有技术实时性差，效率较为低下，不能满足实时应用的要求。

还一种现有技术省略闪断告警的中间状态，仅在闪断告警的最后，上报一条告警产生和一条告警恢复。比如在10分钟内产生100条告警产生和告警恢复，但是最后只上报了第100条告警产生和相应的第100条告警恢复，这种技术方案使得用户无从知晓系统的“闪断”状态及过程，不利于用户了解故障的实质，而且还一定程度上掩盖了故障的性质，易使用户得出错误结论。

发明内容

本发明所要解决的技术问题是需要提供一种故障处理系统及方法，克服现有技术中对故障进行告警时不够灵活的缺陷。

为了解决上述技术问题，本发明首先提供了一种故障处理系统，包括任务检测模块、故障检测模块、事件代理(EB)事件处理模块、告警输出模块以及告警处理模块，其中：

所述任务检测模块，用于检测到网元设备上的任务处理出现故障时，产生EB消息；

所述故障检测模块，用于检测到所述网元设备上的系统运行出现故障时，产生EB消息；

所述EB事件处理模块，存储有各种EB消息的类型，用于接收所述任务检测模块发送的EB消息及所述故障检测模块发送的EB消息，将全部EB消息发送给所述告警输出模块，并根据所述告警处理模块的处理能力将部分EB消息发送给所述告警处理模块；

所述告警输出模块，用于将所述EB事件处理模块发送过来的EB消息转换为告警消息并发送；

所述告警处理模块，用于处理所述EB事件处理模块发送过来的EB消息。

优选地，所述任务检测模块及所述故障检测模块用于向所述EB事件处理模块注册能够发送的EB消息的类型；所述告警输出模块及所述告警处理模块用于向所述EB事件处理模块注册能够接收的EB消息的类型。

优选地，所述告警输出模块用于以简单网络管理协议异常情况输出方式将所述告警消息发送给简单网络管理协议服务器，或者以系统日志输出方式将告警消息发送给系统日志服务器，或者以继电器输出方式将告警消息发送给继电器告警装置。

优选地，所述任务检测模块用于检测到所述任务处理出现故障时产生一个任务告警产生，故障恢复时产生一个相应的任务故障恢复；

其中，所述任务检测模块产生的EB消息，包括所述任务告警产生以及任务故障恢复。

优选地，所述告警输出模块用于在所述任务检测模块产生所述任务告警产生时输出一个任务告警信号，开始预设的限速周期的计时；并用于在所述任务检测模块产生所述任务告警恢复且直至所述任务告警恢复所属限速周期结束未再产生任务告警产生时，于所述任务告警恢复所属限速周期结束时产生一个任务恢复信号。

优选地，所述故障检测模块用于检测到所述系统运行出现故障时产生一个系统告警产生，故障恢复时产生一个相应的系统故障恢复；

其中，所述故障检测模块产生的EB消息，包括所述系统告警产生以及系统故障恢复。

优选地，所述告警输出模块用于在所述故障检测模块产生所述故障告警产生时输出一个故障告警信号，开始预设的限速周期的计时；并用于在所述故障检测模块产生所述故障告警恢复且直至所述故障告警恢复所属限速周期结束未再产生故障告警产生时，于所述故障告警恢复所属限速周期结束时产生一个故障恢复信号。

为了解决上述技术问题，本发明还提供了一种故障处理方法，用于故障处理系统处理故障告警，该故障处理系统包括任务检测模块、故障检测模块、事件代理(EB)事件处理模块、告警输出模块以及告警处理模块；

所述方法包括如下步骤：

所述任务检测模块检测到网元设备上的任务处理出现故障时，产生EB消息；

所述故障检测模块检测到所述网元设备上的系统运行出现故障时，产生EB消息；

所述EB事件处理模块接收所述任务检测模块发送的EB消息及所述故障检测模块发送的EB消息，将全部EB消息发送给所述告警输出模块，并根据所述告警处理模块的处理能力将部分EB消息发送给所述告警处理模块；

所述告警输出模块将所述EB事件处理模块发送过来的EB消息转换为告警消息并发送；

所述告警处理模块处理所述EB事件处理模块发送过来的EB消息。

优选地，所述任务检测模块及所述故障检测模块向所述EB事件处理模块注册能够发送的EB消息的类型；所述告警输出模块及所述告警处理模块向所述EB事件处理模块注册能够接收的EB消息的类型。

优选地，所述告警输出模块以简单网络管理协议异常情况输出方式将所述告警消息发送给简单网络管理协议服务器，或者以系统日志输出方式将告警消息发送给系统日志服务器，或者以继电器输出方式将告警消息发送给继电器告警装置。

优选地，所述任务检测模块检测到所述任务处理出现故障时产生一个任务告警产生，故障恢复时产生一个相应的任务故障恢复；

其中，所述任务检测模块产生的EB消息，包括所述任务告警产生以及任务故障恢复。

优选地，所述告警输出模块在所述任务检测模块产生所述任务告警产生时输出一个任务告警信号，开始预设的限速周期的计时；并在所述任务检测模块产生所述任务告警恢复且直至所述任务告警恢复所属限速周期结束未再产生任务告警产生时，于所述任务告警恢复所属限速周期结束时产生一个任务恢复信号。

优选地，所述故障检测模块检测到所述系统运行出现故障时产生一个系统告警产生，故障恢复时产生一个相应的系统故障恢复；

其中，所述故障检测模块产生的EB消息，包括所述系统告警产生以及系统故障恢复。

优选地，所述告警输出模块在所述故障检测模块产生所述故障告警产生时输出一个故障告警信号，开始预设的限速周期的计时；并在所述故障检测模块产生所述故障告警恢复且直至所述故障告警恢复所属限速周期结束未再产生故障告警产生时，于所述故障告警恢复所属限速周期结束时产生一个故障恢复信号。

与现有技术相比，本发明技术方案的一个实施例把故障检测和告警输出分为两个任务，通过EB事件把二者联系起来，使得故障检测和告警输出更加灵活高效。本发明技术方案的另一个实施例采用限速处理，减少了故障检测的处理时间和复杂性，且保证用户能够了解网元设备产生闪断告警的故障性质。本发明的还一个实施例采用三种告警输出方式进行告警输出，丰富了告警的输出方式，同时也提高了告警消息的可靠性。

附图说明

图1是现有技术通过SNMP协议通知告警的示意图；

图2是本发明实施例的故障处理系统的组成示意图；

图3是本发明另一实施例的故障处理系统的组成示意图；

图4、图5和图6分别是本发明实施例的告警示意图；

图7是本发明实施例的故障处理方法的流程示意图；

图8和图9分别是本发明实施例的实际应用流程示意图。

具体实施方式

以下将结合附图及实施例来详细说明本发明的实施方式，借此对本发明如何应用技术手段来解决技术问题，并达成技术效果的实现过程能充分理解并据以实施。

首先，如果不冲突，本发明实施例以及实施例中的各个特征的相互结合，均在本发明的保护范围之内。另外，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

事件代理(Event Broker，简称为EB)为系统提供集中的事件通知/被通知服务机制。EB将事件检测和事件处理的模块程序分离(解耦)，服务于两种类型的客户，包括：用来检测系统中特定事件(如link up/down)的检测者(Detector)，和用来处理事件(如link up/down)的接收者(Recipient)。检测者通过EB向所有感兴趣的接收者通知事件的发生，接收者通过EB接收通知。

为了获得EB的服务，检测者和接收者都需要向EB注册。当接收者被增加、删除或者修改时，检测者的变动非常小。

实施例一、故障处理系统

如图2所示，本实施例主要包括任务检测模块210、故障检测模块220、EB事件处理模块230、告警输出模块240以及告警处理模块250，其中：

任务检测模块210，用于对网元设备上的各种任务进行处理，当检测到任务处理出现故障需要上报告警时，即产生EB消息发送给EB事件处理模块230；

故障检测模块220，用于对网元设备上各种系统运行环境进行检测，当检测到系统运行出现故障需要上报告警时，即产生EB消息发送给EB事件处理模块230；

EB事件处理模块230，与任务检测模块210及故障检测模块220相连，存储有各种EB消息的类型，用于接收任务检测模块210及故障检测模块220发送的EB消息，根据EB消息的类型发送到相应的接收者；其中，将全部的EB消息发送给告警输出模块240，同时根据告警处理模块250的处理能力，选择性地将部分EB消息发送给告警处理模块250；

告警输出模块240，与EB事件处理模块230相连，用于将接收的EB消息转换为告警消息，并将告警消息发送给SNMP协议服务器300，以向网管设备报告系统运行信息；一般而言，告警输出模块240是将EB消息中的信息完善化而获得告警消息，为网管设备解决问题提供帮助；

告警处理模块250，与EB事件处理模块230相连，用于根据EB事件处理模块230发送过来的EB消息的类型，处理EB事件处理模块230发送过来的EB消息(系统自身能够处理的EB消息)；一般而言，EB消息中大多包含了足够的信息，这部分EB消息可供告警处理模块250直接处理。

本实施例中，EB消息发送者向EB事件处理模块230注册能够发送的EB消息类型，EB消息接收者向EB事件处理模块230注册能够接收的EB消息类型。上述的任务检测模块210和故障检测模块220，即为EB消息发送者；上述的告警输出模块240以及告警处理模块250，即为EB消息接收者。EB事件处理模块230接收到EB消息发送者发送的某类型的EB消息时，根据EB消息的类型把EB消息发送给所有注册了该类型的EB消息接收者。

上述告警处理模块250所处理的EB消息，是系统能力以及告警类型共同决定的。如果EB消息能够在系统内部(告警处理模块250)处理，则该EB消息发送给SNMP协议服务器300的同时，还一并发送给告警处理模块250进行内部处理。

本实施例中，告警输出模块240采用三种告警输出方式，有效保证了告警消息可靠性的问题。这三种告警输出方式具体包括以SNMP trap输出方式将告警消息发送给SNMP服务器、以系统日志(System Logging，简称为syslog)输出方式将告警消息发送给系统日志服务器，以及以继电器输出方式将告警消息发送给继电器告警装置。当然，告警输出模块240同时将告警消息发送给SNMP服务器、系统日志服务器以及继电器告警装置这三者中的两者或全部，也是可行的。

如图3所示，在本发明的其他实施例中，上述实施例中的告警输出模块240还将告警消息输出到外部的syslog服务器(Server)400和警报装置500；当然，从技术上来说，也可以只发送给系统日志服务器400和警报装置500其中之一。

在远端网管侧，采用SNMP协议服务器300以SNMP trap接收告警消息，以及采用系统日志服务器400接收告警消息，二者实现了可靠互补，而无需修改SNMP协议来确保SNMP trap输出的可靠性。系统日志服务器400以系统日志的形式接收告警输出模块240输出的告警。

在告警输出模块240现场，告警输出模块240把告警消息经继电装置(如继电器)输出到外接的警报装置500(如告警灯和/或蜂鸣器等)，如此能更及时地通知现场用户。这里的继电器告警输出并不是针对某一条告警消息的输出，其中的继电器属于全局资源，作为所有告警事件公用的故障输出方式，设备上产生任意一个告警消息，继电器外接的警报装置均会进行报警。直到所有告警消息被清除后，继电器恢复正常输出，继电器外接的告警设备就会停止报警。或者用户收到报警装置的报警后手动关闭报警。

发明人研究发现，由于故障检测的轮询方式是每隔一定的周期查询一次监控参数，每个故障在一个轮询周期内只会被检测到一次，因此在一个轮询周期间隔内不可能会出现不断产生告警产生、告警恢复的现象，所以轮询方式的故障检测，不会在一个轮询周期内产生闪断告警。

故而，闪断告警只能是由于中断方式告警引起的。

通过进一步的分析可以发现，也不是所有的由中断方式产生的告警都会导致闪断告警。因此，对于中断方式产生的告警可分为两种：一种是不可能产生闪断告警的中断式告警，另一种是可能会产生闪断告警的中断式告警。比如端口的up/down告警、由于网线没有插好会导致端口出现时断时续的告警等可能会产生闪断告警；而网元设备掉电告警，由于掉电后网元设备会重启，因此这种告警就不存在告警恢复，也就不会出现闪断告警的现象。

本发明采用的技术方案，是任务检测模块210用于优先采用轮询方式进行任务处理的故障检测，故障检测模块220也用于优先采用轮询方式进行系统运行的故障检测。对于既可以采用中断方式又可以采用轮询方式进行故障检测的告警，任务检测模块210以及故障检测模块220均使用轮询方式；对于只能采用中断方式进行检测的告警，其中可能产生闪断告警的，采取本发明下述的限速处理措施，其中不可能产生闪断告警的，无需考虑(不做处理)。需要说明的是，对于只能采用中断方式进行检测的告警中，哪些可能产生闪断告警，可以根据本领域技术人员的常识性知识来进行分别，本发明对此不做具体限定。

在该限速处理过程中，告警输出模块240采用预设的限速周期来确定告警信号和恢复信号的输出，其中，任务检测模块210检测到网元设备上的任务处理出现故障时产生某一个任务告警产生，此时告警输出模块240输出一个任务告警信号，表示网元设备上的任务处理出现了故障，并开始限速周期的计时。故障检测模块220检测到网元设备上的系统运行出现故障时产生某一个系统告警产生，此时告警输出模块240输出一个系统告警信号，表示网元设备上的系统运行出现了故障，并开始限速周期的计时。

告警输出模块240输出任务告警信号之后，包括第一个限速周期以及后续的任意个限速周期在内，任务检测模块210检测到网元设备上的任务处理产生与之前任务告警产生相应的任务告警恢复，且在直至该任务告警恢复所属的这个限速周期结束，未再产生新的任务告警产生的情形下，在该任务告警恢复所属的限速周期结束时，告警输出模块240输出一任务恢复信号，表示网元设备上业务处理的该故障已经恢复。

告警输出模块240输出系统告警信号之后，包括第一个限速周期以及后续的任意个限速周期在内，故障检测模块220检测到网元设备上的系统运行产生与之前系统告警产生相应的系统告警恢复，且在直至该系统告警恢复所属的这个限速周期结束，未再产生新的系统告警产生的情形下，在该系统告警恢复所属的限速周期结束时，告警输出模块240输出一系统恢复信号，表示网元设备上系统运行的该故障已经恢复。

前述任务检测模块210产生的EB消息，包括上述的任务告警产生以及任务告警恢复。前述的故障检测模块220产生的EB消息，包括上述的系统告警产生以及系统告警恢复。

告警输出模块240可以通过设置告警状态变量来记录告警状态的变化。告警输出模块240输出任务告警信号(或者系统告警信号)时，说明任务检测模块210检测任务处理产生一任务告警产生(或者故障检测模块220检测系统运行产生一系统告警产生)，此时告警输出模块240将告警状态记录为任务告警产生(或者系统告警产生)(需要说明的是，告警输出模块240对于不同的任务告警产生或系统告警产生，以及相应的任务告警恢复或系统告警恢复，会维护不同的告警状态变量)。之后任务检测模块210检测任务处理产生相应的任务告警恢复(或者故障检测模块220检测系统运行产生相应的系统告警恢复)，则告警输出模块240将告警状态更改为任务告警恢复(或者系统告警恢复)。后续如果任务检测模块210检测任务处理继续产生任务告警产生或任务告警恢复(故障检测模块220检测系统运行继续产生系统告警产生或系统告警恢复)，则告警输出模块240相应地变更告警状体为任务告警产生(或者系统告警产生)或任务告警恢复(或者系统告警恢复)。

如果在同一个预设的限速周期T内，每一个告警产生(以下如不特殊声明，统指任务告警产生或者系统告警产生)(图4所示第一告警产生41和第二告警产生44)都对应有相应的告警恢复(以下如不特殊声明，统指任务告警恢复或者系统告警恢复)(图4所示第一告警恢复43和第二告警恢复45)，且最后一个告警恢复直至周期结束未再产生新的告警产生，则在该限速周期T结束时输出一个恢复信号(图4所示恢复信号46)。其中，产生第一个告警产生(图4所示第一告警产生41)时，会输出一个告警信号(图4所示告警信号42)，且将告警状态变量的值更改为告警产生；在产生最后一个告警恢复(第二告警恢复45)时，告警状态变量的值会变更为告警恢复；告警状态变量的值更改的中间过程，不再赘述。

如果在一个预设的限速周期T内，有一个告警产生(两个或两个以上的告警产生时为最后一个告警产生)还没有产生相应的告警恢复，则对后续的周期进行连续记录，直至所有的告警产生都产生有相应的告警恢复，且最后一个告警恢复产生直至周期(该最后一个告警恢复所在的周期)结束再没有产生告警产生，则在该最后一个告警恢复所在的周期结束时输出一个恢复信号(图5所示的恢复信号56，图6所示的恢复信号68)。在这种情形中，首尾两个周期之间，甚至可以包含不产生告警产生并且也不产生告警恢复的“空白”限速周期，其中的“空白”指的是不产生告警产生和告警恢复的限速周期(以图6为基础，比如第二告警产生64和第二告警恢复65之间还可以包含至少一个未产生告警产生和告警恢复的周期)。

在图5所示的示意图中，分别包含第一告警产生51和第二告警产生54，以及第一告警恢复53和第二告警恢复55；在图6所示的示意图中，分别包含第一告警产生61、第二告警产生64和第三告警产生66，第一告警恢复63、第二告警恢复65和第三告警恢复67。其中在第一个告警产生(图5所示的第一告警产生51以及图6所示的第一告警产生61)时输出一个告警信号(图5所示的告警信号52以及图6所示的告警信号62)，且将告警状态变量的值更改为告警产生；在产生最后一个告警恢复(图5所示的第二告警恢复55，图6所示的第三告警恢复67)时，告警状态变量的值会变更为告警恢复；告警状态变量的值的更改的中间过程，不再赘述。

其中，上述限速周期T的起始时刻为产生第一个告警产生(图4所示的第一告警产生41、图5所示的第一告警产生51或者图6所示的第一告警产生61)的时刻。另外，在初始运行时一般不会有告警产生，可以认为是处于告警恢复状态。

需要说明的是，开始限速周期T的计时直至输出恢复信号，所包含的周期数量时不特定的，且为不止两个周期时，除了首尾两个周期之外，中间的周期甚至可以不产生告警产生和/或告警恢复。

经过上述的限速处理后，在予以记录的每个限速周期内，至多仅允许输出一个告警信号和/或一个恢复信号。

实施例二、故障处理方法

结合图2所示故障处理系统，图7所示的本实施例用于图2所示故障处理系统处理故障告警，该故障处理系统主要包括任务检测模块210、故障检测模块220、EB事件处理模块230、告警输出模块240以及告警处理模块250，该方法主要包括如下步骤：

步骤S710，任务检测模块210对网元设备上的各种任务进行处理，当检测到任务处理出现故障需要上报告警时，即产生EB消息发送给EB事件处理模块230；

步骤S720，故障检测模块220对网元设备上的各种系统运行环境进行检测，当检测到系统运行出现故障需要上报告警时，即产生EB消息发送给EB事件处理模块230；

步骤S730，EB事件处理模块230接收任务检测模块210及故障检测模块220发送的EB消息，根据EB消息的类型发送到相应的接收者；其中，将全部的EB消息发送给告警输出模块240，同时根据告警处理模块250的处理能力，选择性地将部分EB消息发送给告警处理模块250；

步骤S740，告警输出模块240将接收的EB消息转换为告警消息，并将告警消息发送给SNMP协议服务器300，以向网管设备报告系统运行信息；一般而言，告警输出模块240是将EB消息中的信息完善化而获得告警消息，为网管设备解决问题提供帮助；

步骤S750，告警处理模块250根据EB事件处理模块230发送过来的EB消息的类型，处理EB事件处理模块230发送过来的EB消息(系统自身能够处理的EB消息)；一般而言，EB消息中大多包含了足够的信息，这部分EB消息可供告警处理模块250直接处理。

在本实施例中，任务检测模块210及故障检测模块220先向EB事件处理模块230注册能够发送的EB消息的类型；告警输出模块240及告警处理模块250先向EB事件处理模块230注册能够接收的EB消息的类型。

上述步骤S740中，告警输出模块240可以以SNMP trap输出方式将告警消息发送给SNMP服务器，也可以以syslog输出方式将告警消息发送给系统日志服务器，还可以以继电器输出方式将告警消息发送给继电器告警装置。当然，告警输出模块240同时将告警消息发送给SNMP服务器、系统日志服务器以及继电器告警装置这三者中的两者或全部，也是可行的。

任务检测模块210检测到任务处理出现故障时产生一个任务告警产生，故障恢复时产生一个相应的任务故障恢复。告警输出模块240在任务检测模块210产生任务告警产生时输出一个任务告警信号，开始预设的限速周期的计时；并在任务检测模块210产生任务告警恢复且直至任务告警恢复所属限速周期结束未再产生任务告警产生时，于任务告警恢复所属限速周期结束时产生一个任务恢复信号。

故障检测模块220检测到系统运行出现故障时产生一个系统告警产生，故障恢复时产生一个相应的系统故障恢复。告警输出模块240在故障检测模块220产生故障告警产生时输出一个故障告警信号，开始预设的限速周期的计时；并在故障检测模块220产生故障告警恢复且直至故障告警恢复所属限速周期结束未再产生故障告警产生时，于故障告警恢复所属限速周期结束时产生一个故障恢复信号。

为使上述技术方案能说明得更加清晰，以下以端口down告警这一实际应用为例进行具体的阐述，并请继续参考图4。

如图8所示，本实际应用包括如下步骤：

步骤S810，网元设备启动后中断上报第一告警产生41(即端口down告警)时，开启一限速定时器用以记录限速周期；在其他实施例中，也可以是其他任意的一个告警产生开始时记录限速周期；

步骤S820，产生一告警信号(即告警信号42)并输出给网管设备，在一寄存器上将告警状态设置为告警产生；

步骤S830，由于限速定时器没有到时，因此继续等待中断上报告警产生或者告警恢复；

步骤S840，中断上报第一告警恢复43(即端口up)，将该寄存器上的告警状态更改为告警恢复；

步骤S850，由于限速定时器还没有到时，因此继续等待中断上报告警产生或者告警恢复；

步骤S860，中断上报第二告警产生44(即端口down告警)，将该寄存器上的告警状态更改为告警产生；

步骤S870，由于限速定时器还没有到时，因此继续等待中断上报告警产生或者告警恢复；

步骤S880，中断上报第二告警恢复45(及端口up)，将该寄存器上的告警状态更改为告警恢复；

步骤S890，限速定时器到时(一个限速周期结束)，寄存器上的状态为告警恢复，产生一恢复信号输出给网管设备。

以下继续以端口down告警这一实际应用为例进行具体的阐述，并请继续参考图5。如图9所示，本实际应用包括如下步骤：

步骤S910，网元设备启动后中断上报第一告警产生51(即端口down告警)时，开启一限速定时器用以记录限速周期；

步骤S920，产生一告警信号(即告警信号52)并输出给网管设备，在一寄存器上将告警状态设置为告警产生；

步骤S930，由于限速定时器没有到时，因此继续等待中断上报告警产生或者告警恢复；

步骤S940，中断上报第一告警恢复53(即端口up)，将该寄存器上的告警状态更改为告警恢复；

步骤S950，由于限速定时器还没有到时，因此继续等待中断上报告警产生或者告警恢复；

步骤S960，中断上报第二告警产生54(即端口down告警)，将该寄存器上的告警状态更改为告警产生；

步骤S970，限速定时器到时(一个限速周期结束)重置，继续计时(第二个限速周期开始)并等待中断上报告警产生或者告警恢复；其中，由于寄存器上的告警状态保持为告警产生，表示还有未处于恢复状态的告警产生存在，因此暂不向网管设备输出告警信号；

步骤S980，中断上报第二告警恢复55(及端口up)，将该寄存器上的告警状态更改为告警恢复；

步骤S990，限速定时器到时(第二个限速周期结束)，寄存器上的状告警态为告警恢复，由于寄存器上的告警状态由告警产生更改为告警恢复，且第二告警恢复55直至第二个限速周期结束，未在产生新的告警产生，因此产生一恢复信号输出给网管设备。

由上述内容可知，本发明是在限速周期的开始阶段输出告警信号(第一个告警产生之后才会开始对限速周期的计时)，并仅在同一个或者后续的限速周期结束时刻输出恢复信号，同一个限速周期或者若干个连续的限速周期内只会输出一条告警信号和一条恢复信号，而且用户可根据具体告警情况合理配置限速周期的大小。

本发明技术方案并没有对所有的告警都直接进行闪断告警的报告和处理，而是只对有可能产生闪断告警的告警进行报告并处理，大大减少了故障检测的处理时间和复杂性。另外，本发明的技术方案采用限速的方法来处理闪断告警，既限制了闪断告警的频率，又保证了用户能够了解网元设备产生闪断告警的故障性质。

本发明的技术方案把故障检测和告警输出分为两个任务，通过EB事件把二者联系起来，使得故障检测和告警输出更加灵活高效，便于其他任务进行告警处理。本发明技术方案中，采用三种告警输出方式进行告警输出，有效解决了告警消息的可靠性问题。

本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

虽然本发明所揭露的实施方式如上，但所述的内容只是为了便于理解本发明而采用的实施方式，并非用以限定本发明。任何本发明所属技术领域内的技术人员，在不脱离本发明所揭露的精神和范围的前提下，可以在实施的形式上及细节上作任何的修改与变化，但本发明的专利保护范围，仍须以所附的权利要求书所界定的范围为准。

Claims (14)

1.一种故障处理系统，其特征在于，包括任务检测模块、故障检测模块、事件代理(EB)事件处理模块、告警输出模块以及告警处理模块，其中：

所述任务检测模块，用于检测到网元设备上的任务处理出现故障时，产生EB消息；

所述故障检测模块，用于检测到所述网元设备上的系统运行出现故障时，产生EB消息；

所述EB事件处理模块，存储有各种EB消息的类型，用于接收所述任务检测模块发送的EB消息及所述故障检测模块发送的EB消息，将全部EB消息发送给所述告警输出模块，并根据所述告警处理模块的处理能力将部分EB消息发送给所述告警处理模块；

所述告警输出模块，用于将所述EB事件处理模块发送过来的EB消息转换为告警消息并发送；

所述告警处理模块，用于处理所述EB事件处理模块发送过来的EB消息。

2.根据权利要求1所述的系统，其特征在于：

所述任务检测模块及所述故障检测模块用于向所述EB事件处理模块注册能够发送的EB消息的类型；

所述告警输出模块及所述告警处理模块用于向所述EB事件处理模块注册能够接收的EB消息的类型。

3.根据权利要求1所述的系统，其特征在于：

所述告警输出模块用于以简单网络管理协议异常情况输出方式将所述告警消息发送给简单网络管理协议服务器，或者以系统日志输出方式将告警消息发送给系统日志服务器，或者以继电器输出方式将告警消息发送给继电器告警装置。

4.根据权利要求1所述的系统，其特征在于：

所述任务检测模块用于检测到所述任务处理出现故障时产生一个任务告警产生，故障恢复时产生一个相应的任务故障恢复；

其中，所述任务检测模块产生的EB消息，包括所述任务告警产生以及任务故障恢复。

5.根据权利要求4所述的系统，其特征在于：

所述告警输出模块用于在所述任务检测模块产生所述任务告警产生时输出一个任务告警信号，开始预设的限速周期的计时；并用于在所述任务检测模块产生所述任务告警恢复且直至所述任务告警恢复所属限速周期结束未再产生任务告警产生时，于所述任务告警恢复所属限速周期结束时产生一个任务恢复信号。

6.根据权利要求1所述的系统，其特征在于：

所述故障检测模块用于检测到所述系统运行出现故障时产生一个系统告警产生，故障恢复时产生一个相应的系统故障恢复；

其中，所述故障检测模块产生的EB消息，包括所述系统告警产生以及系统故障恢复。

7.根据权利要求6所述的系统，其特征在于：

所述告警输出模块用于在所述故障检测模块产生所述故障告警产生时输出一个故障告警信号，开始预设的限速周期的计时；并用于在所述故障检测模块产生所述故障告警恢复且直至所述故障告警恢复所属限速周期结束未再产生故障告警产生时，于所述故障告警恢复所属限速周期结束时产生一个故障恢复信号。

8.一种故障处理方法，用于故障处理系统处理故障告警，其特征在于，该故障处理系统包括任务检测模块、故障检测模块、事件代理(EB)事件处理模块、告警输出模块以及告警处理模块；

所述方法包括如下步骤：

所述任务检测模块检测到网元设备上的任务处理出现故障时，产生EB消息；

所述故障检测模块检测到所述网元设备上的系统运行出现故障时，产生EB消息；

所述EB事件处理模块接收所述任务检测模块发送的EB消息及所述故障检测模块发送的EB消息，将全部EB消息发送给所述告警输出模块，并根据所述告警处理模块的处理能力将部分EB消息发送给所述告警处理模块；

所述告警输出模块将所述EB事件处理模块发送过来的EB消息转换为告警消息并发送；

所述告警处理模块处理所述EB事件处理模块发送过来的EB消息。

9.根据权利要求8所述的方法，其特征在于：

所述任务检测模块及所述故障检测模块向所述EB事件处理模块注册能够发送的EB消息的类型；

所述告警输出模块及所述告警处理模块向所述EB事件处理模块注册能够接收的EB消息的类型。

10.根据权利要求8所述的方法，其特征在于：

所述告警输出模块以简单网络管理协议异常情况输出方式将所述告警消息发送给简单网络管理协议服务器，或者以系统日志输出方式将告警消息发送给系统日志服务器，或者以继电器输出方式将告警消息发送给继电器告警装置。

11.根据权利要求8所述的方法，其特征在于，

所述任务检测模块检测到所述任务处理出现故障时产生一个任务告警产生，故障恢复时产生一个相应的任务故障恢复；

其中，所述任务检测模块产生的EB消息，包括所述任务告警产生以及任务故障恢复。

12.根据权利要求11所述的方法，其特征在于：

所述告警输出模块在所述任务检测模块产生所述任务告警产生时输出一个任务告警信号，开始预设的限速周期的计时；并在所述任务检测模块产生所述任务告警恢复且直至所述任务告警恢复所属限速周期结束未再产生任务告警产生时，于所述任务告警恢复所属限速周期结束时产生一个任务恢复信号。

13.根据权利要求8所述的方法，其特征在于：

所述故障检测模块检测到所述系统运行出现故障时产生一个系统告警产生，故障恢复时产生一个相应的系统故障恢复；

其中，所述故障检测模块产生的EB消息，包括所述系统告警产生以及系统故障恢复。

14.根据权利要求13所述的方法，其特征在于：

所述告警输出模块在所述故障检测模块产生所述故障告警产生时输出一个故障告警信号，开始预设的限速周期的计时；并在所述故障检测模块产生所述故障告警恢复且直至所述故障告警恢复所属限速周期结束未再产生故障告警产生时，于所述故障告警恢复所属限速周期结束时产生一个故障恢复信号。

Images