CN114500249A

CN114500249A - 一种根因定位方法和装置

Info

Publication number: CN114500249A
Application number: CN202210400976.2A
Authority: CN
Inventors: 程鹏; 白佳乐; 任政; 郑杰
Original assignee: Industrial and Commercial Bank of China Ltd ICBC
Current assignee: Industrial and Commercial Bank of China Ltd ICBC
Priority date: 2022-04-18
Filing date: 2022-04-18
Publication date: 2022-05-13
Anticipated expiration: 2042-04-18
Also published as: CN114500249B

Abstract

本申请提供的一种根因定位方法和装置，通过获取第一标准日志，第一标准日志用于记录集群中的第一容器的事件信息，第一容器中运行有第一应用，事件信息包括报警信息；在容器历史报警库中不包含第一标准日志中的第一报警信息，且第一报警信息没有指示第一应用发生上下游接口调用故障的情况下，若第一报警信息指示第一容器发生故障，则将第一容器确定为故障容器，否则将第一应用确定为故障应用，容器历史报警库用于存储历史报警信息与故障类型之间的映射关系。由于利用配置管理数据库和日志报警信息进行节点定位，不但涵盖和满足大部分的云上报警节点定位，且实现了应用故障节点定位的高精度和快响应。

Description

一种根因定位方法和装置

技术领域

本申请涉及分布式技术，尤其涉及一种根因定位方法和装置。

背景技术

分布式云计算时代，随着应用的链路与节点日益增多，节点间的调用关系愈发复杂，当链路或者某个节点出现故障时往往出现许多节点同时报警，而准确找出故障节点对应用的稳定性及可用性具有重要意义。本领域中，找出故障节点也称为故障的根因定位。

目前业界根因定位主要依靠开发和运维人员进行人工分析，从大量的数据中找出故障或者报警的根本原因。

然而，这种方式需要运维人员具有丰富的经验，且当文件、数据数量较大时，人工分析的方式效率低下且易出错，因此亟需一种高效、准确的根因定位方法及装置。

发明内容

本申请提供一种根因定位方法和装置，用以解决现有技术中，分布式系统链路或节点出现报警时，无法快速、高效进行故障定位的技术问题。

第一方面，本申请提供一种根因定位方法，包括：

获取第一标准日志，第一标准日志用于记录集群中的第一容器的事件信息，第一容器中运行有第一应用，事件信息包括报警信息；在容器历史报警库中不包含第一标准日志中的第一报警信息，且第一报警信息没有指示第一应用发生上下游接口调用故障的情况下，若第一报警信息指示第一容器发生故障，则将第一容器确定为故障容器，否则将第一应用确定为故障应用，容器历史报警库用于存储历史报警信息与故障类型之间的映射关系。

本申请提供的根因定位方法，当容器历史报警库中不包含实时获取的第一报警信息时，通过判断第一报警信息是否是指上下游接口调用故障，如果不存在此种故障指示，且未指示容器故障，此种情况下可确定大概率是应用自身的故障，减少了不必要的回溯过程，这种方法加快了故障的根因定位速度；且利用配置管理数据库中预先设定的判定规则，能对故障原因进行进一步追究，提高了故障定位的精度。

在一种可能的实现方式中，该方法还包括：

若容器历史报警库中包含第一标准日志中的第一报警信息，则基于容器历史报警库确定第一报警信息对应的第一故障类型。

本申请提供的根因定位方法，通过利用容器历史报警库中已保存的故障信息，实现了故障类型的快速定位，有利于进一步实现故障的根因定位。

在一种可能的实现方式中，该方法还包括：

若第一故障类型不是上下游故障，且第一报警信息指示第一容器故障，则将第一容器确定为故障容器；若第一故障类型不是上下游故障，且第一报警信息没有指示第一容器故障，则将第一应用确定为故障应用。

本申请提供的根因定位方法，当故障类型不是上下游故障时，不再进行上下游的故障判定，进而判断是否为容器故障，若不是则可确定应用为故障节点，通过这种预判规则的设定，节约了资源，减少不必要的回溯过程，提升了故障定位的效率。

在一种可能的实现方式中，该方法还包括：

若第一故障类型是上下游故障，则获取第二标准日志，第二标准日志用于记录集群中的第二容器的事件信息，第二容器中运行有第二应用，第二应用为第一应用的上下游应用；在容器历史报警库中不包含第二标准日志中的第二报警信息，且第二报警信息没有指示第二应用发生上下游接口调用故障的情况下，若第二报警信息指示第二容器发生故障，则将第二容器确定为故障容器，否则将第二应用确定为故障应用；若容器历史报警库中包含第二报警信息，则基于容器历史报警库确定第二报警信息对应的第二故障类型；若第二故障类型不是上下游故障，且第二报警信息指示第二容器故障，则将第二容器确定为故障容器；若第二故障类型不是上下游故障，且第二报警信息没有指示第二容器故障，则将第二应用确定为故障应用。

本申请提供的根因定位方法，当故障类型指示为上下游故障时，通过对日志里调用信息的获取，回溯上下游的调用信息，可以实现故障的最终定位，提升了故障定位的精度。

在一种可能的实现方式中，该方法还包括：

若第一报警信息指示第一应用发生上下游接口调用故障，则获取第二标准日志，第二标准日志用于记录集群中的第二容器的事件信息，第二容器中运行有第二应用，第二应用为第一应用的上下游应用；在容器历史报警库中不包含第二标准日志中的第二报警信息，且第二报警信息没有指示第二应用发生上下游接口调用故障的情况下，若第二报警信息指示第二容器发生故障，则将第二容器确定为故障容器，否则将第二应用确定为故障应用；若容器历史报警库中包含第二报警信息，则基于容器历史报警库确定第二报警信息对应的第二故障类型；若第二故障类型不是上下游故障，且第二报警信息指示第二容器故障，则将第二容器确定为故障容器；若第二故障类型不是上下游故障，且第二报警信息没有指示第二容器故障，则将第二应用确定为故障应用。

本申请提供的根因定位方法，当容器历史报警库中不包含实时获取的第一报警信息，且指示上下游接口调用故障时，则获取日志的接口调用信息进行上下游的回溯，找到最初的调用故障节点，实现故障的最终定位，进一步提升了故障定位的精度。

在一种可能的实现方式中，该方法还包括：

获取集群中部署在同一个宿主机中的故障容器的第一数量；若第一数量超过宿主机中的容器的总数量的1/2，则确定宿主机为故障宿主机。

在一种可能的实现方式中，根据确定宿主机为故障宿主机后，该方法还包括：

获取部署在同一个集群中的故障宿主机的第二数量；若第二数量超过集群中的宿主机的总数量的1/2，则确定集群为故障集群。

在一种可能的实现方式中，该方法还包括：

获取集群中通过相同应用模板部署有相同故障应用的目标容器的第三数量；若第三数量超过使用应用模板部署有任意应用的容器的总数量的1/2，则确定应用模板为故障模板。

本申请提供的根因定位方法，当确定的故障节点中包含容器时，通过比对容器数量关系，判断故障原因是否为宿主机故障、集群故障或应用模板故障这样的环境问题，进一步提升了故障根因定位的准确性。

第二方面，本申请提供一种根因定位装置，包括：

处理模块：用于获取第一标准日志，第一标准日志用于记录集群中的第一容器的事件信息，第一容器中运行有第一应用，事件信息包括报警信息；

定位模块：用于在容器历史报警库中不包含第一标准日志中的第一报警信息，且第一报警信息没有指示第一应用发生上下游接口调用故障的情况下，若第一报警信息指示第一容器发生故障，则将第一容器确定为故障容器，否则将第一应用确定为故障应用，容器历史报警库用于存储历史报警信息与故障类型之间的映射关系。

第三方面，本申请提供一种电子设备，包括：处理器，以及与处理器通信连接的存储器；存储器存储计算机执行指令；处理器执行存储器存储的计算机执行指令，以实现第一方面的根因定位方法。

第四方面，本申请提供一种计算机可读存储介质，包括计算机可读存储介质中存储有计算机执行指令，计算机执行指令被处理器执行时用于实现第一方面的根因定位方法。

第五方面，本申请提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现第一方面的根因定位方法。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请一实施例提供的根因定位方法的场景示意图；

图2为本申请一实施例提供的根因定位方法的流程示意图；

图3为本申请一实施例提供的建立容器历史报警库的原理示意图；

图4为本申请一实施例提供的上下游故障的原理示意图；

图5为本申请一实施例提供的分布式系统中各组件间关系的结构示意图；

图6为本申请一实施例提供的根因定位装置的结构示意图；

图7为本申请一实施例提供的电子设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

图1为本申请的实施例的一种应用场景的示意图。如图1所示场景，分布式系统100包括服务器101、容器102和应用103。

其中，分布式系统100包括多个服务器101，每一个服务器101又包括一个或多个容器102，容器102是通过服务器101实现内核轻量级的操作系统层虚拟化，容器102可以运行应用103。

例如，分布式系统100中包括N个服务器，其中服务器1包括容器1和容器2，应用1运行在容器1中，其中服务器2包括容器3和容器4，应用2运行在容器2和容器3中，应用3运行在容器4中。

分布式系统100中的每个应用103都运行在对应的容器102中，各个应用103之间可以根据服务的需求互相调用，例如，应用N调用应用3，应用3调用应用2，应用2调用应用1，上述调用过程形成一条服务的调用链路；此时，应用N是应用3的上游调用应用，应用3是应用N的下游调用应用，应用3是应用2的上游调用应用，应用2是应用3的下游调用应用，应用2是应用1的上游调用应用，应用1是应用2的下游调用应用。

可以理解的是，图1中示出的分布式系统的架构方式仅是示例，本申请实施例的分布式系统的架构方式不限于此。

实际应用中，为了对每个服务的状态进行监控，当服务的质量下降时，将会向服务器上报报警事件。由于分布式系统中的一个服务往往涉及到多个应用间的调用，一个服务出现故障时，将导致多个应用的报警。对于分布式系统产生的大量报警事件来说，要快速寻找到故障节点，需要从中实现应用故障的根因定位。

目前，业界常用的根因定位方法是，拉取服务链路上报警时刻前特定时间内（例如五分钟）的报警事件，针对报警的类型及报警所处在链路上的位置统计分析其产生故障概率较高的节点，进而找出具体的故障节点。该种方式依赖较高的报警灵敏度，当出现漏报或误报时都会降低其故障根因定位的准确率和效率。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图2为本申请的实施例的一种故障的根因定位方法流程示意图。如图2所示，本申请的实施例的方法可以包括S201~S210。

该方法可以用于对图1所示的分布式系统中运行的服务所发生的故障进行根因定位。本申请实施例可以由图1所示分布式系统中的服务器执行，也可以由能够与图1中的服务器通信的其他服务器执行。

S201，获取第一标准日志，第一标准日志用于记录分布式系统中的第一容器的事件信息，第一容器中运行有第一应用，事件信息包括报警信息。

可以理解的是，第一容器中运行有应用，第一容器的事件信息可以包括应用的事件信息，因此第一容器的事件信息也可以称为应用的事件信息。

故障包括当链路或节点存在报警时最初发出报警信息的源点，其中，报警可以通过创建阈值报警规则，当监控项超过设定阈值后自动发送报警信息来实现。

可以理解的是，第一容器可以是第一服务器中包含的一个或多个容器中任意一个发生了报警事件的容器，第一服务器可以是分布式系统中包含的一个或多个服务器中部署第一容器的服务器。

第一应用可以是分布式系统中包含的一个或多个应用中任意一个发生了报警事件的应用。

容器的标准日志包括记录该容器中发生的事件的相关信息的日志。例如，容器中所发生的所有事件都可以留存在该容器的标准日志中。作为一种示例，标准日志可以包括容器的报警信息和应用的接口调用信息，其中，容器的报警信息可以是容器中发生的报警事件的信息，应用的接口调用信息可以包括应用与其所调用的下游应用之间的接口信息，和/或，该应用与调用该应用的上游应用之间的接口信息。

在一种可能的实现方式中，第一服务器可以实时获取链路或节点的报警信息。第一服务器接收到报警信息后，获取第一容器的标准日志，从而可以获知第一容器中发生的事件信息。

其中，第一服务器获取报警信息时，可以使用本领域中常用的监控方式。例如，第一服务器可以使用“Heapster”插件、“Prometheus”方式获取报警信息，此处不再赘述。

S202，判断容器历史报警库中是否包含第一标准日志中的第一报警信息，容器历史报警库用于存储历史报警信息与故障类型之间的映射关系。若存在，则执行S203；若不存在，则执行S207。

作为一种示例，可以获取分布式系统中的容器、应用以及链路的历史标准日志，并从该历史标准日志中获取历史报警信息，并分析该历史报警信息所对应的故障类型，然后建立历史报警信息与故障类型之间的映射关系，从而得到容器历史报警库。其中，不同的历史报警信息可以对应不同的故障类型。

例如，不同的故障类型可以包括如下类型中一种或多种：应用自身配置故障、程序故障和上下游故障。

下面结合图3介绍容器历史报警库的一种建立方法。如图3所示，分布式系统300中的服务器302中的容器S1发生了报警事件，相应地，在容器S1的标准日志中记录该报警事件发生时生成的报警信息。

然后，获取容器S1的标准日志中得到报警信息，并对容器S1进行故障分析，得到故障类型，并建立该报警信息与该故障类型之间的映射关系。一个或多个映射关系构成容器历史报警库。

例如，技术人员对容器S1进行故障分析，得知容器S1中的报警事件是因为容器S1中的应用F1发生代码故障而发生的。这种情况下，可以建立该报警信息与应用代码故障之间的映射关系。

又如，技术人员对容器S1进行故障分析，得知容器S1中的报警事件是因为容器中的应用发生配置问题而发生的。这种情况下，可以建立该报警信息与应用配置故障之间的映射关系。

再如，技术人员对容器S1进行故障分析，得知容器S1中的报警事件是因为容器中的应用调用下游应用的接口发生问题而发生的。这种情况下，可以建立该报警信息与上游应用接口故障之间的映射关系。

或者，技术人员对容器S1进行故障分析，得知容器S1中的报警事件是因为容器中的应用的上游应用调用该应用的接口发生问题而发生。这种情况下，可以建立该报警信息与下游应用接口故障之间的映射关系。

S203，基于容器历史报警库确定第一报警信息对应的第一故障类型。

作为示例，将容器历史报警库中与第一报警信息具有映射关系的故障类型确定为第一故障类型。

例如，容器历史报警库中与第一报警信息具有映射关系的故障类型为应用代码故障类型时，第一故障类型为应用代码故障类型。

S204，判断第一故障类型是否为上下游故障，上下游故障包括上游故障或下游故障，上游故障包括第一应用的上游应用导致的故障，下游故障包括第一应用的下游导致的故障。若为上下游故障，则执行S205，否则执行S206。

作为示例，下面结合图4对上下游故障进行介绍。如图4所示，应用X1调用应用X2，应用X2调用应用X3，应用X2为第一应用。第一故障类型包括上游故障，表示第一报警信息是因为应用X1所引发的报警事件的信息；第一故障类型包括下游故障，表示第一报警信息是因为应用X3所引发的报警事件的信息。

S205，将第一应用更新为第一应用的上下游应用，重新从S201开始执行。

可以理解得是，第一应用更新之后，第一容器、第一服务器、第一报警信息和第一故障类型都需要随之更新。

S206，判断第一报警信息是否指示第一容器故障。若为第一容器故障，则执行S209，否则执行S208。

S207，判断第一报警信息是否指示第一应用发生上下游接口调用故障，上下游接口调用故障包括上游接口调用故障或下游接口调用故障，上游接口调用故障包括第一应用的上游应用调用第一应用失败，下游接口调用故障包括第一应用调用下游的应用失败。若为上下游接口调用故障，则执行S205，否则执行S206。

S208，将第一应用确定为故障应用。

可选地，本实施例中还可以包括：将第一故障类型确定为第一应用发生的故障。

S209，将第一容器确定为故障容器。

可选地，本实施例中还可以包括：将第一故障类型确定为第一容器发生的故障。

S210，根据故障容器的数量确定故障原因。

作为示例，判断容器的故障节点数量是否满足预设规则，预设规则存储在配置管理数据库中，若满足预设规则要求，则确定是环境问题。

预设规则是技术人员预先设定并存储至配置管理数据中，判断故障是否由环境问题所导致的判定条件。

例如，服务器确定故障容器后，根据分布式系统的配置管理数据库中组件间的运行关系信息，若任一宿主机中容器的故障节点数超过该宿主机中总容器数量的1/2，则确定该宿主机出现故障。

又如，服务器确定故障容器后，根据分布式系统的配置管理数据库中组件间的运行关系信息，若任一模板对应运行的容器的故障节点数超过该模板对应运行的容器总数量的1/2，则确定该模板出现故障。其中，应用通过模板部署运行在容器中，模板包括运行环境参数信息。

再如，服务器确定故障容器后，根据分布式系统的配置管理数据库中组件间的运行关系信息，若任一集群中宿主机的故障数量超过该集群宿主机总数量的1/2，则确定该集群出现故障。

配置管理数据库包括分布式系统中各组件间对应运行关系的信息。例如，分布式系统中每一个服务器上运行多个容器，这些运行在该服务器上的容器与该服务器存在对应运行关系。

作为示例，分布式系统中可以包括多个集群、多个服务器和配置管理数据库，其中服务器可以包括宿主机。容器、应用、宿主机和集群的信息以及这些组件间的对应运行关系信息会存储在配置管理数据库中，服务器可以从配置管理数据库中获取到这些关系信息。

下面结合图5介绍分布式系统中各组件间关系信息的存储方法。如图5所示，包括集群Q1、宿主机K1、宿主机K2、容器R1、容器R2、容器R3、容器R4、容器R5、容器R6、应用A1、模板D1、模板D2和模板D3。

其中，容器R1、容器R2和容器R3对应运行在宿主机K1上，容器R4、容器R5和容器R6对应运行在宿主机K2上，宿主机K1和宿主机K2对应运行在集群Q1上。

其中，应用A1运行在容器R1和容器R2上，应用A1运行在容器R4和R6上。容器R1和容器R2对应的部署环境为模板D1，容器R4和容器R6对应的部署环境为模板D3。

此时，配置管理数据库可以获取并存储上述各组件间的对应运行关系。

可以理解的是，图5所示的配置管理数据库登记的组件间关系仅是示例，在实际应用场景中可以存在多个集群，集群内包括多个宿主机，宿主机存在多个容器，应用存在多个模板，应用通过模板部署运行在多个容器中。

本申请实施例中，通过事先建立容器历史报警库的方式将过往历史中存在的报警信息进行分析并分类存储，当出现报警信息时，优先将该包含报警信息的日志与容器历史报警库中的报警数据进行比对，有效减少回溯过程，加快故障节点的根因定位。特别的，当存在多个报警信息时，优先进行容器历史报警库的报警信息比对，进行已有报警信息的故障节点定位后，可以集中资源对不在容器历史报警数据库的故障进行根因定位，极大提高了整体的故障节点的定位效率。

与此同时，当容器历史报警库不包括该报警信息时，若应用日志中不存在上下游报警，则确定大概率是应用自身的故障，从而加快了故障根因定位的速度。最后，基于配置管理数据库的信息及容器故障数据，判断是否为环境问题导致的故障，进一步提高了故障定位的精度。

本申请利用配置管理数据库和日志报警信息进行节点定位，不但涵盖和满足大部分的云上报警节点定位，实现了应用故障节点定位的高精度和快响应。

还一种可能实现的方式是，若获取到的报警信息不存在于容器历史报警数据库中，执行上述S201~S210步骤，直至找到故障节点后，将该报警信息与故障类型之间的映射关系存入容器历史报警库中。

本申请实施例中，通过存储此前不存在于容器历史报警库中的报警信息，当此后再出现该类报警事件时，可以直接定位故障类型，加快故障的根因定位速度。

图6为本申请实施例提供的故障的根因定位装置结构示意图。如图6所示，该根因定位装置600包括：处理模块601、定位模块602。其中：

处理模块601，用于获取第一标准日志，第一标准日志用于记录分布式系统中的第一容器的事件信息，第一容器中运行有第一应用，事件信息包括报警信息；判断容器历史报警库中是否包含第一标准日志中的第一报警信息，容器历史报警库用于存储历史报警信息与故障类型之间的映射关系；若容器历史报警库中不包含第一标准日志中的第一报警信息，则判断第一报警信息是否指示第一应用发生上下游接口调用故障；若第一报警信息没有指示第一应用发生上下游接口调用故障，则判断第一报警信息是否指示第一容器故障。

定位模块602，用于若第一报警信息指示第一容器故障，则将第一容器确定为故障容器，否则，将第一应用确定为故障应用；根据故障容器的数量确定故障原因。

可以理解的是，本申请实施例提供的故障的根因定位装置，可用于执行如上任一方法实施例的技术方案，其实现原理和技术效果类似，具体可参考上述方法实施例，此处不再赘述。

图7为本申请实施例提供的电子设备的结构示意图。如图7所示，本申请提供的电子设备可以包括：

存储器701、处理器702即存储在存储器701上并可在处理器702上运行的根因定位程序；

根因定位程序被处理器702执行时实现如前述任一实施例的根因定位方法的步骤。

可选地，存储器701既可以是独立的，也可以是跟处理器702集成在一起。

本实施例提供的电子设备的实现原理和技术效果可以参见前述各实施例，此处不再赘述。

本申请实施例还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现如前述任一实施例提供的根因定位方法的步骤。

在本发明提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器执行本发明各个实施例方法的部分步骤。

应理解，上述处理器可以是中央处理单元（Central Processing Unit，简称CPU），还可以是其它通用处理器、数字信号处理器（Digital Signal Processor，简称DSP）、专用集成电路（Application Specific Integrated Circuit，简称ASIC）等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（SRAM），电可擦除可编程只读存储器（EEPROM），可擦除可编程只读存储器（EPROM），可编程只读存储器（PROM），只读存储器（ROM），磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits，简称ASIC)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备或主控设备中。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质（如ROM/RAM、磁碟、光盘）中，包括若干指令用以使得一台终端设备（可以是手机，计算机，服务器，空调器，或者网络设备等）执行本发明各个实施例的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求书指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

Claims

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

获取第一标准日志，所述第一标准日志用于记录集群中的第一容器的事件信息，所述第一容器中运行有第一应用，所述事件信息包括报警信息；

在容器历史报警库中不包含所述第一标准日志中的第一报警信息，且所述第一报警信息没有指示所述第一应用发生上下游接口调用故障的情况下，若所述第一报警信息指示所述第一容器发生故障，则将所述第一容器确定为故障容器，否则将所述第一应用确定为故障应用，所述容器历史报警库用于存储历史报警信息与故障类型之间的映射关系。

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

若所述容器历史报警库中包含所述第一标准日志中的第一报警信息，则基于所述容器历史报警库确定所述第一报警信息对应的第一故障类型。

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

若所述第一故障类型不是上下游故障，且所述第一报警信息指示所述第一容器故障，则将所述第一容器确定为故障容器；

若所述第一故障类型不是上下游故障，且所述第一报警信息没有指示所述第一容器故障，则将所述第一应用确定为故障应用。

4.根据权利要求3所述的根因定位方法，其特征在于，所述方法还包括：

若所述第一故障类型是上下游故障，则获取第二标准日志，所述第二标准日志用于记录集群中的第二容器的事件信息，所述第二容器中运行有第二应用，所述第二应用为所述第一应用的上下游应用；

在所述容器历史报警库中不包含所述第二标准日志中的第二报警信息，且所述第二报警信息没有指示所述第二应用发生上下游接口调用故障的情况下，若所述第二报警信息指示所述第二容器发生故障，则将所述第二容器确定为故障容器，否则将所述第二应用确定为故障应用；

若所述容器历史报警库中包含所述第二报警信息，则基于所述容器历史报警库确定所述第二报警信息对应的第二故障类型；

若所述第二故障类型不是上下游故障，且所述第二报警信息指示所述第二容器故障，则将所述第二容器确定为故障容器；

若所述第二故障类型不是上下游故障，且所述第二报警信息没有指示所述第二容器故障，则将所述第二应用确定为故障应用。

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

若所述第一报警信息指示所述第一应用发生上下游接口调用故障，则获取第二标准日志，所述第二标准日志用于记录集群中的第二容器的事件信息，所述第二容器中运行有第二应用，所述第二应用为所述第一应用的上下游应用；

6.根据权利要求1所述的根因定位方法，其特征在于，所述方法包括：

获取所述集群中部署在同一个宿主机中的故障容器的第一数量；

若所述第一数量超过所述宿主机中的容器的总数量的1/2，则确定所述宿主机为故障宿主机。

7.根据权利要求6所述的根因定位方法，其特征在于，所述方法还包括：

获取部署在同一个集群中的故障宿主机的第二数量；

若所述第二数量超过所述集群中的宿主机的总数量的1/2，则确定所述集群为故障集群。

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

获取所述集群中通过相同应用模板部署有相同故障应用的目标容器的第三数量；

若所述第三数量超过使用所述应用模板部署有任意应用的容器的总数量的1/2，则确定所述应用模板为故障模板。

9.一种根因定位装置，其特征在于，包括：

处理模块：用于获取第一标准日志，所述第一标准日志用于记录集群中的第一容器的事件信息，所述第一容器中运行有第一应用，所述事件信息包括报警信息；

定位模块：用于在容器历史报警库中不包含所述第一标准日志中的第一报警信息，且所述第一报警信息没有指示所述第一应用发生上下游接口调用故障的情况下，若所述第一报警信息指示所述第一容器发生故障，则将所述第一容器确定为故障容器，否则将所述第一应用确定为故障应用，所述容器历史报警库用于存储历史报警信息与故障类型之间的映射关系。

10.一种电子设备，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现如权利要求1-8中任一项所述的根因定位方法。