CN113434320A - 信息系统故障定位方法、装置、设备及存储介质 - Google Patents

Abstract

本说明书涉及信息系统故障定位技术领域，提供了一种信息系统故障定位方法、装置、设备及存储介质，该方法包括：获取应用层级的告警信息；根据预设的横向关系定位所述告警信息对应的故障应用；所述横向关系包括应用间的依赖关系；根据预设的纵向关系定位所述故障应用的故障点；所述纵向关系包括应用与基础设施的部署关系。本说明书可以实现从大量报警风暴中快速定位故障点。

Description

信息系统故障定位方法、装置、设备及存储介质

技术领域

本说明书涉及信息系统故障定位技术领域，尤其是涉及一种信息系统故障定位方法、装置、设备及存储介质。

背景技术

为满足业务场景的快速灵活创新，应对线上业务不断出现的秒杀、抢购等互联网业务高峰的挑战，现有信息系统正在向着分布式、云化、服务化的方向发展变化。在此发展变化的过程中，伴随着服务器数量的快速扩张以及访问关系的复杂度不断提升，进而使得信息系统的系统架构日益复杂。在此情况下，易出现大量报警风暴。如何从大量报警风暴中快速定位故障发生点(以下简称故障点)是目前亟待解决的技术问题。

发明内容

本说明书实施例的目的在于提供一种信息系统故障定位方法、装置、设备及存储介质，以实现从大量报警风暴中快速定位故障点。

为达到上述目的，一方面，本说明书实施例提供了一种信息系统故障定位方法，包括：

获取应用层级的告警信息；

根据预设的横向关系定位所述告警信息对应的故障应用；所述横向关系包括应用间的依赖关系；

根据预设的纵向关系定位所述故障应用的故障点；所述纵向关系包括应用与基础设施的部署关系。

本说明书的实施例中，所述根据预设的横向关系定位所述告警信息对应的故障应用，包括：

根据所述告警信息对应的IP地址确认目标应用；

确认所述横向关系中是否存在所述目标应用的依赖应用；

当存在所述目标应用的依赖应用时，确认所述依赖应用是否存在对应告警信息；

当所述依赖应用存在对应告警信息时，当所述依赖应用作为新的目标应用；

确认所述横向关系中是否存在所述新的目标应用的依赖应用；

以此递推，直至从所述横向关系中识别出所有的存在对应告警信息且无依赖应用的应用。

本说明书的实施例中，所述根据预设的纵向关系定位所述故障应用的故障点，包括：

拉取所述故障应用在指定时间范围内的各条告警信息；

根据所述各条告警信息在所述纵向关系中所归属的基础设施层级，对所述各条告警信息进行赋影响权值；

对所述各条告警信息的影响权值进行排序；

根据排序结果确定所述故障应用的故障点。

本说明书的实施例中，所述根据排序结果确定所述故障应用的故障点，包括：

将影响权值最大者对应的基础设施层级确定为所述故障应用的故障点。

本说明书的实施例中，所述基础设施层级由低至高依次包括：

物理设备级、操作系统级、数据库级、应用级。

本说明书的实施例中，所述影响权值与所述基础设施层级负相关。

本说明书的实施例中，所述依赖关系包括调用关系。

另一方面，本说明书实施例还提供了一种信息系统故障定位装置，包括：

告警信息获取模块，用于获取应用层级的告警信息；

故障应用定位模块，用于根据预设的横向关系定位所述告警信息对应的故障应用；所述横向关系包括应用间的依赖关系；

故障点定位模块，用于根据预设的纵向关系定位所述故障应用的故障点；所述纵向关系包括应用与基础设施的部署关系。

另一方面，本说明书实施例还提供了一种计算机设备，包括存储器、处理器、以及存储在所述存储器上的计算机程序，所述计算机程序被所述处理器运行时，执行上述方法的指令。

另一方面，本说明书实施例还提供了一种计算机存储介质，其上存储有计算机程序，所述计算机程序被计算机设备的处理器运行时，执行上述方法的指令。

由以上本说明书实施例提供的技术方案可见，本说明书实施例中，可以预先生成应用间的依赖关系，以及应用与基础设施的部署关系；在此基础上，当获取到应用层级的告警信息后，可以根据依赖关系横向定位告警信息对应的故障应用，然后根据应用与基础设施的部署关系纵向定位故障应用的故障点，从而实现了可以在大量报警风暴中快速定位出故障点，提高了大量报警风暴场景下的故障点定位效率。

附图说明

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

图1示出了本说明书一些实施例中信息系统故障定位方法的流程图；

图2示出了本说明书一些实施例中根据关系定位告警信息对应的故障应用的流程图；

图3示出了本说明书一些实施例中根据纵向关系定位故障应用的故障点的流程图；

图4示出了本说明书一实施例中应用间的依赖关系示意图；

图5示出了本说明书一些实施例中信息系统故障定位过程的示意图；

图6示出了本说明书另一实施例中应用间的依赖关系示意图；

图7示出了本说明书一些实施例中装置的结构框图；

图8示出了本说明书一些实施例中计算机设备的结构框图。

【附图标记说明】

71、告警信息获取模块；

72、故障应用定位模块；

73、故障点定位模块；

802、计算机设备；

804、处理器；

806、存储器；

808、驱动机构；

810、输入/输出接口；

812、输入设备；

814、输出设备；

816、呈现设备；

818、图形用户接口；

820、网络接口；

822、通信链路；

824、通信总线。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。

本说明书实施例涉及信息系统(例如银行系统等业务信息系统)故障定位技术。为便于描述在下文中将以银行系统为例进行说明。但是本领域技术人员可以理解，本说明书实施例的银行系统仅为示例性说明，不应理解为对本说明书实施例的限制，本说明书实施例的信息系统故障定位技术可以应用于其他任何合适的信息系统(例如电子商务平台系统等)。

为确保第一时间掌握信息系统的运行情况，及时发现信息系统故障，信息系统部署了多种监控措施。在基础设施(即IT基础设施)发生故障后，基于基础设施的操作系统、应用、交易都会同时发生告警，进而产生报警风暴。大量报警风暴同时产生后，短时间难以判断哪些是故障点，哪些是受影响点，如何从大量报警风暴中快速定位故障点已成为目前亟待解决的技术问题。

有鉴于此，本说明书实施例提供了一种信息系统故障定位方法，其可以应用于任何合适的计算机设备上，以实现信息系统故障定位。参考图1所示，在本说明书一些实施例中，所述信息系统故障定位方法可以包括以下步骤：

S101、获取应用层级的告警信息。

S102、根据预设的横向关系定位所述告警信息对应的故障应用；所述横向关系包括应用间的依赖关系。

S103、根据预设的纵向关系定位所述故障应用的故障点；所述纵向关系包括应用与基础设施的部署关系。

本说明书实施例中，可以预先生成应用间的依赖关系，以及应用与基础设施的部署关系；在此基础上，当获取到应用层级的告警信息后，可以根据依赖关系横向定位告警信息对应的故障应用，然后根据应用与基础设施的部署关系纵向定位故障应用的故障点，从而实现了可以在大量报警风暴中快速定位出故障点，提高了大量报警风暴场景下的故障点定位效率。

信息系统可部署有一个或多个应用。在很多情况下，这些应用之间可能并不是孤立的；换而言之，应用之间可以存在访问与被访问、调用与被调用等依赖关系。比如，当应用一的运行需要应用二提供数据为前提时，作为数据需求方的应用一，就产生了对作为数据提供方的应用二的依赖。一旦应用二出现故障，显然会对应用一产生影响，从而使得应用一也将产生告警，但实际应用一本身并无故障；但是，由于应用二的运行并不需要应用一提供数据，应用一出现故障一般并不会对应用一产生影响。

例如，在一示例性实施例中，银行系统可以部署有存款应用系统和贷款应用系统，当用户提交贷款申请时，为了核实用户是否满足可贷款条件(包括用户资产情况)，贷款应用系统可以向存款应用系统查询该用户在本行的存款余额信息。如此，若存款应用系统故障时，则会使得贷款应用系统无法查询该用户在本行的存款余额信息，从而也将产生告警。

因此，可以预先构建出信息系统的应用之间的依赖关系，以利于据此快速追溯应用故障点。在一些实施例中，可以从服务化数据平台等中获取每个应用的依赖数据，并据此形成应用间的依赖关系。例如，在一示例性实施例中，一个信息系统部署有应用A、应用B、应用C和应用D四个应用。其中，应用A的运行需要调用应用B的数据；应用B的运行需要调用应用C的数据；应用C的运行需要调用应用D的数据；应用D的运行均需要调用其他的应用。因此，根据这种调用关系，四个应用之间可以形成如图4或图5所示的依赖关系。例如，当应用C故障时，应用B和应用A将受影响。

应用的运行需要相应的基础设施(包括软件和硬件等)支持。本说明书实施例中的基础设施不仅包含物理设备(例如服务器设备、网络设备、存储设备等)，也包括在部署在这些物理设备上的操作系统、数据库等。因此，基础设施可以划分多个层级。例如，在一些实施例中，基础设施从底层至上层依次可以分为：物理设备级、操作系统级、数据库级和应用级。在另一些实施中，基础设施还可以涵盖中间件等应用服务程序，在此情况下，基础设施从底层至上层依次可以分为：物理设备级、操作系统级、数据库级、应用服务级和应用级(例如下表1所示)。

表1

基础设施层级	层级名称	层级内容
			Level1	物理设备级	网络、存储、服务器
Level2	操作系统级	操作系统
			Level3	数据库级	数据库
Level4	应用服务级	中间件及WEB
			Level5	应用级	应用、交易

各个层级基础设施之间存在部署关系，例如操作系统需要安装于物理设备上，数据库三维安装需要操作系统的支持，应用的部署同样需要操作系统和数据库的支持。当应用层级出现故障时，应用本身也可能并无故障，而是有可能是因为其所依赖的下层基础设施的故障而受影响。例如，当应用所依赖的数据库故障时，应用可能无法向数据库读写数据，从而也会产生告警，但实际上，应用本身并无故障。

鉴于不同层级的基础设施在发生故障时的影响范围一般不同，且越是底层的基础设施，其影响范围越大。因此，还可以预先构建出应用与基础设施的部署关系，以利于据此快速追溯应用故障点。在一些实施例中，可以预先从配置管理数据库(ConfigurationManagement Database，CMDB)等中获取应用与基础设施的部署关系。其中，部署关系中可以包含应用部署在哪些服务器设备上，数据传输经过哪些网络设备，数据存储在哪些存储设备，应用配置了哪些数据库，应用使用了何种操作系统等。

参考图2所示，在一些实施例中，所述根据预设的横向关系定位所述告警信息对应的故障应用可以包括以下步骤：

S201、根据所述告警信息对应的IP地址确认目标应用。

告警信息中包含有IP地址(或其他可以用标识应用的信息)，据此可以识别出应用，并可以将该应用作为初始的识别对象。

S202、确认所述横向关系中是否存在所述目标应用的依赖应用；当存在所述目标应用的依赖应用时执行步骤S203，否则跳转执行步骤S205。

由于横向关系中包含有目标应用在内各个应用之间的依赖关系，通过查询横向关系即可以判断出横向关系中是否存在所述目标应用的依赖应用。当目标应用的运行需访问或调用某个应用时，则该应用即为目标应用的依赖应用。例如，以图4或图5所示的横向关系为例，若获取的告警信息是应用A的告警信息，通过查询图4或图5所示的横向关系可以发现应用A依赖应用B，因此，可以确认应用A存在依赖应用，即应用A的依赖应用为应用B。

S203、确认所述依赖应用是否存在对应告警信息。当所述依赖应用存在对应告警信息时，执行步骤S204；否则跳转执行步骤S205。

步骤S204、当所述依赖应用存在对应告警信息时，当所述依赖应用作为新的目标应用，然后跳转执行步骤S202。

依赖应用存在对应告警信息是指：该依赖应用存在告警信息，该告警信息与目标应用的告警信息相关联，且两个告警信息的发生时间相近(例如发生时间的时间差在预设范围内)。例如，以图4或图5所示的横向关系为例，应用A的依赖应用为应用B，应用A在T1时间发生了有关于不能从外部访问参数X的告警M，应用B在T2时间发生了参数X采集模块故障的告警N，由于告警M和告警N均是有关于参数X的告警，且T1和T2的差值绝对值未超过预设的时间阈值，则可以认为应用B存在告警信息。

步骤S205、将当前的目标应用识别为故障应用，即识别出所有的存在对应告警信息且无依赖应用的应用。

若当前的目标应用的依赖应用也存在对应告警信息，表明当前的目标应用自身无故障，而是受到了其依赖应用故障的影响；因此当前的目标应用不是故障点，为了进一步追溯故障点，可以将当前的目标应用的依赖应用作为新的目标应用，从而有利于准确识别故障点。

例如，以图4或图5所示的横向关系为例，应用A的依赖应用为应用B，应用A在T1时间发生了有关于不能从外部访问参数X的告警M，应用B在T2时间发生了参数X采集模块故障的告警N，由于告警M和告警N均是有关于参数X的告警，且T1和T2的差值绝对值未超过预设的时间阈值，则可以认为应用B存在告警信息。因此，可以认为应用A自身无故障，而是受到了应用B故障的影响，因此应用A不是故障点，为了进一步追溯故障点，可以将应用B作为新的目标应用。

应当指出，一些应用场景下，横向关系可能并不会是如图4或图5所示那样的一条线，而可能存在分支。为了准确追溯故障点，当依赖关系存在分支时，对于每条分支均需要进行处理。例如，在一示例性实施例中，一个信息系统部署有应用A、应用B、应用C和应用D四个应用。其中，应用A的运行需要调用应用B和应用C的数据；应用C的运行需要调用应用D的数据；应用B和应用D的运行均不需要调用其他的应用。因此，根据这种调用关系，四个应用之间可以形成如图6所示的依赖关系。从图6中可以看出，整个依赖关系图包括两个分支，即应用A→应用B形成一个分支，应用A→应用C→应用D形成另一个分支。

参考图3所示，在一些实施例中，所述根据预设的纵向关系定位所述故障应用的故障点可以包括以下步骤：

S301、拉取所述故障应用在指定时间范围内的各条告警信息。

底层基础设施故障后向上层基础设施扩散或传播故障的过程会有一定的时间延迟，为了利于追溯故障应用的故障是由哪一层底层基础设施引起的，可以拉取所述故障应用在指定时间范围内的各条告警信息。其中的指定时间范围可以根据实际情况适当设置。

S302、根据所述各条告警信息在所述纵向关系中所归属的基础设施层级，对所述各条告警信息进行赋影响权值。

对于故障应用在指定时间范围内的每条告警信息，可以对根据其所归属的基础设施层级赋予不同的影响权值。影响权值越大表示对应告警信息的影响范围越大(或影响程度越高)。而基础设施层级越低，则其故障影响范围越大；因此，在本说明书实施例中，影响权值与基础设施层级负相关，即基础设施层级越高，影响权值越低；反之亦然。

S303、对所述各条告警信息的影响权值进行排序。

排序可以按照由大到小的顺序，也可以按照由小到大的顺序，本说明书实施例对此不作限定，具体可以根据需要选择。

S304、根据排序结果确定所述故障应用的故障点。

在本说明书实施例中，根据排序结果确定所述故障应用的故障点，将影响权值最大者对应的基础设施层级确定为所述故障应用的故障点，从而有利于进一步准确识别故障点。例如，以图5所示的纵向关系为例，基础设施层级由低至高依次为：物理设备级、操作系统级、数据库级、应用级，其对应的权值分别为：V1、V2、V3、V4，则V1～V4的大小关系为：V1>V2>V3>V4，即V1～V4按照由大到小的排序为：V1→V2→V3→V4。由于该排序结果中，V1为影响权值最大值，则可以将V1对应的故障层级作为故障应用的故障点，即应用D的物理设备故障是故障根源。

本领域技术人员可以理解，一些应用场景下，纵向关系也可能并不会是如图5所示那样的一条线，而可能存在分支。为了准确追溯故障点，当纵向关系存在分支时，对于每条分支也均需要进行处理。

虽然上文描述的过程流程包括以特定顺序出现的多个操作，但是，应当清楚了解，这些过程可以包括更多或更少的操作，这些操作可以顺序执行或并行执行(例如使用并行处理器或多线程环境)。

与上述的信息系统故障定位方法对应，本说明书实施例还提供了一种信息系统故障定位装置。参考图7所示，在本说明书一些实施例中，所述信息系统故障定位装置可以包括：

告警信息获取模块71，可以用于获取应用层级的告警信息；

故障应用定位模块72，可以用于根据预设的横向关系定位所述告警信息对应的故障应用；所述横向关系包括应用间的依赖关系；

故障点定位模块73，可以用于根据预设的纵向关系定位所述故障应用的故障点；所述纵向关系包括应用与基础设施的部署关系。

一些装置实施例中，所述根据预设的横向关系定位所述告警信息对应的故障应用，包括：

根据所述告警信息对应的IP地址确认目标应用；

确认所述横向关系中是否存在所述目标应用的依赖应用；

当存在所述目标应用的依赖应用时，确认所述依赖应用是否存在对应告警信息；

当所述依赖应用存在对应告警信息时，当所述依赖应用作为新的目标应用；

确认所述横向关系中是否存在所述新的目标应用的依赖应用；

以此递推，直至从所述横向关系中识别出所有的存在对应告警信息且无依赖应用的应用。

一些装置实施例中，所述根据预设的纵向关系定位所述故障应用的故障点，可以包括：

拉取所述故障应用在指定时间范围内的各条告警信息；

根据所述各条告警信息在所述纵向关系中所归属的基础设施层级，对所述各条告警信息进行赋影响权值；

对所述各条告警信息的影响权值进行排序；

根据排序结果确定所述故障应用的故障点。

一些装置实施例中，所述根据排序结果确定所述故障应用的故障点，可以包括：

将影响权值最大者对应的基础设施层级确定为所述故障应用的故障点。

一些装置实施例中，所述基础设施层级由低至高依次包括：

物理设备级、操作系统级、数据库级、应用级。

一些装置实施例中，所述影响权值与所述基础设施层级负相关。

一些装置实施例中，所述依赖关系可以包括调用关系。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本说明书实施例还提供一种计算机设备。如图8所示，在本说明书一些实施例中，所述计算机设备802可以包括一个或多个处理器804，诸如一个或多个中央处理单元(CPU)或图形处理器(GPU)，每个处理单元可以实现一个或多个硬件线程。计算机设备802还可以包括任何存储器806，其用于存储诸如代码、设置、数据等之类的任何种类的信息，一具体实施例中，存储器806上并可在处理器804上运行的计算机程序，所述计算机程序被所述处理器804运行时，可以执行上述任一实施例所述的信息系统故障定位方法的指令。非限制性的，比如，存储器806可以包括以下任一项或多种组合：任何类型的RAM，任何类型的ROM，闪存设备，硬盘，光盘等。更一般地，任何存储器都可以使用任何技术来存储信息。进一步地，任何存储器可以提供信息的易失性或非易失性保留。进一步地，任何存储器可以表示计算机设备802的固定或可移除部件。在一种情况下，当处理器804执行被存储在任何存储器或存储器的组合中的相关联的指令时，计算机设备802可以执行相关联指令的任一操作。计算机设备802还包括用于与任何存储器交互的一个或多个驱动机构808，诸如硬盘驱动机构、光盘驱动机构等。

计算机设备802还可以包括输入/输出接口810(I/O)，其用于接收各种输入(经由输入设备812)和用于提供各种输出(经由输出设备814)。一个具体输出机构可以包括呈现设备816和相关联的图形用户接口818(GUI)。在其他实施例中，还可以不包括输入/输出接口810(I/O)、输入设备812以及输出设备814，仅作为网络中的一台计算机设备。计算机设备802还可以包括一个或多个网络接口820，其用于经由一个或多个通信链路822与其他设备交换数据。一个或多个通信总线824将上文所描述的部件耦合在一起。

通信链路822可以以任何方式实现，例如，通过局域网、广域网(例如，因特网)、点对点连接等、或其任何组合。通信链路822可以包括由任何协议或协议组合支配的硬连线链路、无线链路、路由器、网关功能、名称服务器等的任何组合。

本申请是参照本说明书一些实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理器的处理器以产生一个机器，使得通过计算机或其他可编程数据处理器的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理器以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理器上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算机设备访问的信息。按照本说明书中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

本领域技术人员应明白，本说明书的实施例可提供为方法、系统或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理器来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

还应理解，在本说明书实施例中，术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系。例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

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

获取应用层级的告警信息；

根据预设的横向关系定位所述告警信息对应的故障应用；所述横向关系包括应用间的依赖关系；

根据预设的纵向关系定位所述故障应用的故障点；所述纵向关系包括应用与基础设施的部署关系。

2.如权利要求1所述的信息系统故障定位方法，其特征在于，所述根据预设的横向关系定位所述告警信息对应的故障应用，包括：

根据所述告警信息对应的IP地址确认目标应用；

确认所述横向关系中是否存在所述目标应用的依赖应用；

当存在所述目标应用的依赖应用时，确认所述依赖应用是否存在对应告警信息；

当所述依赖应用存在对应告警信息时，当所述依赖应用作为新的目标应用；

确认所述横向关系中是否存在所述新的目标应用的依赖应用；

以此递推，直至从所述横向关系中识别出所有的存在对应告警信息且无依赖应用的应用。

3.如权利要求1所述的信息系统故障定位方法，其特征在于，所述根据预设的纵向关系定位所述故障应用的故障点，包括：

拉取所述故障应用在指定时间范围内的各条告警信息；

根据所述各条告警信息在所述纵向关系中所归属的基础设施层级，对所述各条告警信息进行赋影响权值；

对所述各条告警信息的影响权值进行排序；

根据排序结果确定所述故障应用的故障点。

4.如权利要求3所述的信息系统故障定位方法，其特征在于，所述根据排序结果确定所述故障应用的故障点，包括：

将影响权值最大者对应的基础设施层级确定为所述故障应用的故障点。

5.如权利要求3所述的信息系统故障定位方法，其特征在于，所述基础设施层级由低至高依次包括：

物理设备级、操作系统级、数据库级、应用级。

6.如权利要求5所述的信息系统故障定位方法，其特征在于，所述影响权值与所述基础设施层级负相关。

7.如权利要求1所述的信息系统故障定位方法，其特征在于，所述依赖关系包括调用关系。

8.一种信息系统故障定位装置，其特征在于，包括：

告警信息获取模块，用于获取应用层级的告警信息；

故障应用定位模块，用于根据预设的横向关系定位所述告警信息对应的故障应用；所述横向关系包括应用间的依赖关系；

故障点定位模块，用于根据预设的纵向关系定位所述故障应用的故障点；所述纵向关系包括应用与基础设施的部署关系。

9.一种计算机设备，包括存储器、处理器、以及存储在所述存储器上的计算机程序，其特征在于，所述计算机程序被所述处理器运行时，执行根据权利要求1-7任意一项所述方法的指令。

10.一种计算机存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被计算机设备的处理器运行时，执行根据权利要求1-7任意一项所述方法的指令。

Images