CN101800675B - 故障监控方法、监控设备及通信系统 - Google Patents

Abstract

本发明实施例提供一种故障监控方法、监控设备及通信系统，其中，故障监控方法包括：获取通信单元上报的业务处理失败事件；所述业务处理失败事件包括：业务处理失败的对象实体的地址信息；根据通信单元上报的业务处理失败事件和预置的失效判别准则，确定发生异常的实体，发送用于指示进行故障检测的故障预警通知消息，所述故障预警通知消息包括：所确定的发生异常的实体中至少一个实体的信息。使用本发明实施例提供的技术方案，能够提高故障检测的效率。

Description

故障监控方法、监控设备及通信系统

技术领域

本发明涉及通信技术领域，特别涉及一种故障监控方法、监控设备及通信系统。

背景技术

通信网络设备要求有很高的可靠性，为了达到很高的可靠性，将产品寿命周期费用降至最低，设备开发商需要花费大量的时间和成本为整个通信设备进行详细的失效模式与影响分析(Failure Mode and Effects Analysis，FMEA)，以求尽量分析到通信设备所有故障模式，并提供有效的故障处理措施，确保通信设备出了故障后能尽快恢复正常，尽量减少通信设备业务影响。

由于目前通信设备越来越复杂，特别是软件规模越来越庞大，按照传统FMEA方式想要穷尽所有故障模式，成本非常大，所需要的时间也非常大，在目前激烈的商业竞争环境下，任何一个设备开发商都无法承受这种代价，所以现在绝大部份电信设备都会或多或少存在一些通信设备无法检测的故障。另外，有些故障检测手段由于非常耗费通信设备性能，一般设计在通信设备空闲时执行，这样导致这类故障不可能实时进行检测。

现有技术的缺点是：

对于上述两种故障(即通信设备无法检测的故障或无法实时检测的故障)，通信设备都无法及时检测到，也无法及时进行恢复。

发明内容

本发明实施例提供一种故障监控方法、监控设备及通信系统，能够提高故障检测的效率。

有鉴于此，本发明实施例提供：

一种故障监控方法，包括：

获取通信单元上报的业务处理失败事件；所述业务处理失败事件包括：业务处理失败的对象实体的地址信息；

根据通信单元上报的业务处理失败事件和预置的失效判别准则，确定发生异常的实体，发送用于指示进行故障检测的故障预警通知消息，所述故障预警通知消息包括：所确定的发生异常的实体中至少一个实体的信息。

一种监控设备，包括：

第一获取单元，用于获取通信单元上报的业务处理失败事件；所述业务处理失败事件包括：业务处理失败的对象实体的地址信息；

确定单元，用于根据通信单元上报的业务处理失败事件和预置的失效判别准则，确定发生异常的实体；

发送单元，用于发送故障预警通知消息，所述故障预警通知消息包括：所确定的发生异常的实体中至少一个实体的信息，所述故障预警通知消息用于指示进行故障检测。

一种通信系统，包括：通信单元，子监控单元，和父监控单元，其中，

子监控单元，用于获取通信单元上报的业务处理失败事件，根据业务处理失败事件中携带的业务处理失败的对象实体的地址信息，确定所述业务处理失败的对象实体不属于自己管理的范围，将该业务处理失败事件上报给父监控单元；

父监控单元，用于接收子监控单元上报的业务处理失败事件，根据业务处理失败事件中携带的业务处理失败的对象实体的地址信息，确定所述业务处理失败的对象实体是否属于自己管理的范围，如果是，根据所述业务处理失败事件和预置的失效判别准则，确定发生异常的实体，发送用于指示进行故障检测的故障预警通知消息，所述故障预警通知消息包括：所确定的发生异常的实体中至少一个实体的信息；如果否，继续将所述业务处理失败事件上报给所述父监控单元的父监控单元。

一种通信系统，包括：第一通信单元、第二通信单元和监控单元，

监控单元，用于获取第一通信单元上报的业务处理失败事件，获取第二通信单元上报的业务处理失败事件，当第一通信单元上报的业务处理失败事件携带的业务处理失败的对象实体的地址信息为第二通信单元的地址信息，且第二通信单元上报的业务处理失败事件携带的业务处理失败的对象实体的地址信息为第一通信单元的地址信息时，不对第一通信单元和第二通信单元进行失效分析。

本发明实施例通过分析通信单元上报的业务处理失败事件确定发生异常的实体，并发送相应的故障预警通知消息，以便系统采取相应的故障处理，针对发生异常的实体能及时进行故障恢复，将故障修复在萌芽状态，避免了故障扩散，提高系统可靠性。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的一种故障监控方法流程图；

图2是本发明实施例提供的一种故障监控及处理方法流程图；

图3是本发明实施例提供的另一种故障监控及处理方法示意图；

图4是本发明实施例提供的又一种故障监控及处理方法示意图；

图5是本发明实施例提供的又一种故障监控及处理方法示意图；

图6是本发明实施例提供的监控设备结构图；

图7是本发明实施例提供的一种通信系统结构图；

图8是本发明实施例提供的另一种通信系统结构图。

具体实施方式

参阅图1，本发明一实施例提供一种故障监控方法，其包括：

101、获取通信单元上报的业务处理失败事件，所述业务处理失败事件包括：业务处理失败的对象实体的地址信息。

对通信系统而言，各种通信业务的完成实质上是由通信系统中各通信单元通过消息或业务码流交互协同处理完成的。该通信单元可以是通信系统中的某个网元，也可以是网元内某个处理单元，如：机框，单板，芯片，处理器，I/O设备等硬件实体；也可以是运行在芯片或处理器上的软件实体，如：软件模块，进程，线程等软件实体；还可以是部署在系统程序中的逻辑资源实体，如：内存资源，信号量，业务处理资源，带宽资源，链路资源等逻辑资源实体。

其中，可以通过如下方式获取通信单元上报的业务处理失败事件：第一种方式：直接接收通信单元上报的业务处理失败事件；第二种方式，父监控单元接收子监控单元发送的业务处理失败事件。其中，第二种方式适用于分布式的失效分析处理模式，分布式的失效分析处理模式包括但不限于：单板级失效分析，框级失效分析，网元级失效分析和网络级失效分析。不同层次的监控单元(即进行失效分析的单元)逻辑上可以部署在一起，也可以部署在不同硬件上。为了提高处理效率，一般采取分散部署在不同硬件上。一般地，单板级失效分析包括单板内硬件芯片或单板内所运行的软件模块的失效分析，直接就近部署在本单板上。框级失效分析不仅包括单板级失效分析内容，还包括单板级失效分析无法处理的内容，部署在框的中心控制单板上。网元级失效分析部署在网元的中心控制单板上。网络级失效分析部署在网络的中心控制节点上，如中心网管设备。因此，父监控单元是网络级监控单元，其位于中心网管设备上，子监控单元是网元级监控单元，其位于网元的中心控制单板上；或者，父监控单元是网元级监控单元，其位于网元的中心控制单板上，子监控单元是框级监控单元，其位于框的中心控制单板上；或者，父监控单元是框级监控单元，其位于框的中心控制单板上，子监控单元是单板级监控单元，其位于通信单元所在的单板上。

一般地，若一个层次的失效分析能做出明确失效判决，则所述通信单元的业务处理失败事件将在本层次的失效分析被终结，不再上报给上一层；若无法做出明确失效判决，则本层次失效分析需要将所述通信单元的业务处理失败事件继续上报给上一层的失效分析。比如：A单板接收到B单板发送的响应消息中某些字段赋值错误，A单板会向自己所在的单板级监控单元上报B单板的业务处理失败事件，该事件中携带B单板的地址信息；由于A单板所在的单板级监控单元无法有效分析其他单板的失效，则需要将此业务处理失败事件继续上报给A单板所属的框级监控单元进行分析。同样，若A单板与B单板位于不同的框上，则A单板所属的框级监控单元仍无法有效分析，则需要继续上报给A单板所属的网元级监控单元进行分析，若A单板与B单板位于不同的网元上，A单板所属的网元级监控单元仍无法有效分析，则需要继续上报给网络级监控单元进行分析。

其中，业务处理失败的对象实体是所述通信单元或者为与所述通信单元通信的对端通信单元；业务处理失败事件可以是信令消息处理失败事件、管理消息处理失败事件，业务码流处理失败事件，或者接口调用处理失败事件。

具体的，通信单元执行信令消息相应的功能失败时上报信令消息处理失败事件；或者，通信单元执行管理消息相应的功能失败时上报管理消息处理失败事件；或者，通信单元处理业务码流失败时上报业务码流处理失败事件；或者，通信单元接口调用处理失败时上报接口调用处理失败事件。

对于接收的消息正常，而在内部处理时失败，所述业务处理失败的对象实体的地址信息为本消息处理通信单元的地址信息。

对于接收的消息内部包含异常信元而导致失败的，所述业务处理失败的对象实体的地址信息为消息发送通信单元的地址信息。

对于发送的消息正常，而超时未接收到对端通信单元的响应消息而导致失败的，所述业务处理失败的对象实体的地址信息为消息接收通信单元(即对端通信单元)的地址信息。

接口调用处理失败，表示接口设备可能故障，所述业务处理失败的对象实体的地址信息为接口设备通信单元的地址信息。如读写硬盘时的接口调用处理失败，表示硬盘可能故障。

业务处理失败事件还可以包括：业务处理失败的原因指示信息。还可以包括：业务处理时一些上下文关键运行参数，如当前负荷量，总业务处理次数等。

特别地，当通信单元在当前负荷量超过预设阈值时，可以不上报该业务处理失败事件，避免后续进行不必要的失效分析。

特别地，当通信单元确定来自对端通信单元的信令消息中字段赋值异常是由于接入的终端设备(包括用户终端和操作维护终端)是非法的，可以不上报业务处理失败事件，或者上报业务处理失败事件，但在事件携带特定字段进行标识。对于这种情况，也可以在通信单元处进行控制，即控制通信单元不上报该业务处理失败事件。比如，归属位置寄存器(Home LocationRegister，HLR)设备中的某个通信单元接收到呼叫请求消息后，发现该呼叫请求消息中携带的终端的国际移动用户识别码(international mobile subscriberidentity，IMSI)、电子序列号(Electronic Serial Number，ESN)不合法，可以不上报业务处理失败事件，避免后续进行不必要的失效分析。

其中，业务处理失败的对象实体的地址信息包括对象实体所属硬件的物理地址信息，用以唯一标识通信单元所属硬件在整个通信系统中的详细地址信息；如果通信单元是网元内的某个处理单元，如：机框，单板，芯片，处理器，I/O设备等，则对象实体所属硬件的物理地址信息可以是信令点标识或IP地址，或者是按照[机框号，单板槽位号，子系统号]形式表示的物理地址。

若业务处理失败的对象实体为软件实体，所述的业务处理失败的对象实体的地址信息还可以包括此软件实体的逻辑地址信息，此逻辑地址信息可以是软件模块地址或进程地址，或与软件模块地址或进程地址一一对应的软件模块编号或进程编号。

其中，业务处理失败的原因指示信息可以指示因哪种资源申请失败而导致业务处理失败，其中，上述资源可以是内存资源，信号量，业务处理资源，带宽资源，链路资源等，在系统中，业务处理失败的原因指示信息可以为一个具体编号，其与申请失败的资源相对应。一般地，建议编号与资源保持一一对应关系，这样在系统内，只要是因为同一种资源申请失败导致的业务处理失败，该业务处理失败的原因指示信息是相同的，这有利于系统中资源的失效分析处理。

一般地，对象实体在业务处理成功时通信单元不需要上报任何事件，但在上报过业务处理失败事件后，在对象实体再次执行业务处理成功时，通信单元要上报业务处理成功事件给监控单元。另外，通信单元是否上报业务处理成功事件也可以由监控单元来控制，例如：监控单元在收到通信单元上报的业务处理失败事件后，回消息给通信单元，通知通信单元在对象实体的业务处理成功时上报业务处理成功事件。

其中，通信单元可以使用同一个接口上报业务处理成功事件和业务处理失败事件，在业务处理失败事件中携带业务处理失败的原因指示信息，在业务处理成功事件中携带业务处理成功指示信息，比如业务处理成功事件中携带特定标识表示业务处理成功。

102、根据通信单元上报的业务处理失败事件和预置的失效判别准则，确定发生异常的实体。

具体的，可以利用通信单元上报的业务处理失败事件，针对一个或者多个分析对象统计失效指标值；根据所统计的失效指标值和失效判别准则中相应的失效阈值，确定相应分析对象是否异常。

对象实体的业务处理失败，必然会造成其相关功能失败或受损，在对外表现上，就是某个实体异常。其中，失效判别准则规定了失效阈值和分析对象。失效判别准则可以规定分析对象为业务处理失败的对象实体所属硬件的物理地址对应的硬件实体，或者，分析对象为业务处理失败的对象实体所属硬件的物理地址及逻辑地址两者所对应的软件实体，或者，分析对象为业务处理失败的对象实体所属硬件的物理地址及业务处理失败的原因指示信息两者所对应的逻辑资源实体。

一般地，失效指标值可以是连续业务处理失败次数的累加值，也可以是一段时间内的业务处理失败次数占总业务处理次数的比值，也可以是系统统计的关键业绩指标(Key Performance Indicators，KPI)，比如呼损率，掉话率等统计指标值。具体选取哪些失效指标值依赖于所制定的失效判别准则。若失效指标值为连续业务处理失败次数的累加值时，监控单元接收到通信单元上报的业务处理失败事件时，依据不同的分析对象，将分析对象所对应的失效指标值分别加一。若失效指标值为一段时间内的业务处理失败次数占总业务处理次数的比值时，则依据不同的分析对象，将分析对象所对应的业务处理失败次数加一，然后求当前业务失败次数与总业务处理次数的比值。在接收到通信单元上报的业务处理成功事件时，则将各分析对象对应的失效指标值清零。

若失效指标值为关键业绩指标时，通信单元上报的业务处理失败事件触发监控单元查询关键业绩指标，将关键业绩指标与预设的阈值进行比较。

一般地，失效判别准则可以采用阈值比较法，具体的，在监控单元上预先设置失效阈值，当失效指标值大于所设置的失效阈值时，则可判定业务处理失败的对象实体发生异常。特别地，以连续业务处理失败的次数超过一定阈值作为失效判别准则，则当连续业务处理失败次数的失效指标值超过失效判别准则中的失效阈值时，即可判定业务处理失败的对象实体发生异常。

参照步骤101所述，假设业务处理失败事件携带三个参数：业务处理失败的对象实体所属硬件的物理地址信息，业务处理失败的对象实体的逻辑地址信息，业务处理失败的原因指示信息，则监控单元在接收到通信单元上报的业务处理失败事件时，失效分析可以以一个或多个分析对象分别进行分析：

若以业务处理失败的对象实体所属硬件的物理地址所对应的硬件实体作为分析对象，若该分析对象对应的失效指标值超过第一失效阈值，则表示该硬件实体连续执行业务处理失败次数超过第一失效阈值，确定该硬件实体发生异常。

若以业务处理失败的对象实体所属硬件的物理地址和该对象实体的逻辑地址两者所对应的软件实体作为分析对象，若该分析对象对应的失效指标值超过第二失效阈值，则表示该软件实体连续执行业务处理失败次数超过第二失效阈值，确定此软件实体发生异常。

若以业务处理失败的对象实体所属硬件的物理地址和业务处理失败的原因指示信息两者所对应的逻辑资源实体作为分析对象，若该分析对象对应的失效指标值超过第三失效阈值，则表示系统连续调用该逻辑资源实体而导致的业务处理失败的次数超过第三失效阈值，确定此逻辑资源实体发生异常。

其中，监控单元将当前失效分析结果分别进行保存，以备后续调用。

特别地，如果业务处理失败事件中携带当前负荷量，且当前负荷量超过预设阈值时，则监控单元可以结合整个系统的运行负荷情况，决策是否将该业务处理失败事件丢弃，当决策将该业务处理失败事件丢弃时，即在这种情况下，不将分析对象对应的失效指标值进行加一处理。

特别地，如果业务处理失败事件中携带特定标识，该特定标识表示接入的终端设备(包括用户终端和操作维护终端)是非法的，则监控单元将该业务处理失败事件丢弃，或仅记录日志，即在这种情况下，不将分析对象对应的失效指标值进行加一处理。

103、发送故障预警通知消息，该消息包括：所确定的发生异常的实体中至少一个实体的信息。

如果仅以步骤102中的硬件实体为分析对象进行失效分析，当失效分析结果表示该硬件实体发生异常时，发送故障预警通知消息，该故障预警通知消息包括：业务处理失败的对象实体所属硬件的物理地址信息。

如果仅以步骤102中的软件实体为分析对象进行失效分析，当失效分析结果表示该软件实体发生异常时，发送故障预警通知消息，该故障预警通知消息包括：业务处理失败的对象实体所属硬件的物理地址信息和该对象实体的逻辑地址信息。

如果仅以步骤102中的逻辑资源实体为分析对象进行失效分析，当失效分析结果表示该逻辑资源实体发生异常时，发送故障预警通知消息，该故障预警通知消息包括：业务处理失败的对象实体所属硬件的物理地址和失败原因指示信息。

如果同时以步骤102中的硬件实体、软件实体、逻辑资源实体作为失效分析对象分别进行失效分析，且有多个分析对象都发生失效，则可以同时上报多个故障预警通知消息，也可以只上报一个故障预警通知消息，也可以逐个上报故障预警通知消息。比如：在确定硬件实体和软件实体都异常时，可以先上报软件实体对应的故障预警通知消息，暂不上报硬件实体对应的故障预警通知消息。在确定硬件实体和逻辑资源实体都异常时，可以先上报逻辑资源实体对应的故障预警通知消息，暂不上报硬件实体对应的故障预警通知消息；优选的，当同时存在多个分析对象发生异常时，先发起最小粒度的失效分析对象所对应的故障预警通知消息，这样可以先进行最精确的故障预警。特别的，如果后续分析发现系统仍然故障，再上报硬件实体对应的故障预警通知消息。特别的，对于硬件实体的故障预警通知消息，也可以区分不同粒度大小的硬件实体，其中，对象实体所属硬件的物理地址信息包括：第一级子地址；所述对象实体所属硬件是第一级子地址对应的硬件的组件；监控单元在发送包括对象实体所属硬件的物理地址信息的故障预警通知消息后，若预设时间段内确定所述对象实体所属硬件一直异常，则发送包括第一级子地址的故障预警通知消息。可选的，第一级子地址包括：第二级子地址，所述第一级子地址对应的硬件为第二级子地址对应的硬件的组件；监控单元在发送包括第一级子地址的故障预警通知消息之后的预设时间段内，若确定对象实体所属硬件还是一直异常，则发送包括第二级子地址的故障预警通知消息。比如：按照[机框号，单板槽位号，子系统号]形式的物理地址表示的硬件实体发生异常，可以先发送[机框号，单板槽位号，子系统号]所对应的硬件实体(子系统)的故障预警通知消息；然后可以发送[机框号，单板槽位号]所对应的硬件实体(单板)的故障预警通知消息；最后可以发送[机框号]所对应的硬件实体(机框)的故障预警通知消息。具体的，在逐次发送不同粒度的失效分析对象所对应的故障预警通知消息时，在上报了一个故障预警通知消息之后可以通过预设一个等待时间，在等待时间超时后，重新检查当前失效分析结果，若当前失效分析结果表明所述失效分析对象仍旧异常，则再上报下一个故障预警通知消息。其中，[机框号，单板槽位号，子系统号]为对象实体所属硬件的物理地址信息，[机框号，单板槽位号]为第一级子地址，[机框号]为第二级子地址。

其中，故障预警通知消息可以是发给发生异常的实体自身，也可以是发给发生异常的实体的管理模块。比如：对于机框对应的故障预警通知消息，发给该机框的管理模块；对于单板对应的故障预警通知消息，发给该单板的管理模块；对于DSP芯片子系统对应的故障预警通知消息，发给该DSP芯片子系统的管理模块；对于内存资源对应的故障预警通知消息，发给该内存资源的管理模块；对于软件模块对应的故障预警通知消息，可以发给该软件模块自身，也可以发给该软件模块的管理模块。优选的，故障预警通知消息发给发生异常实体的管理模块。

发生异常的实体或者发生异常的实体的管理模块在接收到故障预警通知消息后，将对发生异常的实体进行故障检测和故障恢复流程。详见后续实施例相应部分的描述。

特别地，监控单元在针对一个分析对象发送故障预警通知消息后，可以启动一个定时器，在定时器超时前，后续针对该分析对象的失效分析不再发送故障预警通知消息。

本发明实施例中通信单元在对象实体业务处理失败时及时上报业务处理失败事件，监控单元进行失效分析确定具体的发生异常的实体，并发送故障预警通知消息，及时触发对该发生异常的实体的故障检测流程和故障恢复流程，不仅可以使发生异常的实体能够及时被自动修复，将故障修复在萌芽状态，保障了系统长期地，稳定地正常运行，有效避免了故障扩散，提高系统可靠性。另外，故障检测流程是在分析发现系统失效后才触发，并且可以是只针对发生异常的实体触发，所以不仅可以保证故障检测产生的故障告警与系统失效表现的一致性，而且能有效抑制无关的告警上报。本实施例提供的技术方案可以将系统中所有业务处理失败进行监控，包括信令消息处理失败，管理消息处理失败，和业务码流的处理失败，可以覆盖系统所有业务处理失败，可以保证系统能检测到所有通信单元的失效，保证了检测的完备性，这样即使某些通信单元在系统中没有设计相关的故障检测技术，也能通过本发明所描述的方案基本确定通信单元的失效，进而采取针对性的故障恢复措施，使发生异常的通信单元能够及时被自动修复或隔离，系统恢复正常。

参阅图2，本发明另一实施例提供一种通信单元出现连续执行信令消息失败时的故障监控方法，其包括：

201、通信单元执行信令消息失败，上报信令消息处理失败事件，事件中包括：该通信单元所属单板的物理地址信息。

所述信令消息可以是信令面的任何正常消息。所述的通信单元执行信令消息失败可以是通信单元在消息处理时碰到的各种异常原因导致的失败，比如申请内存资源失败，申请定时器失败，查询配置失败，或查询到的配置数据异常等各种原因导致的处理失败。

202、监控单元获取通信单元上报的信令消息处理失败事件。

203、监控单元根据通信单元上报的信令消息处理失败事件和预置的失效判别准则，确定所述通信单元所属的单板发生异常。

根据信令消息处理失败事件中包括的信息：该通信单元所属单板的物理地址信息，针对该单板进行连续业务处理失败次数的累加统计，监控单元每接收到通信单元上报一次信令消息处理失败事件，则将该单板所对应的连续业务处理失败次数加一。当该单板所对应的连续业务处理失败次数大于系统所设置的失效阈值时，监控单元判定该单板发生异常。

204、监控单元发送故障预警通知消息给所述单板，该消息包括：所述单板的物理地址信息。

监控单元在发送故障预警通知消息后，启动一个定时器，在定时器超时前，后续针对该单板的失效分析将不再发送故障预警通知消息，这样做主要是防止后续监控单元进行重复频繁的故障预警通知消息。

205、所述单板在接收到故障预警通知消息之后，触发故障检测流程。

所述单板在收到故障预警通知消息，则触发此单板的故障检测流程，对单板进行全面的故障检测，以最终确定单板的故障点和故障原因。一般地，在检测到具体的故障点和故障原因时，上报相应的故障告警信息，提示设备的运维人员。比如：故障检测流程包含单板的内存芯片失效检测，运行内存芯片失效检测发现内存芯片失效，则可以上报内存芯片失效的故障告警信息。

206、所述单板在执行完所述故障检测流程后，根据故障检测结果，进行故障失效确认流程。

如果所述单板故障检测结果表示没有检测到任何故障，则向监控单元发送故障失效查询消息，监控单元返回响应消息，响应消息中包括当前最新的失效分析结果。如果当前最新的失效分析结果表示所述单板仍然失效，则执行下一步；如果当前最新的失效分析结果表示所述单板已经正常，则整个流程结束。

若故障检测结果中表示所述单板确实存在故障，则可以不进行故障失效确认，直接执行下一步。

207、所述单板触发故障恢复流程。

若所述单板的故障恢复流程为单板复位，则执行该单板复位流程。若所述单板的故障恢复流程为主备倒换，则执行该主备倒换流程。若所述单板的故障恢复流程为单板隔离，则执行该单板隔离流程。

特别的，所述单板的故障恢复流程可以配置为多个故障恢复措施的组合，比如：可以配置所述单板的故障恢复流程为首先执行主备倒换，再执行单板复位，最后执行单板隔离。在执行完一个故障恢复措施后，重新执行步骤205～206，重新进行故障检测和故障失效确认流程，若故障检测结果或当前最新的失效分析结果表示所述单板仍然故障或失效，则继续执行下一个故障恢复措施，否则表示所述单板已经正常，流程结束。

本发明实施例中在通信单元连续执行信令消息处理失败时，及时上报信令消息处理失败事件，监控单元进行失效分析确定通信单元所属的单板发生异常时，向该单板发送故障预警通知消息，及时触发对该单板的故障检测流程和故障恢复流程，可以使该单板能够及时被自动修复或隔离，将故障修复在萌芽状态，保障了系统长期地，稳定地正常运行，有效避免了故障扩散，提高系统可靠性。另外，由于故障检测流程只是在分析发现单板发生异常之后才触发，相比于原来定时故障检测触发机制，不仅保证了及时性，而且对系统性能影响最小。

参阅图3，如下举具体实例对本发明实施例提供的技术方案进行详细描述。本发明实施例假定所在框号为3，单板槽位号为3，子系统号为1的DSP芯片发生连续业务处理失败，并假定所述DSP芯片运行的软件模块为单进程。

301、DSP芯片进行业务处理失败，向DSP芯片的监控单元上报业务处理失败事件，该事件包括：DSP芯片的物理地址(DSP芯片所在的框号为3、单板槽位号为1和子系统号为1)，和业务处理失败的原因指示信息。

由于DSP芯片运行软件模块为单进程，不用进行区分，所以这里的业务处理失败的软件模块的逻辑地址可以不用携带。

其中，该业务处理失败事件可以是该DSP的信令消息处理失败事件、或该DSP的管理消息处理失败事件或者该DSP的业务码流处理失败事件。

其中，业务处理失败的原因指示信息可以指示因哪种资源申请失败而导致业务处理失败，其中，上述资源可以是DSP芯片的内存资源，DSP芯片的定时器资源，DSP芯片的业务通道处理资源等，在系统中，所述业务处理失败的原因指示信息一般为一个具体编号，其与申请失败的资源一一对应。

302、监控单元获取到DSP芯片上报的业务处理失败事件。

监控单元获取到DSP芯片上报的业务处理失败事件后，解析出事件中携带的信息，包括：DSP芯片的物理地址(DSP芯片所在的框号为3、单板槽位号为1和子系统号为1)，和业务处理失败的原因指示信息。

303、监控单元根据DSP芯片上报的业务处理失败事件和预置的失效判别准则，判断DSP芯片是否异常。

这里预置的失效判别准则为：DSP芯片连续业务处理失败的次数是否超过配置的失效阈值(假设系统配置的失效阈值为5次)，则若超过5次，则监控单元将判定DSP芯片发生异常，否则，表示DSP芯片还未达到失效判别准则，监控单元将判定DSP芯片正常。

根据预置的失效判别准则，监控单元需要根据DSP芯片上报的业务处理失败事件统计DSP芯片的连续业务处理失败的次数。监控单元每接收到一次DSP芯片上报的业务处理失败事件，则以事件中所携带的DSP芯片的物理地址所对应的物理实体为分析对象，对此物理实体的连续业务处理失败次数进行加一处理，这里对框号为3、单板槽位号为1和子系统号为1的DSP芯片的连续业务处理失败次数进行加一处理，然后判断DSP芯片连续业务处理失败的次数是否超过配置的失效阈值。例如：DSP芯片连续进行5次业务处理均失败，则会连续向监控单元上报5次业务处理失败事件，监控单元在前4次获取到DSP芯片上报的业务处理失败事件时，进行失效分析，由于还未达到失效阈值5次，前4次失效分析结果都为DSP芯片正常，在第5次获取到DSP芯片上报的业务处理失败事件时，进行失效分析，发现DSP芯片连续业务处理失败的次数已经达到失效阈值5次，则失效分析结果输出DSP芯片异常。如果5次业务处理失败的原因指示信息都是一样，假设都指向DSP芯片的内存资源，则以DSP芯片的内存资源作为分析对象，其失效分析结果也同样会输出DSP芯片的内存资源发生异常的结果。

需要说明的是，如果监控单元接收到DSP上报的业务处理失败事件后，首次接收到DSP上报的业务处理成功事件，则将已统计的业务处理失败次数清零。假如：DSP芯片连续进行3次业务处理失败，但第4次业务处理成功，则会上报一个业务处理成功事件，监控单元会将统计的DSP芯片的连续业务处理失败的次数由3改为0。

监控单元会保存失效分析的结果(即DSP芯片异常或者正常)作为当前最新的失效分析结果。

304、监控单元当确定DSP芯片发生异常时，向DSP芯片管理单元发送故障预警通知消息。

该故障预警通知消息包括：发生异常的DSP芯片的地址信息(这里DSP芯片地址信息为框号为3、单板槽位号为1和子系统号为1)。

监控单元在发送故障预警通知消息后，启动一个定时器，在定时器超时前，后续的失效分析将不再发送故障预警通知消息，这样做主要是防止后续监控单元进行重复频繁的故障预警通知消息。

305、DSP芯片管理单元调用DSP故障检测处理程序，进行故障检测。

在DSP芯片管理单元中可以注册DSP故障检测处理函数，调用此函数则触发DSP故障检测处理流程。比如：向发生异常的DSP芯片发消息，触发DSP芯片进行程序段和数据段的CRC数据校验，并将CRC数据校验结果返回给DSP芯片管理单元。DSP故障检测处理流程在发现具体故障原因时会上报相应的告警和记录日志，以方便用户问题定位。

306、DSP芯片管理单元根据DSP故障检测结果，与监控单元进行故障失效确认。

如果DSP故障检测结果表示没有检测到任何故障，则向监控单元发送故障失效查询消息，监控单元返回响应消息，响应消息中包括当前最新的失效分析结果。

如果DSP故障检测结果表示检测到故障，也可以向监控单元发送故障失效查询消息，也可以不向监控单元发送故障失效查询消息进行故障失效确认。优选地，由于已经检测到故障，一般不向监控单元发送故障失效查询消息，以提高系统处理效率。

特别地，如果DSP故障测检结果表示检测到故障，或与监控单元进行故障失效确认得到的当前最新的失效分析结果表示DSP发生异常，则继续执行下一步。如果DSP故障检测结果表示没有检测到任何故障，且与监控单元进行故障失效确认得到的当前最新的失效分析结果也表示DSP芯片正常，表示DSP芯片已经恢复正常，可以结束整个流程。这样可以避免一些闪断类型故障造成后续不必要的故障恢复措施对系统的影响。

307、DSP芯片管理单元调用DSP故障恢复处理程序，进行故障恢复。

在DSP芯片管理单元中可以注册DSP故障恢复处理函数，调用此函数则触发DSP故障恢复处理流程。比如：向发生异常的DSP芯片发复位消息，触发DSP芯片进行复位重启，并可以启动一个定时器，等待DSP芯片重新运行正常。

DSP芯片管理单元在执行完DSP故障恢复处理程序后，可以再次对该DSP芯片进行故障检测，并与监控单元进行故障失效确认。如果DSP故障测检结果表示检测到故障，或与监控单元进行故障失效确认得到的当前最新的失效分析结果表示DSP仍旧异常，则执行DSP芯片隔离措施，将该异常的DSP芯片进行隔离。

本发明实施例通过在DSP芯片业务处理失败时，向监控单元上报的业务处理失败事件，由监控单元根据业务处理失败事件进行失效分析，及时确定DSP芯片发生异常，并在DSP芯片发生异常时向DSP芯片管理单元发送故障预警通知消息，由DSP芯片管理单元及时调用DSP芯片故障检测流程和故障恢复流程，不仅可以及时检测DSP芯片的具体故障原因，上报表示故障根本原因的告警，而且能及时对DSP芯片进行故障修复或隔离，将故障修复在萌芽状态，快速恢复或隔离发生异常的DSP芯片，避免了故障扩散，提高系统可靠性。另外，由于故障检测流程是在收到故障预警通知消息后才触发，相比于原来定时触发机制，不仅保证了及时性，而且对系统性能影响最小，甚至可以关闭原来的定时触发的DSP芯片故障检测机制。由于本发明实施例可以将DSP芯片的所有业务处理失败都进行监控，包括信令消息业务处理失败，管理消息业务处理失败，和业务码流的处理处理失败，可以覆盖DSP芯片的所有业务处理失败，可以保证DSP芯片的失效检测的完备性，这样即使DSP芯片遗漏设计了一些故障模式的故障检测技术，也能通过本发明所描述的方案，通过对DSP芯片对外表现，基本确定DSP芯片的失效，进而采取DSP芯片故障恢复措施，使发生异常的DSP芯片能够及时被自动修复或隔离，恢复正常。

参阅图4，本发明实施例提供一种故障监控及处理方法，本实施例假定第一通信单元向第二通信单元发送消息，由于超时未收到第二通信单元的响应消息而导致业务处理失败。对此种情况的失效处理流程如下：

401、第一通信单元向第二通信单元发送消息，由于超时未收到第二通信单元的响应消息而导致业务处理失败，向第一通信单元的本层监控单元上报业务处理失败事件，该业务处理失败事件包括：业务处理失败的对象实体(第二通信单元)的地址信息。

402、上级监控单元获取第一通信单元上报的业务处理失败事件。

由于第二通信单元可能不在第一通信单元的监控单元监控范围内，那么第一通信单元的监控单元无法有效的对第二通信单元进行失效分析，则需要上报给更上一级的监控单元，最终由能监控第一通信单元和第二通信单元的监控单元接收该第一通信单元上报的业务处理失败事件。

监控单元可以包括：单板级监控单元，框级监控单元，网元级监控单元和网络级监控单元。不同层次的监控单元(即进行失效分析的单元)可以处理的失效分析范围是有区别的。一般地，单板级监控单元只能对单板内硬件芯片或单板内所运行的软件模块进行失效分析。框级监控单元不仅包括框内各单板级失效分析内容，还包括框级各单板间的失效分析内容。网元级监控单元可以分析网元内所有硬件芯片或软件模块进行失效分析。网络级监控单元可以分析整个网络中所有硬件芯片或软件模块进行失效分析。

403、上级监控单元根据第一通信单元上报的业务处理失败事件和预置的失效判别准则，判断第二通信单元是否异常。

如果确实是第二通信单元故障，则所有通信单元只要给第二通信单元发送消息，都会发生因超时未响应的业务处理失败，这些业务处理失败事件都会向上级监控单元发送。该上级监控单元确定多个通信单元发送的业务处理失败事件所指向的对象实体都是第二通信单元，且针对该对象实体所统计的业务处理连续失败的次数超过了配置的失效阈值，则上级监控单元将判定第二通信单元发生异常。

404、监控单元向第二通信单元的管理单元发送故障预警通知消息，该故障预警通知消息携带第二通信单元的地址信息。

后续故障检测与故障恢复的处理步骤与步骤205-207基本相同，在此不再赘述。

本发明实施例中若多个通信单元发送的业务处理失败事件所指向的对象实体是同一对象实体，且针对该对象实体所统计的业务处理连续失败的次数超过了配置的失效阈值时，确定该对象实体故障，发送故障预警通知消息，及时触发对该对象实体的故障检测流程和故障恢复流程，可以使该对象实体能够及时被自动修复或隔离，将故障修复在萌芽状态，保障了系统长期地，稳定地正常运行，有效避免了故障扩散，提高系统可靠性。

参阅图5，本发明实施例提供一种故障监控及处理方法，本实施例假定第一通信单元向第二通信单元发送消息，由于超时未收到第二通信单元的响应消息而导致业务处理失败；同时，第二通信单元也向第一通信单元发送消息，由于超时未收到第一通信单元的响应消息而导致业务处理失败。在这种情况下，第一通信单元会向上报业务处理失败事件，第二通信单元会向上报业务处理失败事件，两个业务处理失败的对象实体分别指向对端通信单元，分别为第二通信单元和第一通信单元，但实际上反映的是第一通信单元到第二通信单元之间的通信路径的失效，在这个通信路径上还可能包含其它用于交换的第三通信单元，第三通信单元的失效同样会造成此类问题，所以对这类问题的失效分析需要在覆盖整个路径所有通信单元的监控单元进行。对此种情况的失效处理流程如下：

501、第一通信单元向第二通信单元发送消息，由于超时未收到第二通信单元的响应消息而导致业务处理失败，向第一通信单元的本层监控单元上报针对第二通信单元的业务处理失败事件，该业务处理失败事件包括：业务处理失败的对象实体(第二通信单元)的地址信息。第二通信单元向第一通信单元发送消息，由于超时未收到第一通信单元的响应消息而导致业务处理失败，向第二通信单元的本层监控单元上报针对第一通信单元的业务处理失败事件，该业务处理失败事件包括：业务处理失败的对象实体(第一通信单元)的地址信息。

502、上级监控单元获取第一通信单元上报的针对第二通信单元的业务处理失败事件和第二通信单元上报的针对第一通信单元的业务处理失败事件。

由于第二通信单元可能不在第一通信单元的监控单元监控范围内，那么第一通信单元的监控单元无法有效的对第二通信单元进行失效分析，则第一通信单元上报的针对第二通信单元的业务处理失败事件需要上报给更上一级的监控单元。同理，第二通信单元上报的针对第一通信单元的业务处理失败事件也需要上报给更上一级的监控单元。最终由能监控第一通信单元和第二通信单元的监控单元接收该第一通信单元上报的业务处理失败事件和第二通信单元上报的业务处理失败事件。

503、上级监控单元根据第一通信单元上报的业务处理失败事件、第二通信单元上报的业务处理失败事件和预置的失效判决准则，不对第一通信单元和第二通信单元进行失效分析，对第一通信单元和第二通信单元之间路径上的第三通信单元进行失效分析。

其中，预置的失效判决准则规定彼此通信的两个通信单元上报的业务处理失败事件所指向的对象实体均为对端通信单元时，不对这两个通信单元进行失效分析。

进一步，如果系统配置有第一通信单元与第二通信单元之间路径上包含第三通信单元，预置的失效判决准则规定彼此通信的两个通信单元上报的业务处理失败事件所指向的对象实体均为对端通信单元时，对这两个通信单元之间路径上的通信单元进行失效分析。则在此情况下，可以针对第一通信单元和第二通信单元之间路径上的第三通信单元进行失效分析。比如：该上级监控单元确定多个通信单元(包括第一通信单元和第二通信单元)发送的业务处理失败事件所指向的对象实体都是第三通信单元，且针对该第三通信单元所统计的业务处理连续失败的次数超过了配置的失效阈值，则该上级监控单元将判定第三通信单元发生异常。

504、监控单元向第三通信单元的管理单元发送故障预警通知消息，该故障预警通知消息携带第三通信单元的地址信息。

后续故障检测与故障恢复的处理步骤与步骤205-207基本相同，在此不再赘述。

本发明实施例在彼此进行通信的两个通信单元(如上述第一通信单元和第二通信单元)都上报对方业务处理失败事件时，根据预置的失效判别准则不对这两个通信单元进行失效分析，对第一通信单元和第二通信单元之间路径上的第三通信单元进行失效分析，及时发现通信路径上的失效节点，通过发送故障预警通知消息，及时触发对该失效节点的故障检测流程和故障恢复流程，可以使失效节点能够及时被自动修复，将故障修复在萌芽状态，保障了系统长期地，稳定地正常运行，有效避免了故障扩散，提高系统可靠性。

参阅图6，本发明实施例提供一种监控设备，其包括：

第一获取单元61，用于获取通信单元上报的业务处理失败事件；所述业务处理失败事件包括：业务处理失败的对象实体的地址信息；

确定单元62，用于根据通信单元上报的业务处理失败事件和预置的失效判别准则，确定发生异常的实体；

发送单元63，用于发送故障预警通知消息，所述故障预警通知消息包括：所确定的发生异常的实体中至少一个实体的信息，所述故障预警通知消息用于指示进行故障检测。

其中，确定单元62包括：获取子单元621，用于利用通信单元上报的业务处理失败事件，统计失效指标值；确定子单元622，用于根据所述失效指标值和失效判别准则中相应的失效阈值，确定发生异常的对象实体。

该监控设备还可以包括：配置单元68，用于配置并保存上述失效判别准则。

具体的，获取子单元621，用于利用通信单元上报的业务处理失败事件，统计连续业务处理失败次数的累加值；所述连续业务处理失败次数的累加值为失效指标值；或者，获取子单元621，用于利用通信单元上报的业务处理失败事件，获得一段时间内的业务处理失败次数占总业务处理次数的比值；所述一段时间内的业务处理失败次数占总业务处理次数的比值为失效指标值；或者，获取子单元621，用于在接收到通信单元上报的业务处理失败事件后，查询关键业绩指标，所述关键业绩指标为所述失效指标值。

具体的，获取子单元621包括第一统计子单元6211、第二统计子单元6212和第三统计子单元6213，

第一统计子单元6211具体用于利用通信单元上报的业务处理失败事件，针对硬件实体统计失效指标值，其中，所述硬件实体是所述对象实体所属硬件；

第二统计子单元6212具体用于利用通信单元上报的业务处理失败事件，针对软件实体统计失效指标值，其中，所述软件实体为以对象实体所属硬件的物理地址信息和对象实体的逻辑地址信息两者所对应的实体；

第三统计子单元6213具体用于利用通信单元上报的业务处理失败事件，针对逻辑资源实体统计失效指标值，所述逻辑资源实体为所述对象实体所属硬件的物理地址信息和业务处理失败的原因指示信息两者所对应的实体；

确定子单元622包括第一确定子单元6221、第二确定子单元6222和第二确定子单元6223，

第一确定子单元6221具体用于根据针对硬件实体所统计的失效指标值和失效判别准则中针对所述硬件实体的第一失效阈值，确定所述硬件实体是否异常。

第二确定子单元6222，用于根据针对软件实体所统计的失效指标值和失效判别准则中针对所述软件实体的第二失效阈值，确定所述软件实体是否异常。

第三确定子单元6223，用于根据针对逻辑资源实体所统计的失效指标值和失效判别准则中针对所述逻辑资源实体的第三失效阈值，确定所述逻辑资源实体是否异常。

具体的，发送单元63，用于当仅硬件实体故障时，发送包括对象实体所属硬件的物理地址信息的故障预警通知消息；当硬件实体和软件实体都异常时，发送仅包括软件实体的信息的故障预警通知消息，所述软件实体信息包括：对象实体所属硬件的物理地址信息和对象实体的逻辑地址信息；当硬件实体和逻辑资源实体都异常时，发送仅包括逻辑资源实体信息的故障预警通知消息，所述逻辑资源实体信息包括：对象实体所属硬件的物理地址信息和业务处理失败的原因指示信息。

具体的，所述对象实体所属硬件的物理地址信息包括：第一级子地址；所述对象实体所属硬件是第一级子地址对应的硬件的组件；

为了确保异常的实体能够及时被修复，将故障修复在萌芽状态，该监控设备还包括：第一控制单元69和第二控制单元610，

其中，第一控制单元69用于在发送包括对象实体所属硬件的物理地址信息的故障预警通知消息之后的预设时间段内，若第一确定子单元6221确定硬件实体一直异常，控制发送单元63发送包括第一级子地址的故障预警通知消息；此时发送单元63还用于发送包括第一级子地址的故障预警通知消息。此时，发送单元63还用于发送包括第一级子地址的故障预警通知消息。

第二控制单元610，用于在发送包括软件实体信息或者逻辑资源实体信息的故障预警通知消息之后的预设时间段内，若第一确定子单元6221确定硬件实体一直异常，控制发送单元63发送包括硬件实体信息的故障预警通知消息，所述硬件实体信息包括：对象实体所属硬件的物理地址信息。此时，发送单元63还用于发送包括硬件实体信息的故障预警通知消息。

可选的，业务处理失败事件还包括：所述通信单元的当前负荷量；

可选的，为了保证失效分析的准确性，该监控设备还包括：第一判断单元64和第二判断单元65，

其中，第一判断单元64用于判断所述通信单元的当前负荷量是否小于预设阈值，如果否，丢弃所述业务处理失败事件；此时确定单元62用于在第一判断单元64的判断结果为是时，根据通信单元上报的业务处理失败事件和预置的失效判别准则，确定发生异常的实体。

第二判断单元65，用于判断所述业务处理失败事件是否携带指示由终端设备导致业务处理失败的特定指示标识，如果是，丢弃所述业务处理失败事件；此时确定单元62，用于在第二判断单元65的判断结果为否时，根据通信单元上报的业务处理失败事件和预置的失效判别准则，确定发生异常的实体。

可选的，第一获取单元61具体用于获取通过子监控设备转发的通信单元上报的业务处理失败事件，所述业务处理失败事件是当业务处理失败的对象实体不属于子监控设备的管理范围时由子监控设备转发的。

可选的，发送单元63具体用于向业务处理失败的对象实体或者业务处理失败的对象实体的管理模块发送故障预警通知消息。

为了保证失效分析的准确性，该监控设备还包括：第二获取单元66，用于获取通信单元上报的业务处理成功事件；清零单元67，用于在第二获取单元获取到业务处理成功事件之后，将统计的失效指标值清零，具体的，将第一统计子单元6211、第二统计子单元6212或者第三统计子单元6213所统计的失效指标值清零。

可选的，为了确保异常的实体能够及时被修复，将故障修复在萌芽状态，该监控设备还可以包括：接收单元611，

接收单元611，用于接收故障失效查询消息，所述故障失效查询消息是业务处理失败的对象实体或者业务处理失败的对象实体的管理模块发送的；

发送单元63，还用于根据确定子单元的确定结果，发送响应消息，所述响应消息包括当前最新的失效分析结果，具体的，响应消息包括：已发送的故障预警通知消息所针对的异常实体的当前最新失效分析结果。如果发送的故障预警通知消息是针对硬件实体的(即所述故障预警通知消息包括硬件实体的信息)，则响应消息包括该硬件实体的当前最新失效分析结果，即指示该硬件实体是否异常的信息；如果发送的故障预警通知消息是针对软件实体的(即所述故障预警通知消息包括软件实体的信息)，则响应消息包括该软件实体的当前最新失效分析结果，即指示该软件实体是否异常的信息；如果发送的故障预警通知消息是针对逻辑资源实体的(即所述故障预警通知消息包括逻辑资源实体的信息)，则响应消息包括该逻辑资源实体的当前最新失效分析结果，即指示该逻辑资源实体是否异常的信息。

本发明实施例中通信单元在对象实体业务处理失败时及时上报业务处理失败事件，监控设备进行失效分析确定具体的发生异常的实体，并发送故障预警通知消息，及时触发对该发生异常的实体的故障检测流程和故障恢复流程，不仅可以使发生异常的实体能够及时被自动修复或隔离，将故障修复在萌芽状态，保障了系统长期地，稳定地正常运行，有效避免了故障扩散，提高系统可靠性。另外，故障检测流程是在分析发现系统失效后才触发，并且可以是只针对发生异常的实体触发，所以不仅可以保证故障检测产生的故障告警与系统失效表现的一致性，而且能有效抑制无关的告警上报。本实施例提供的技术方案可以将系统中所有业务处理失败进行监控，包括信令消息处理失败，管理消息处理失败，和业务码流的处理失败，可以覆盖系统所有业务处理失败，可以保证系统能检测到所有通信单元的失效，保证了检测的完备性，这样即使某些通信单元在系统中没有设计相关的故障检测技术，也能通过本发明所描述的方案基本确定通信单元的失效，进而采取针对性的故障恢复措施，使发生异常的通信单元能够及时被自动修复，系统恢复正常。

参阅图7，本发明实施例提供一种通信系统，适用于分布式的失效分析处理模式，其包括：通信单元701，子监控单元702，和父监控单元703，具体的，

子监控单元702，用于获取通信单元701上报的业务处理失败事件，根据业务处理失败事件中携带的业务处理失败的对象实体的地址信息，确定该业务处理失败的对象实体不属于自己管理的范围，将该业务处理失败事件上报给父监控单元703；

父监控单元703，用于根据业务处理失败事件中携带的业务处理失败的对象实体的地址信息，确定该业务处理失败的对象实体是否属于自己管理的范围，如果是，根据通信单元701上报的业务处理失败事件和预置的失效判别准则，确定发生异常的实体，发送用于指示进行故障检测的故障预警通知消息，所述故障预警通知消息包括：所确定的发生异常的实体中至少一个实体的信息；如果否，继续将所述业务处理失败事件上报给所述父监控单元703的父监控单元。

其中，父监控单元是网络级监控单元，其位于中心网管设备上，子监控单元是网元级监控单元，其位于网元的中心控制单板上；或者，父监控单元是网元级监控单元，其位于网元的中心控制单板上，子监控单元是框级监控单元，其位于框的中心控制单板上；或者，父监控单元是框级监控单元，其位于框的中心控制单板上，子监控单元是单板级监控单元，其位于通信单元所在的单板上。具体参见说明书方法实施例中的相应描述，在此不再赘述。

本发明实施例中通信单元在对象实体业务处理失败时及时上报业务处理失败事件，监控单元进行失效分析确定具体的发生异常的实体，并发送故障预警通知消息，及时触发对该发生异常的实体的故障检测流程和故障恢复流程，不仅可以使发生异常的实体能够及时被自动修复，将故障修复在萌芽状态，保障了系统长期地，稳定地正常运行，有效避免了故障扩散，提高系统可靠性。

参阅图8，本发明实施例提供一种通信系统，其包括：第一通信单元801、第二通信单元802和监控单元803，

监控单元803，用于获取第一通信单元801上报的业务处理失败事件，获取第二通信单元802上报的业务处理失败事件，当第一通信单元801上报的业务处理失败事件携带的业务处理失败的对象实体的地址信息为第二通信单元802的地址信息，且第二通信单元802上报的业务处理失败事件携带的业务处理失败的对象实体的地址信息为第一通信单元801的地址信息时，不对第一通信单元801和第二通信单元802进行失效分析。

其中，不对第一通信单元801和第二通信单元802进行失效分析具体指：监控单元803根据第一通信单元801上报的业务处理失败事件、第二通信单元802上报的业务处理失败事件和预置的失效判决准则，不对第一通信单元801和第二通信单元802进行失效分析。其中，预置的失效判决准则规定彼此通信的两个通信单元上报的业务处理失败事件所指向的对象实体均为对端通信单元时，不对这两个通信单元进行失效分析。

需要说明的是，由于当彼此通信的两个通信单元上报的业务处理失败事件所指向的对象实体均为对端通信单元时表示该第一通信单元到第二通信单元之间的通信路径故障，因而不需要对这两个通信单元进行失效分析。具体参见说明书方法实施例中的相应描述，在此不再赘述。

本发明实施例提供的通信系统中，当彼此应该进行通信的两个通信单元上报的业务处理失败事件所指向的对象实体均为对端通信单元时，不对这两个通信单元进行失效分析，避免导致错误的失效分析结果。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，例如只读存储器，磁盘或光盘等。

以上对本发明实施例所提供的故障监控方法、通信设备及通信系统进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (33)

1.一种故障监控方法，其特征在于，包括：

获取通信单元上报的业务处理失败事件；

当硬件实体发生异常时，所述业务处理失败事件包括业务处理失败的对象实体的物理地址信息；

当软件实体发生异常时，所述业务处理失败事件包括业务处理失败的对象实体的逻辑地址信息；

当逻辑资源实体发生异常时，所述业务处理失败事件包括业务处理失败的对象实体的物理地址信息，和业务处理失败的原因指示信息；

利用通信单元上报的业务处理失败事件，针对一个或者多个所述业务处理失败的对象实体统计失效指标值；根据所统计的失效指标值和预置的失效判别准则中相应的失效阈值，确定发生异常的实体，发送用于指示进行故障检测的故障预警通知消息，所述故障预警通知消息包括：所确定的发生异常的实体中至少一个实体的信息。

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

所述利用通信单元上报的业务处理失败事件，针对一个或者多个所述业务处理失败的对象实体统计失效指标值包括：

所述利用通信单元上报的业务处理失败事件，统计连续业务处理失败次数的累加值；所述连续业务处理失败次数的累加值为失效指标值；

或者，

所述利用通信单元上报的业务处理失败事件，获得一段时间内的业务处理失败次数占总业务处理次数的比值；所述一段时间内的业务处理失败次数占总业务处理次数的比值为失效指标值。

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

所述利用通信单元上报的业务处理失败事件，针对一个或者多个所述业务处理失败的对象实体统计失效指标值包括：

接收到通信单元上报的业务处理失败事件后，查询关键业绩指标，所述关键业绩指标为所述失效指标值。

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

所述根据所述失效指标值和失效判别准则中相应的失效阈值，确定发生异常的实体包括：

根据针对硬件实体所统计的失效指标值和失效判别准则中针对所述硬件实体的第一失效阈值，确定所述硬件实体是否异常。

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

所述发送用于指示进行故障检测的故障预警通知消息具体为：

发送包括对象实体所属硬件的物理地址信息的故障预警通知消息；

其中，所述对象实体所属硬件的物理地址信息包括：第一级子地址；所述对象实体所属硬件是第一级子地址对应的硬件的组件；

在发送包括对象实体所属硬件的物理地址信息的故障预警通知消息后，该方法还包括：若预设时间段内确定所述对象实体所属硬件一直异常，则发送包括第一级子地址的故障预警通知消息。

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

所述根据所述失效指标值和失效判别准则中相应的失效阈值，确定发生异常的实体还包括；

根据针对软件实体所统计的失效指标值和失效判别准则中针对所述软件实体的第二失效阈值，确定所述软件实体是否异常。

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

发送用于指示进行故障检测的故障预警通知消息具体为：

当硬件实体和软件实体都异常时，发送仅包括软件实体信息的故障预警通知消息，所述软件实体信息包括：对象实体所属硬件的物理地址信息和对象实体的逻辑地址信息。

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

所述根据所述失效指标值和失效判别准则中相应的失效阈值，确定发生异常的实体还包括：

根据针对逻辑资源实体所统计的失效指标值和失效判别准则中针对所述逻辑资源实体的第三失效阈值，确定所述逻辑资源实体是否异常。

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

发送用于指示进行故障检测的故障预警通知消息具体为：

当硬件实体和逻辑资源实体都异常时，发送仅包括逻辑资源实体信息的故障预警通知消息，所述逻辑资源实体信息包括：对象实体所属硬件的物理地址信息和业务处理失败的原因指示信息。

10.根据权利要求7或者9所述的方法，其特征在于，该方法还包括：

在发送用于指示进行故障检测的故障预警通知消息之后的预定时间段内，确定所述硬件实体一直异常，发送包括硬件实体信息的故障预警通知消息，所述硬件实体信息包括：对象实体所属硬件的物理地址信息。

11.根据权利要求2-9任意一项所述的方法，其特征在于，

所述业务处理失败事件还包括：所述通信单元的当前负荷量；

该方法还包括：判断所述通信单元的当前负荷量是否小于预设阈值，如果是，触发执行统计失效指标值的步骤；如果否，丢弃所述业务处理失败事件。

12.根据权利要求2-9任意一项所述的方法，其特征在于，

该方法还包括：判断所述业务处理失败事件是否携带指示由终端设备导致业务处理失败的特定指示标识，如果否，触发执行统计失效指标值的步骤；如果是，丢弃所述业务处理失败事件。

13.根据权利要求1-9任一项所述的方法，其特征在于，

所述业务处理失败事件是信令消息处理失败事件，或者，管理消息处理失败事件，或者，业务码流处理失败事件，或者，接口调用处理失败事件。

14.根据权利要求1-9任一项所述的方法，其特征在于，

所述业务处理失败事件是通信单元在确定来自对端通信单元的信令消息中字段赋值异常时上报的信令消息处理失败事件；

或者，所述业务处理失败事件是通信单元在预定时间段内未接收到对端通信单元的响应消息时上报的信令消息处理失败事件。

15.根据权利要求1-9任一项所述的方法，其特征在于，

获取通信单元上报的业务处理失败事件具体为：

获取通过子监控设备转发的通信单元上报的业务处理失败事件，所述业务处理失败事件是当业务处理失败的对象实体不属于子监控设备的管理范围时由子监控设备转发的。

16.根据权利要求2、4-9任一项所述的方法，其特征在于，该方法还包括：

获取通信单元上报的业务处理成功事件，将所述失效指标值清零。

17.根据权利要求1-9任一项所述的方法，其特征在于，

所述发送故障预警通知消息具体为：

向业务处理失败的对象实体发送故障预警通知消息；

或者，向业务处理失败的对象实体的管理模块发送故障预警通知消息。

18.一种监控设备，其特征在于，包括：

第一获取单元，用于获取通信单元上报的业务处理失败事件；当硬件实体发生异常时，所述业务处理失败事件包括业务处理失败的对象实体的物理地址信息；当软件实体发生异常时，所述业务处理失败事件包括业务处理失败的对象实体的逻辑地址信息；当逻辑资源实体发生异常时，所述业务处理失败事件包括业务处理失败的对象实体的物理地址信息，和业务处理失败的原因指示信息；

获取子单元，用于利用通信单元上报的业务处理失败事件，针对一个或者多个所述业务处理失败的对象实体统计失效指标值；

确定子单元，用于根据所统计的失效指标值和预置的失效判别准则中相应的失效阈值，确定发生异常的实体；

发送单元，用于发送故障预警通知消息，所述故障预警通知消息包括：所确定的发生异常的实体中至少一个实体的信息，所述故障预警通知消息用于指示进行故障检测。

19.根据权利要求18所述的监控设备，其特征在于，

所述获取子单元，用于利用通信单元上报的业务处理失败事件，统计连续业务处理失败次数的累加值；所述连续业务处理失败次数的累加值为失效指标值；

或者，

所述获取子单元，用于利用通信单元上报的业务处理失败事件，获得一段时间内的业务处理失败次数占总业务处理次数的比值；所述一段时间内的业务处理失败次数占总业务处理次数的比值为失效指标值。

20.根据权利要求18所述的监控设备，其特征在于，

所述获取子单元，用于在接收到通信单元上报的业务处理失败事件后，查询关键业绩指标，所述关键业绩指标为所述失效指标值。

21.根据权利要求19所述的监控设备，其特征在于，

所述获取子单元包括第一统计子单元，

所述第一统计子单元，用于利用通信单元上报的业务处理失败事件，针对硬件实体统计失效指标值，其中，所述硬件实体是所述对象实体所属硬件；

所述确定子单元包括第一确定子单元，

所述第一确定子单元，用于根据针对硬件实体所统计的失效指标值和失效判别准则中针对所述硬件实体的第一失效阈值，确定所述硬件实体是否异常。

22.根据权利要求21所述的监控设备，其特征在于，

其中，所述对象实体所属硬件的物理地址信息包括：第一级子地址；所述对象实体所属硬件是第一级子地址对应的硬件的组件；

该监控设备还包括：

第一控制单元，用于当发送包括对象实体所属硬件的物理地址信息的故障预警通知消息之后的预设时间段内，若第一确定子单元确定硬件实体一直异常，控制发送单元发送包括第一级子地址的故障预警通知消息；

所述发送单元，还用于发送包括第一级子地址的故障预警通知消息。

23.根据权利要求21所述的监控设备，其特征在于，

所述获取子单元还包括第二统计子单元，

所述第二统计子单元，用于利用通信单元上报的业务处理失败事件，针对软件实体统计失效指标值，其中，所述软件实体为以对象实体所属硬件的物理地址信息和对象实体的逻辑地址信息两者所对应的实体；

所述确定子单元包括第二确定子单元，

所述第二确定子单元，用于根据针对软件实体所统计的失效指标值和失效判别准则中针对所述软件实体的第二失效阈值，确定所述软件实体是否异常。

24.根据权利要求23所述的监控设备，其特征在于，

所述发送单元，用于当硬件实体和软件实体都异常时，发送仅包括软件实体的信息的故障预警通知消息，所述软件实体信息包括：对象实体所属硬件的物理地址信息和对象实体的逻辑地址信息。

25.根据权利要求21所述的监控设备，其特征在于，

所述统计子单元还包括第三统计子单元，

所述第三统计子单元，用于利用通信单元上报的业务处理失败事件，针对逻辑资源实体统计失效指标值，所述逻辑资源实体为所述对象实体所属硬件的物理地址信息和业务处理失败的原因指示信息两者所对应的实体；

所述确定子单元还包括第三确定子单元，

所述第三确定子单元，用于根据针对逻辑资源实体所统计的失效指标值和失效判别准则中针对所述逻辑资源实体的第三失效阈值，确定所述逻辑资源实体是否异常。

26.根据权利要求25所述的监控设备，其特征在于，

所述发送单元，用于当硬件实体和逻辑资源实体都异常时，发送仅包括逻辑资源实体信息的故障预警通知消息，所述逻辑资源实体信息包括：对象实体所属硬件的物理地址信息和业务处理失败的原因指示信息。

27.根据权利要求24或者26所述的监控设备，其特征在于，

该监控设备还包括：

第二监控单元，用于在所述发送单元发送故障预警通知消息之后的预设时间段内，若第一确定子单元确定所述硬件实体一直异常，控制发送单元发送包括硬件实体信息的故障预警通知消息，所述硬件实体信息包括：对象实体所属硬件的物理地址信息；

所述发送单元，还用于发送包括硬件实体信息的故障预警通知消息。

28.根据权利要求18-26任一项所述的监控设备，其特征在于，

所述业务处理失败事件还包括：所述通信单元的当前负荷量；

所述监控设备还包括：第一判断单元，用于判断所述通信单元的当前负荷量是否小于预设阈值，如果否，丢弃所述业务处理失败事件；

所述确定单元，用于在所述第一判断单元的判断结果为是时，根据通信单元上报的业务处理失败事件和预置的失效判别准则，确定发生异常的实体。

29.根据权利要求18-26任一项所述的监控设备，其特征在于，

所述监控设备还包括：第二判断单元，用于判断所述业务处理失败事件是否携带指示由终端设备导致业务处理失败的特定指示标识，如果是，丢弃所述业务处理失败事件；

所述确定单元，用于在所述第二判断单元的判断结果为否时，根据通信单元上报的业务处理失败事件和预置的失效判别准则，确定发生异常的实体。

30.根据权利要求18-26任一项所述的监控设备，其特征在于，

所述第一获取单元，用于获取通过子监控设备转发的通信单元上报的业务处理失败事件，所述业务处理失败事件是当业务处理失败的对象实体不属于子监控设备的管理范围时由子监控设备转发的。

31.根据权利要求19、21-26任一项所述的监控设备，其特征在于，

该监控设备还包括：

第二获取单元，用于获取通信单元上报的业务处理成功事件；

清零单元，用于在第二获取单元获取到业务处理成功事件之后，将统计的失效指标值清零。

32.一种通信系统，其特征在于，包括：通信单元，子监控单元，和父监控单元，其中，

子监控单元，用于获取通信单元上报的业务处理失败事件，当硬件实体发生异常时，所述业务处理失败事件包括业务处理失败的对象实体的物理地址信息；当软件实体发生异常时，所述业务处理失败事件包括业务处理失败的对象实体的逻辑地址信息；当逻辑资源实体发生异常时，所述业务处理失败事件包括业务处理失败的对象实体的物理地址信息，和业务处理失败的原因指示信息；根据业务处理失败事件中携带的业务处理失败的对象实体的地址信息，确定所述业务处理失败的对象实体不属于自己管理的范围，将该业务处理失败事件上报给父监控单元；

父监控单元，用于接收子监控单元上报的业务处理失败事件，根据业务处理失败事件中携带的业务处理失败的对象实体的地址信息，确定所述业务处理失败的对象实体是否属于自己管理的范围，如果是，利用通信单元上报的业务处理失败事件，针对一个或者多个所述业务处理失败的对象实体统计失效指标值；根据所统计的失效指标值和预置的失效判别准则中相应的失效阈值，确定发生异常的实体，发送用于指示进行故障检测的故障预警通知消息，所述故障预警通知消息包括：所确定的发生异常的实体中至少一个实体的信息；如果否，继续将所述业务处理失败事件上报给所述父监控单元的父监控单元。

33.一种通信系统，其特征在于，包括：第一通信单元、第二通信单元和监控单元，

监控单元，用于获取第一通信单元上报的业务处理失败事件，当硬件实体发生异常时，所述业务处理失败事件包括业务处理失败的对象实体的物理地址信息；当软件实体发生异常时，所述业务处理失败事件包括业务处理失败的对象实体的逻辑地址信息；当逻辑资源实体发生异常时，所述业务处理失败事件包括业务处理失败的对象实体的物理地址信息，和业务处理失败的原因指示信息；获取第二通信单元上报的业务处理失败事件，当第一通信单元上报的业务处理失败事件携带的业务处理失败的对象实体的地址信息为第二通信单元的地址信息，且第二通信单元上报的业务处理失败事件携带的业务处理失败的对象实体的地址信息为第一通信单元的地址信息时，不对第一通信单元和第二通信单元进行统计失效指标值的失效分析。

Images