CN102045213B - 故障定位方法及装置 - Google Patents

Abstract

本发明涉及通信技术领域，公开了一种故障定位方法及装置，所述方法包括：对业务运行的轨迹进行监控；当所述轨迹出现异常时，根据所述轨迹进行故障诊断及定位。利用本发明，可以有效诊断及定位故障。

Description

故障定位方法及装置

技术领域

本发明涉及通信技术，具体涉及一种故障定位方法及装置。

背景技术

目前，通信应用软件越来越复杂，因此为了保证系统的正常运行，一旦出现故障，需要对故障能够进行快速诊断及定位。通常系统发生故障时与当前业务数据、系统资源状况、周边系统状况、具体业务参数等多方面因素有关，发生故障时定位原因的难度很高。

在现有技术中，一般是在系统开发阶段预先分析，确定哪些点可能会出现系统异常或业务处理异常。当发生系统级异常或业务处理异常时，通过以告警的方式发给监控台，通知维护人员，维护人员根据告警信息来定位故障位置以及原因。业务处理异常一般体现在性能统计中，当异常达到门限时转为告警。除此之外，现有技术中还可以采用构造条件进行模拟测试，重现故障，或者通过在线跟踪的方式，获取系统运行时的信息。

在实现本发明的过程中，发明人发现现有技术至少存在以下问题：

系统所发出的告警信息记录的是故障发生点的信息，有利于定位故障的信息量非常有限，根据这些信息有时无法准确诊断及定位故障。

发明内容

本发明实施例提供一种故障定位方法及装置，以有效诊断及定位故障。

本发明实施例提供一种故障定位方法，包括：

对业务运行的轨迹进行监控；

当监控到所述轨迹出现异常时，根据所述轨迹进行故障诊断及定位，包括：

在系统加载、升级、扩容或卸载时，将关键业务节点注册为候选监控节点；

从所述候选监控节点中选择轨迹节点；

为所述轨迹节点配置参数信息，生成轨迹注册表；

所述对业务运行的轨迹进行监控包括：

根据所述轨迹注册表确定各轨迹节点是否异常；

如果所述轨迹节点异常，则确定所述轨迹异常，其中，所述为所述轨迹节点配置参数信息包括：为所述轨迹节点配置以下任意一项或多项参数：节点类型、左节点约束、右节点约束、父节点约束、快照控制参数。

本发明实施例提供一种故障定位装置，包括：轨迹监控代理单元和轨迹处理单元；

所述轨迹监控代理单元，用于对业务运行的轨迹进行监控，将监控到的轨迹上报给所述轨迹处理单元；

所述轨迹处理单元，用于接收所述轨迹监控代理单元上报的轨迹，对所述轨迹接口子单元接收的轨迹进行诊断，并在诊断到所述轨迹异常时，根据所述轨迹进行故障诊断及定位，包括：

轨迹接口子单元，用于接收所述轨迹监控代理单元上报的轨迹；

轨迹诊断子单元，用于对所述轨迹接口子单元接收的轨迹进行诊断，并在诊断到所述轨迹异常时，根据所述轨迹进行故障诊断及定位；

所述轨迹监控代理单元，还用于对监控到的轨迹进行诊断，诊断出正常的业务轨迹，并将剩余的业务轨迹上报给所述轨迹处理单元，并在系统加载、升级、扩容或卸载时向所述轨迹处理单元上报节点信息；

所述轨迹接口子单元，还用于接收所述轨迹监控代理单元上报的节点信息；

所述轨迹处理单元还包括：轨迹注册子单元，用于根据所述轨迹接口子单元接收的节点信息，将关键业务节点注册为候选监控节点，并从所述候选监控节点中选择轨迹节点，为所述轨迹节点配置参数信息，生成轨迹注册表；

所述轨迹诊断子单元，具体用于根据根据所述轨迹注册表对所述轨迹监控代理单元上报的轨迹进行诊断，确定所述轨迹是否异常。

本发明实施例提供的故障定位方法及装置，通过对业务运行的轨迹进行监控，当所述轨迹出现异常时，根据所述轨迹进行故障诊断及定位，从而可以准确地进行故障诊断及定位。本发明扩展性强，适用范围广，不仅可以适用于通信软件行业，而且可以推广到其他领域。

附图说明

图1是本发明实施例故障定位方法的一种流程图；

图2是本发明实施例中轨迹注册表的一种结构示意图；

图3是本发明实施例故障定位方法的另一种流程图；

图4是本发明实施例故障定位装置的一种结构示意图；

图5是本发明实施例故障定位装置的另一种结构示意图；

图6是应用本发明实施例故障定位装置在线计费时的故障处理流程图。

具体实施方式

为了使本技术领域的人员更好地理解本发明实施例的方案，下面结合附图和实施方式对本发明实施例作进一步的详细说明。

如图1所示，是本发明实施例故障定位方法的一种流程图，包括以下步骤：

步骤101，对业务运行的轨迹进行监控。

由于业务运行正常或异常流程都会经过多个步骤，形成一个运行轨迹，可以定义不同层次的轨迹，比如对应一个流程的轨迹，或者对于一个步骤的轨迹。因此，可以对该业务运行过程中的各轨迹进行监控，当监控到异常轨迹时记录该异常轨迹及相关快照信息，从而进行故障诊断。

由于业务系统往往会很复杂，配置全部步骤与分支的复杂度高、维护成本也很高，因此，为了降低实现的复杂度，可以对各轨迹选择一个或多个关键的轨迹节点，轨迹节点可以是业务流程的步骤，各步骤可以由：关键API（Application Programming Interface，应用程序编程接口）、组件、部件等来执行。具体地，可以在业务加载、升级、扩容或卸载时将关键业务节点注册为候选监控节点，从候选监控节点中选择轨迹节点。

除此之外，为了保证能够正确判断轨迹节点运行是否正常，还可以为轨迹节点配置参数信息，生成轨迹注册表。参数信息包括以下任意一项或多项参数：节点类型（必备节点、禁止节点、可选节点）、左节点约束、右节点约束、父节点约束、快照控制参数。当然，根据业务的不同，参数信息也不仅限于包括上述这些参数。其中，左、右节点约束，指当前步骤与前一步（左节点）、后一步（右节点）存在关联依赖关系，前后步骤符合一定的约束条件；父节点约束指当前步骤与上一层存在关联依赖关系。其中：必备节点，是指所述轨迹必须经历的节点；禁止节点，是指所述轨迹不允许经历的节点；可选节点，是指所述轨迹可经历也可不经历的节点。

上述快照控制参数可以是轨迹异常时，需要快照的信息范围，相应于不同层次的轨迹，所述快照也可以是多级。

快照信息包括以下任意一项或多项：

（1）系统运行的环境数据，比如：软件运行机制的操作系统、CPU、数据库、进程占用的系统资源等；

（2）业务处理动态数据，主要包括业务流程中涉及的特有的数据，比如拨打电话时的电话号码、余额、状态等信息；

（3）周边部件传递的信息，即业务流程交互时传递的数据信息，比如银行跨行转帐时其他银行传递过来的转帐金额等数据。

当然，本发明实施例也不仅限于上述这些快照信息。针对不同的异常场景，可以有不同的快照控制参数。对于可选节点，还可以为其配置概率范围参数，具体可以是百分比或数量，将在后面详细说明。

轨迹注册表可以采用树型结构保存各轨迹节点。在本发明实施例中，轨迹注册表可以有多种表示方式，比如：

（1）维护绝对路径，即采用“线”的方式维护节点顺序列表，适用于轨迹分支较少的业务系统，优点是直观清晰；

（2）维护相对路径，即采用“点”的方式维护关键节点的前后依赖关系，适用于轨迹分支较多的场景，优点是便于维护、管理，抓住关键问题。

如图2所示，是本发明实施例中轨迹注册表的一种结构示意图。

其中，A、B、C、D、E是业务流程的步骤，也就是流程轨迹中的轨迹节点，A1、A2、A3是轨迹节点A下的子步骤。其中，A1是必备节点，A2是可选节点，A3是禁止节点。

A1节点下还包括两个子节点：A11和A12，B节点下中包括一个子节点B1，D节点包括两个子节点：D1和D2，D1节点包括两个子节点：D11和D12，其中，D11为必备节点，D12为禁止节点。

这样，在对业务运行的轨迹进行监控时，可以根据轨迹注册表确定轨迹是否异常。

步骤102，当轨迹出现异常时，根据轨迹进行故障诊断及定位。

由于轨迹注册表保存了轨迹节点的一些参数信息，因此，可以根据轨迹注册表判断当前轨迹是否异常。比如，可以从以下几个方面来判断轨迹是否异常：

（1）对于必备节点，如果当前轨迹中不存在该节点，或其左节点、右节点、或父节点不符合约束，则认为当前轨迹异常。比如用户拨打长途电话过程中，必须执行“检查用户是否具有长途权限”的步骤，如果没有执行该步骤则认为是异常流程。

（2）对于禁止节点，如果当前轨迹中存在该节点，则认为当前轨迹异常。比如在线计费系统中，由于采用先预留后扣费的方式，因此不存在扣负或欠费场景。当预付费用户拨打电话时计费处理中执行了记欠费的步骤，则认为是异常流程。

（3）对于可选节点，如果当前轨迹中其左节点、父节点不符合约束，并且这种情况在监控周期内发生的概率超出一定阈值，则认为当前轨迹异常。比如，某个时间段内“呼叫响应超时”步骤被调用次数超出一定阈值，则认为是异常流程。

可见，只要有必备节点或禁止节点出现异常，则可以确定整个流程异常；对于可选节点，可以根据其周期性的概率统计来确定整个流程是否异常。需要说明的是，由于量变可以引起质变，低于阈值时的相关信息对故障定位也有一定的参考意见。因此，在本发明实施例中，在当前监控周期内，还可以缓存影响轨迹的相关信息，比如资源使用情况等，到新的监控周期后，如果可选节点的其周期性的概率统计值未超出设定的阈值，则清除缓存的相关信息。

可见，本发明实施例故障定位方法，通过对业务运行的轨迹进行监控，当轨迹出现异常时，根据轨迹进行故障诊断及定位，从而可以及时、完整地保护第一现场，根据记录的异常信息及相关快照信息可以准确地进行故障诊断及定位。

本发明实施例故障定位方法，可以降低故障定位难度，方便了运营商对系统的维护。在对业务运行轨迹监控时，记录关键轨迹，相对于现有技术记录比较详细的跟踪日志而言，成本更低；而且由于系统运行时，绝大多数业务都属于正常轨迹，而在故障处理时只是在诊断出是故障流程时才需输出快照信息，因而对系统性能损耗很小。

本发明实施例故障定位方法扩展性强，适用范围广，不仅可以适用于通信软件行业，而且可以推广到其他领域。

在业务运行中，根据业务的不同，可能有时只根据记录的业务轨迹无法准确地对故障进行诊断和定位。在这种情况下，还可以通过获取相关快照信息，利用所述快照信息准确地进行故障诊断及定位。

如图3所示，是本发明实施例故障定位方法的另一种流程图，包括以下步骤：

步骤201，对业务运行的轨迹进行监控。

步骤202，当轨迹出现异常时，确定是否能够根据轨迹进行故障诊断及定位；如果是，则执行步骤203；否则执行步骤204。

步骤203，根据轨迹进行故障诊断及定位。

步骤204，获取与轨迹相关的快照信息。

步骤205，根据获取的相关快照信息进行故障诊断及定位。

为了便于对系统各部分的统一管理，通常会由网管系统来对网络进行统一管理。因此，在本发明实施例故障定位方法中，还可进一步包括以下步骤：将诊断结果上报网管系统。需要说明的是，在实际应用中，考虑到轨迹处理会增加系统资源开销，因此，可以提供轨迹开关，在需要时关闭轨迹的相关处理逻辑，以减少对系统资源的消耗。

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

本发明实施例还提供一种故障定位装置，如图4所示，是该装置的一种结构示意图。

在该实施例中，所述装置包括：轨迹监控代理单元301和轨迹处理单元302，其中：

所述轨迹监控代理单元301，用于对业务运行的轨迹进行监控，将监控到的轨迹上报给轨迹处理单元302；

所述轨迹处理单元302，用于接收所述轨迹监控代理单元上报的轨迹，对所述轨迹接口子单元接收的轨迹进行诊断，并在诊断到所述轨迹异常时，根据所述轨迹进行故障诊断及定位。

在本发明实施例中，所述轨迹处理单元302包括：轨迹接口子单元321和轨迹诊断子单元322，其中：

轨迹接口子单元321，是轨迹处理单元302的对外接口，与轨迹监控代理单元301进行交互，在本发明实施例中，用于接收轨迹监控代理单元301上报的轨迹；当然，还可以提供一些其他功能，比如下达指令及通报给周边系统的轨迹监控代理单元，与网管的交互等，将在后面详细说明。

轨迹诊断子单元322，用于对轨迹接口子单元321接收的轨迹进行诊断，并在诊断到轨迹异常时，根据轨迹进行故障诊断及定位。

当然，在实际应用中，根据系统的不同，轨迹监控代理单元301可以有多个，并且可以分别位于不同的系统或节点中，比如OCS（Online ChargingSystem，在线计费系统），SCP（ServiceControlPoint，业务控制点）等。

需要说明的是，为了降低轨迹处理单元302的处理压力，减少网络开销，还可以将一些基本的轨迹诊断功能转移到轨迹监控代理单元301上，也就是说，在本发明实施例中，轨迹监控代理单元301，还可进一步对监控到的轨迹进行诊断，诊断出正常的业务轨迹，并将剩余的业务轨迹上报给轨迹处理单元302。这样，可以避免每次业务运行时，将所有轨迹上报到轨迹处理单元301。

本发明实施例故障定位装置，可以对业务运行的轨迹进行监控，当所述轨迹出现异常时，根据所述轨迹进行故障诊断及定位，从而可以及时、完整地保护第一现场，根据记录的异常信息及相关快照信息可以准确地进行故障诊断及定位，具体过程可以参照前面本发明实施例故障定位方法中的描述。

在本发明实施例中，为了降低实现的复杂度并且方便本发明实施例故障定位装置在不同业务环境中的应用，还可以只对业务的某些关键轨迹节点进行监控。为此，可以通过注册方式选择出所需监控的轨迹节点。

具体地，如图4所示，是本发明实施例故障定位装置的另一种结构示意图。

与图3所示实施例的区别在于，在该实施例中，轨迹监控代理单元401，还用于在系统加载、升级、扩容或卸载时向轨迹处理单元402上报节点信息。轨迹处理单元402不仅包括轨迹接口子单元421和轨迹诊断子单元422，还包括轨迹注册子单元423。其中：

轨迹接口子单元421还用于接收轨迹监控代理单元401上报的节点信息；

轨迹注册子单元421，用于根据轨迹接口子单元421接收的节点信息，将关键业务节点注册为候选监控节点，并从所述候选监控节点中选择轨迹节点，为所述轨迹节点配置参数信息，生成轨迹注册表。

其中，关键业务节点可以是步骤，这类步骤具体可以是输入、输出（如在线计费时DCC（Diameter Credit Control，Diameter信用控制协议）消息收发、写清单、更新余额等，事务性（如转账包括转出与转入）或低可靠性（如涉及物理存储的访问、文件读写、物理数据库访问、远程访问等）与关键计费功能（如扣费、赠送资金等）。轨迹节点可以是流程步骤、关键API、组件、部件或系统等。轨迹注册表优选为树型结构。

另外，在本发明实施例中，轨迹诊断子单元422，除了具有与图3所示轨迹诊断子单元321同样的功能，即根据轨迹注册表对轨迹监控代理单元301上报的轨迹进行诊断，并在诊断到轨迹异常时，根据轨迹进行故障诊断及定位之外，还进一步用于在诊断到轨迹异常，并且不能根据轨迹进行故障诊断及定位时，通过轨迹接口子单元421向轨迹监控代理单元401下发指令，使轨迹监控代理单元401记录相关快照信息，并根据轨迹监控代理单元401上报的相关快照信息进行故障诊断及定位。

所述轨迹监控代理单元401，还用于根据所述轨迹诊断子单元422的指令，记录相关快照信息并上报给所述轨迹处理单元402。

在系统进行升级等操作后，可能有些节点会发生变化，比如新增节点、或原节点被删除、或节点类型变更等，则轨迹监控代理单元401还需要将这些变化的节点信息上报给轨迹处理单元402，由轨迹处理单元402中的轨迹注册子单元423根据轨迹监控代理单元401上报的信息对轨迹注册表进行修改。

在本发明实施例中，轨迹注册子单元423需要将选择的轨迹节点通知给所述轨迹监控代理单元401，这样，在系统运行时，轨迹监控代理单元301就可以只监控并上报这些轨迹节点的信息。

在本发明实施例中，如果轨迹处理单元402诊断出故障原因是由于周边系统或部件异常引起的，可以上报给网管系统，同时还可以通知相关系统或部件。

在实际应用中，本发明实施例的故障定位装置可以有多种变型，比如，如果不涉及网络级应用，可以将轨迹监控代理单元401和轨迹处理单元402集成在业务系统上，即单机版方式。当然，轨迹监控代理单元401还可以位于业务系统中，轨迹处理单元402还可以作为独立实体。

下面以在线计费系统的故障定位处理过程为例，对本发明实施例的故障定位装置做进一步详细说明。

如图5所示，是应用本发明实施例故障定位装置在线计费时的故障处理流程图。

501．SCP上报计费请求给OCS。

502．OCS进行正常处理，并且OCS上安装的轨迹监控代理单元会记录下当前业务处理的轨迹信息，上报给轨迹处理单元。

当然，OCS上安装的轨迹监控代理单元也可以对基本轨迹进行诊断，过滤掉正常的轨迹，将过滤后剩余的其他轨迹上报给轨迹处理单元。

503．轨迹处理单元对当前轨迹进行分析处理，如果轨迹正常，则通知OCS中的轨迹监控代理单元，即转步骤504；如果诊断出轨迹异常，则转步骤506。

504．通知OCS中的轨迹监控代理单元进行正常业务处理。

505．OCS与SCP进行正常的消息处理。

506．轨迹处理单元根据具体轨迹异常的情况，向OCS中的轨迹监控代理单元下达收集快照数据指令。

507．OCS中的轨迹监控代理单元根据指令进行快照数据的收集，并将收集的快照数据上报给轨迹处理单元。

508．轨迹处理单元根据收到的快照数据进行故障诊断及定位。

509．轨迹处理单元将定位出的故障原因上报给网管系统。

510．如果该故障来源于周边系统SCP，则轨迹处理单元可以通过SCP中的轨迹监控代理单元通知SCP；如果SCP未安装轨迹监控代理单元，则可以通过其它渠道通知SCP，比如在OCS与SCP的消息接口中通知。

可见，利用本发明实施例故障定位装置，可以准确、有效地诊断及定位故障。比如，X局点出现网上故障，故障原因是：对于此超长呼叫业务，在处理到request_number=N时，由于余额不足，OCS反算通话时长为1分钟（GSU=1分钟），此时OCS处理是正确的。但SCP处理异常，上报的实际通话时长为6分钟（USU=6分钟），OCS扣尽余额但已不满6分钟的扣款额。

在计费过程中出现以下计费结果：用户通话3600秒，但扣费金额与通话时长不吻合。由于OCS采用先预留再扣费的方式，上述结果不合常理。

如果按照现有技术，由于计费涉及的场景太复杂，该问题难以再现，故障原因定位困难。电信运营商更没有办法知道是那个步骤出了问题。

如果采用本发明实施例的方法及装置，对于实时业务流程，由于入账扣款不足属于异常场景，作为关键业务节点进行注册（类别为禁止节点），当轨迹流经此节点时快照用户动态数据（本案例为余额），同时通过DCC应答消息通知SCP。这样，由于余额信息及时快照下来，因此能够很快诊断出属于SCP控制出现异常；而SCP根据OCS的消息通知，也便于尽快定位出其故障原因。

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

Claims (10)

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

对业务运行的轨迹进行监控；

当监控到所述轨迹出现异常时，根据所述轨迹进行故障诊断及定位，包括：

在系统加载、升级、扩容或卸载时，将关键业务节点注册为候选监控节点；

从所述候选监控节点中选择轨迹节点；

为所述轨迹节点配置参数信息，生成轨迹注册表；

所述对业务运行的轨迹进行监控包括：

根据所述轨迹注册表确定各轨迹节点是否异常；

如果所述轨迹节点异常，则确定所述轨迹异常，其中，所述为所述轨迹节点配置参数信息包括：为所述轨迹节点配置以下任意一项或多项参数：节点类型、左节点约束、右节点约束、父节点约束、快照控制参数；

其中，所述快照控制参数是指轨迹异常时，需要快照的信息范围。

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

如果根据所述轨迹无法进行故障诊断及定位，则获取与所述轨迹相关的快照信息；

根据获取的快照信息进行故障诊断及定位。

3.根据权利要求2所述的方法，其特征在于，所述快照信息包括以下任意一项或多项：系统运行的环境数据，业务处理动态数据，周边部件传递的信息。

4.根据权利要求3所述的方法，其特征在于，所述节点类型包括：必备节点、禁止节点和可选节点；

所述根据轨迹注册表确定各轨迹节点是否异常包括：

对于类型为必备节点的轨迹节点，如果当前轨迹中不存在该节点，或其左节点、右节点、或父节点不符合约束，则确定该轨迹节点异常；

对于类型为禁止节点的轨迹节点，如果当前轨迹中存在该节点，则确定该轨迹节点异常；

对于类型为可选节点的轨迹节点，如果在监控周期内出现异常的概率超过预定阈值，则确定该轨迹节点异常。

5.根据权利要求1所述的方法，其特征在于，所述轨迹注册表采用树型结构保存各轨迹节点。

6.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

将诊断结果上报网管系统。

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

如果故障定位的结果是故障来源于其他部件，则通知所述其他部件故障信息。

8.一种故障定位装置，其特征在于，包括：轨迹监控代理单元、轨迹处理单元；

所述轨迹监控代理单元，用于对业务运行的轨迹进行监控，将监控到的轨迹上报给所述轨迹处理单元；

所述轨迹处理单元，用于接收所述轨迹监控代理单元上报的轨迹，对所述轨迹接口子单元接收的轨迹进行诊断，并在诊断到所述轨迹异常时，根据所述轨迹进行故障诊断及定位，包括：

轨迹接口子单元，用于接收所述轨迹监控代理单元上报的轨迹；

轨迹诊断子单元，用于对所述轨迹接口子单元接收的轨迹进行诊断，并在诊断到所述轨迹异常时，根据所述轨迹进行故障诊断及定位；

所述轨迹监控代理单元，还用于对监控到的轨迹进行诊断，诊断出正常的业务轨迹，并将剩余的业务轨迹上报给所述轨迹处理单元，并在系统加载、升级、扩容或卸载时向所述轨迹处理单元上报节点信息；

所述轨迹接口子单元，还用于接收所述轨迹监控代理单元上报的节点信息；

所述轨迹处理单元还包括：轨迹注册子单元，用于根据所述轨迹接口子单元接收的节点信息，将关键业务节点注册为候选监控节点，并从所述候选监控节点中选择轨迹节点，为所述轨迹节点配置参数信息，生成轨迹注册表；

所述轨迹诊断子单元，具体用于根据根据所述轨迹注册表对所述轨迹监控代理单元上报的轨迹进行诊断，确定所述轨迹是否异常。

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

所述轨迹诊断子单元，还用于在诊断到所述轨迹异常时，通过所述轨迹接口子单元向所述轨迹监控代理单元下发指令，使所述轨迹监控代理单元记录相关快照信息，并根据所述轨迹监控代理单元上报的异常信息及相关快照信息进行故障诊断及定位；

所述轨迹监控代理单元，还用于根据所述轨迹诊断子单元的指令，记录相关快照信息并上报给所述轨迹处理单元。

10.根据权利要求8所述的装置，其特征在于，所述轨迹监控代理单元和所述轨迹处理单元均位于业务系统中。

Images