CN115145751A - 微服务系统故障根因定位方法、装置、设备及存储介质 - Google Patents

微服务系统故障根因定位方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN115145751A
CN115145751A CN202110349350.9A CN202110349350A CN115145751A CN 115145751 A CN115145751 A CN 115145751A CN 202110349350 A CN202110349350 A CN 202110349350A CN 115145751 A CN115145751 A CN 115145751A
Authority
CN
China
Prior art keywords
suspicious
chain
fault
abnormal
call
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110349350.9A
Other languages
English (en)
Inventor
何川
刘德卫
林帆
向麒麟
龚胜芳
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Innovation Co
Original Assignee
Alibaba Singapore Holdings Pte Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Singapore Holdings Pte Ltd filed Critical Alibaba Singapore Holdings Pte Ltd
Priority to CN202110349350.9A priority Critical patent/CN115145751A/zh
Publication of CN115145751A publication Critical patent/CN115145751A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本公开实施例涉及微服务系统故障根因定位方法、装置、设备及存储介质。本公开的至少一个实施例中，基于代码仓库的数据和监控平台的数据，引入方法故障传播链，来表征某一个方法修改可能引入的故障的传播轨迹，以提升故障根因定位结果的可解释性。另一方面，通过对监控平台的数据进行预处理，可得到微服务系统运行时异常方法调用链，进而基于方法故障传播链和异常方法调用链集，确定故障根因信息，包括可疑方法，实现将故障根因信息定位到方法级别，另外，故障根因信息还可包括可疑提交记录信息，实现可疑方法和可疑提交记录信息关联，缩短代码变更场景下的故障排查时间。

Description

微服务系统故障根因定位方法、装置、设备及存储介质
技术领域
本公开实施例涉及计算机技术领域，具体涉及一种微服务系统故障根因定位方法、装置、电子设备及非暂态计算机可读存储介质。
背景技术
传统单体系统的故障根因定位，可以使用基于增量调试、切片、频谱、程序状态分析以及机器学习等方法来进行，这些方法可以定位导致系统故障的疑似方法和代码。而微服务系统具有高度的动态性和复杂性，每一个微服务可能包含多个实例。根据调度需求，每一个微服务的多个实例会在不同容器或虚拟机中被动态地创建和销毁。此外，微服务间往往包含复杂的调用链，每条调用链可能会被调用成千上万次，这些调用链中通常还包含一些异步调用。以上的诸多因素，使得传统单体系统的故障根因定位方法难以有效地运用到微服务系统中。
微服务系统中的故障类型，主要包含系统级资源类型故障(如CPU、Memory占用率过高等)和应用级业务类型故障(如空指针、参数传递错误引发的解析异常等)。
对于系统级资源类型故障，有研究者提出可以使用调用链比对和机器学习等方法来进行定位。前者将线上的异常调用链与历史的异常调用链进行比对，以得出疑似故障根因的微服务。后者通过故障注入，分析故障发生时系统的服务级调用链，训练机器学习模型，来预测生产系统中疑似故障的根因位置(服务级)。这些方法目前都只针对系统级资源类型故障，同时只能将故障根因定位到服务级(即定位哪个服务出现故障)，无法深入到方法级(即定位哪个服务所调用的哪个方法出现故障，一个服务通常调用多个方法(方法实质为代码或函数)来提供服务)，也无法与提交记录信息(Commit信息)进行关联。
对于应用级业务类型故障，故障种类繁多，通过枚举式的故障注入往往只能覆盖一小部分故障种类。现有的基于增量调试、切片、频谱和程序状态分析等故障根因定位方案，往往只能针对某一个特定的微服务，而微服务系统中跨服务调用十分频繁，单纯应用这些方案会丢失重要的上下文信息。而基于机器学习的方案，由于其解释性相对较差，当准确性不高时，其结果会使用户难以接受。
上述对问题的发现过程的描述，仅用于辅助理解本公开的技术方案，并不代表承认上述内容是现有技术。
发明内容
为了解决现有技术存在的至少一个问题，本公开的至少一个实施例提供了一种微服务系统故障根因定位方法、装置、电子设备及非暂态计算机可读存储介质。
第一方面，本公开实施例提出一种微服务系统故障根因定位方法，所述方法包括：
获取代码数据、第一提交记录信息集、应用日志和方法调用链集；
基于代码数据、第一提交记录信息集、应用日志和方法调用链集，确定方法故障传播链集；
识别方法调用链集中的异常方法调用链；
基于应用日志和异常链路聚合条件对识别的异常方法调用链进行聚合，得到一个或多个异常方法调用链集；
基于方法故障传播链集和异常方法调用链集，确定故障根因信息，故障根因信息包括可疑方法。
在一些实施例中，代码数据和第一提交记录信息集来源于代码仓库；监控平台的数据包括：应用日志和方法调用链集来源于监控平台；微服务系统包括代码仓库和监控平台。
在一些实施例中，基于代码数据、第一提交记录信息集、应用日志和方法调用链集，确定方法故障传播链集包括：
对代码数据进行静态扫描，确定方法间的间接依赖关系；
基于第一提交记录信息集，确定修改方法集和每个修改方法对应的第二提交记录信息集；
基于方法调用链集、间接依赖关系、修改方法集和每个修改方法对应的第二提交记录信息集，确定方法故障传播链集。
第二方面，本公开实施例还提出一种微服务系统故障根因定位装置，包括：
获取模块，用于获取代码数据、第一提交记录信息集、应用日志和方法调用链集；
故障传播链确定模块，用于基于代码数据、第一提交记录信息集、应用日志和方法调用链集，确定方法故障传播链集；
异常调用链确定模块，用于识别方法调用链集中的异常方法调用链；基于应用日志和异常链路聚合条件对识别的异常方法调用链进行聚合，得到一个或多个异常方法调用链集；
故障根因定位模块，用于基于方法故障传播链集和异常方法调用链集，确定故障根因信息，故障根因信息包括可疑方法。
第三方面，本公开实施例还提出一种电子设备，包括：处理器和存储器；所述处理器通过调用所述存储器存储的程序或指令，用于执行如第一方面所述微服务系统故障根因定位方法的步骤。
第四方面，本公开实施例还提出一种非暂态计算机可读存储介质，用于存储程序或指令，所述程序或指令使计算机执行如第一方面所述微服务系统故障根因定位方法的步骤。
可见，本公开的至少一个实施例中，基于代码仓库的数据和监控平台的数据，引入方法故障传播链，来表征某一个方法修改可能引入的故障的传播轨迹，以提升故障根因定位结果的可解释性。另一方面，通过对监控平台的数据进行预处理，可得到微服务系统运行时异常方法调用链，进而基于方法故障传播链和异常方法调用链集，确定故障根因信息，包括可疑方法，实现将故障根因信息定位到方法级别，另外，故障根因信息还可包括可疑提交记录信息，实现可疑方法和可疑提交记录信息关联，缩短代码变更场景下的故障排查时间。
本公开的至少一个实施例中，通过结合微服务系统运行时的方法调用链，进一步细粒度化地追溯每一次业务请求的方法执行轨迹。通过将微服务系统运行时异常方法调用链中的异常方法与方法故障传播链进行比对，得到可疑方法集，同时计算每个可疑方法的可疑率，以此得出可疑的故障根因。最后，通过分析可疑方法的所有Commit信息，来寻找可能导致故障的一部分Commit信息，以此将可疑方法与Commit信息关联起来，缩短代码变更场景下的故障排查时间。
附图说明
为了更清楚地说明本公开实施例的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1是本公开实施例提供的一种示例性应用场景图；
图2是本公开实施例提供的一种故障根因定位装置的示例性框图；
图3是本公开实施例提供的一种故障根因定位模块的示例性框图；
图4是本公开实施例提供的一种电子设备的示例性框图；
图5是本公开实施例提供的一种微服务系统故障根因定位方法的示例性流程图；
图6是本公开实施例提供的另一种微服务系统故障根因定位方法的示例性流程图；
图7是本公开实施例提供的一种确定间接故障传播链集的示例性流程图；
图8是本公开实施例提供的一种确定直接故障传播链集的实例性流程图；
图9是本公开实施例提供的一种确定异常方法调用链集的示例性流程图；
图10是本公开实施例提供的一种输出可疑方法的示例性流程图；
图11是本公开实施例提供的一种输出可疑方法的可疑Commit集的示例性流程图。
具体实施方式
为了能够更清楚地理解本公开的上述目的、特征和优点，下面结合附图和实施例对本公开作进一步的详细说明。可以理解的是，所描述的实施例是本公开的一部分实施例，而不是全部的实施例。此处所描述的具体实施例仅仅用于解释本公开，而非对本公开的限定。基于所描述的本公开的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本公开保护的范围。
需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
为了便于理解本公开实施例的方案，对本公开实施例涉及的名词进行如下解释：
方法依赖：描述方法间的依赖关系，主要包含直接依赖和间接依赖两种。直接依赖是指不同的方法之间存在调用与被调用的关系，这些方法在一条方法调用链上。间接依赖是指不同的方法通过访问某些共享状态(共享状态包括但不限于全局变量、缓存和数据库)形成的依赖，比如两个方法都访问了同一个全局变量、缓存或数据库，这些方法不在同一条方法调用链上。
故障传播：系统大部分的故障是由代码(方法)修改引入的。当系统中某个服务的方法被修改时，可能会引入故障。该修改引入的故障可能会影响到上下游与该方法有直接依赖的其他方法，故障影响上游的方法称为故障反向传播，故障影响下游的方法称为故障正向传播。此外，该修改引入的故障可能会影响到与该方法有间接依赖关系的其他方法，称为故障间接传播。
方法故障传播链：描述方法修改引入的故障的传播轨迹，分为直接依赖故障传播链和间接依赖故障传播链，链头方法为修改方法(也即修改后的方法)。直接依赖故障传播链包含两种：由故障正向传播形成的传播链和故障反向传播形成的传播链。间接依赖故障传播链则主要是由故障间接传播形成的传播链。
方法调用链：传统的调用链是以微服务为统计粒度，统计微服务间的调用关系。方法级分布式调用链将统计粒度进一步细化到方法，例如，统计到一条调用链(Trace)经过的不同微服务的所有方法，并且反映了每一个方法调用情况，包含调用是否成功、失败时的故障类型等信息。
Commit信息：在开发人员使用代码版本控制系统过程中，每次向中央代码仓库提交代码时，系统会生成一条提交记录信息，称为Commit信息。一个文件可以被修改多次，每次提交产生一条Commit信息，一条Commit信息可以修改多个文件，每个文件包括一个或多个方法。
故障根因：故障的根源或根本原因。
下面描述现有技术中的六个故障根因定位方案。
故障根因定位方案一
针对单体系统，采用二次定位策略来定位故障。第一次定位可能含有故障的函数(即方法)，第二次定位函数中的故障代码行(即故障语句)。由于单体系统与微服务系统存在本质差别，单体系统的故障根因定位方案无法直接应用到微服务系统。
故障根因定位方案二
针对微服务系统，以方法为粒度，通过分析执行轨迹差异来定位引发故障的方法调用。但是这种故障根因定位方案定位的只是发生故障的方法调用，链路轨迹的差异处很可能不是故障的根因所在，因此无法将故障根因真正定位方法级(即定位哪个服务所调用的哪个方法出现故障)。
故障根因定位方案三
针对微服务系统，采用面向异常传播的微服务智能监测方案，但是异常传播链节点为微服务而不是方法，所以故障根因只能定位到服务级别(或者是服务入口API级别)，也即故障根因只能定位到某个微服务，无法将故障根因真正定位方法级。
故障根因定位方案四
针对微服务系统，采用离线训练和在线预测两个部分。这种故障根因定位方案为了得到训练数据，需要编写大量测试用例来收集大量的微服务级调用链数据(即执行轨迹日志)，而且故障根因只能定位到服务级，无法将故障根因真正定位方法级。
故障根因定位方案五
针对单体系统，采用将错误预防和解决技术相结合的方案，分为两个阶段：第一阶段包括建立一个基于度量的模型，以评估传入Git库的Commit是否有引发风险的可能性。第二阶段将第一阶段存在可疑风险的代码块与已知的历史错误提交和解决方法进行比较。由于单体系统与微服务系统存在本质差别，单体系统的故障根因定位方案无法直接应用到微服务系统，例如，微服务系统中建立通用的度量指标和动态的阈值范围往往比较困难。
故障根因定位方案六
针对微服务系统，采用针对性能故障的根因定位方案MicroRCA(Root CauseLocalization of PerformanceIssues in Microservices)，主要用于定位响应延迟、CPU占用和内存泄漏这三种异常，且只能定位到服务级别，无法将故障根因真正定位方法级。
本公开实施例提供了一种微服务系统故障根因定位方法、装置、电子设备及非暂态计算机可读存储介质。本公开的至少一个实施例中，对于微服务系统中线上的异常方法调用链路，将故障根因定位到方法，同时将方法与Commit信息进行关联，筛选出最可能引入缺陷、导致微服务系统故障的相关Commit信息。本公开的至少一个实施例中，通过引入方法故障传播链，来表征某一个方法修改可能引入的故障的传播轨迹，以提升故障根因定位结果的可解释性。本公开的至少一个实施例中，通过结合微服务系统运行时的方法调用链，进一步细粒度化地追溯每一次业务请求的方法执行轨迹。本公开的至少一个实施例中，通过将微服务系统运行时异常方法调用链中的异常方法与方法故障传播链进行比对，得到可疑方法集，同时计算每个可疑方法的可疑率，以此得出可疑的故障根因。本公开的至少一个实施例中，通过分析可疑方法的所有Commit信息，来寻找可能导致故障的一部分Commit信息，以此将可疑方法与Commit信息关联起来，缩短代码变更场景下的故障排查时间。
相比故障根因定位方案一、方案四需要编写大量测试用例。本公开实施例提供的微服务系统故障根因定位方案，通过使用日志信息、微服务系统运行时跨服务的方法调用链路和代码静态扫描，来获取跨服务的方法依赖关系和执行情况，避免编写大量的测试用例。
相比故障根因定位方案一、方案五主要针对单体系统，由于微服务系统需要更高覆盖度的测试用例，同时微服务系统的故障可能在运行时跨服务传播，导致这两种方案难以较好地应用到微服务系统中。本公开实施例提供的微服务系统故障根因定位方案，通过使用微服务系统运行时跨服务的方法调用链路，来描述跨服务的方法依赖关系和执行情况，对于微服务系统的应用有较好的支持。
相比故障根因定位方案三、方案四主要针对微服务系统，但故障根因定位结果为服务级。本公开实施例提供的微服务系统故障根因定位方案，通过使用方法故障传播链和微服务系统运行时的方法调用链，来描述方法的依赖关系和执行情况，能够将故障根因定位到方法级。
相比故障根因定位方案二定位的结果为故障的发生点，而不是故障的根因点。例如，微服务A调用微服务B来获取数据c，进而基于数据c调用微服务C，若微服务B的方法进行了修改，可能获取的数据c错误，进而导致基于数据c调用微服务C时，微服务C报错，方案二只能定位到故障的发生点(微服务C)，而无法定位到故障根因(微服务B)。本公开实施例提供的微服务系统故障根因定位方案，通过使用跨服务的方法故障传播链，来描述故障根因和故障传播轨迹，使得所定位的结果即为故障根因。
相比故障根因定位方案二、方案五需要积累大量的历史故障样本来提升方案的准确性。本公开实施例提供的微服务系统故障根因定位方案，通过使用微服务系统运行时的方法调用链，来表征跨服务的方法依赖关系和执行情况，不需要积累大量的历史故障样本。
相比故障根因定位方案四使用机器学习的方案，对于故障根因定位的结果，其可解释性很差。本公开实施例提供的微服务系统故障根因定位方案，通过使用跨服务的方法故障传播链，来描述故障根因和故障传播轨迹，使得每一个定位结果都具备较高的可解释性。
相比故障根因定位方案一、二、三、四、六均不能将故障根因定位结果关联到Commit信息。本公开实施例提供的微服务系统故障根因定位方案，通过日志信息、跨服务的方法故障传播链和微服务系统运行时的方法调用链，首先将故障根因定位到方法级，然后通过分析该方法的Commit信息，筛选出可能导致本次故障的一部分Commit信息，完成故障根因关联到Commit信息。
相比故障根因定位方案六使用图谱的方案，主要针对系统资源类型的故障，不能定位应用级业务类型故障。本公开实施例提供的微服务系统故障根因定位方案，通过使用跨服务的方法故障传播链，来描述故障根因和故障传播轨迹，从而可以定位到业务类型的方法级故障根因信息。
本公开实施例可以应用于任意微服务系统中，其中，微服务系统可以根据不同的业务类型进行配置，微服务系统的配置属于本领域的成熟技术，在此不再赘述。由于不同微服务系统可以针对不用的业务，因此，本公开实施例可以应用于不同的业务场景中，例如网上购物场景。应当理解的是，本公开实施例的应用场景仅仅是本公开的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以将本公开应用于其他类似情景。
图1为本公开实施例提供的一种示例性应用场景图。如图1所示，该应用场景中包括：代码仓库10、监控平台11、故障根因定位设备12和其他与微服务系统相关的设备。图1可以理解为微服务系统或微服务系统的一部分。
在一些实施例中，用户发起一个业务请求，例如用户网上购物时点击了下单按钮，会发起一个下单请求。这个业务请求在微服务系统中会经过多个微服务的处理，而每个微服务会使用一个或多个方法(可以理解为函数或代码)。
例如，这个下单请求会经过行为判断服务、库存服务、订单服务等微服务的处理，也即用户点击了下单按钮，会调用这些微服务。其中，行为判断服务用于判断用户本次的点击是否合法，并在判定不合法时给出提示信息，例如用户短时间内多次点击，行为判断服务会提示用户不要多次下单。库存服务用于查找产品的库存数量是否满足用户下单的产品数量。订单服务用于生成订单信息，订单信息中包括用户ID、产品ID、产品数量、价格、用户地址、商家地址、联系方式等。
每个微服务会使用一个或多个方法。对于web架构的微服务，通常采用分层设计，例如三层设计包括：表示层、业务逻辑层、数据访问层，其中，表示层对应前端用户界面(User Interface，UI)。那么每层会对应至少一个方法，例如库存服务为web架构的微服务，库存服务会使用表示层的方法接收下单请求，然后使用业务逻辑层的方法解析该下单请求得到多种信息(包括产品ID)，之后使用数据访问层的方法访问产品数据库得到该产品ID的库存量。
这样，微服务系统会形成针对这个业务请求的微服务执行轨迹(可以理解为服务级别的执行轨迹)，也会形成针对这个业务请求的方法执行轨迹(可以理解为方法级别的执行轨迹)。相应地，不同的业务请求会对应不同的微服务执行轨迹或方法执行轨迹。
代码仓库10，用于存储微服务系统中的静态数据。所述静态数据可包括但不限于：代码数据和提交记录信息集。其中，代码数据可以理解为微服务系统中不同微服务所涉及的方法的代码数据。
监控平台11，用于监控微服务系统运行时产生的动态数据。监控平台11可监控到方法执行轨迹，形成方法调用链。所述动态数据可包括但不限于：方法调用链集和应用日志，其中，方法调用链集可以理解为微服务系统运行时跨服务的方法调用链的集合，方法调用链集可用于表征跨服务的方法间的直接依赖关系。应用日志可包括但不限于：异常方法调用链的异常类型和堆栈信息等。
故障根因定位设备12，用于在方法执行轨迹中产生故障时，将故障根因定位到方法，得到故障根因定位信息。其中，故障根因定位信息包括：可疑方法、可疑提交记录信息、异常位置和异常类型，从而将可疑方法与可疑提交记录信息(可疑Commit信息)关联起来，缩短代码变更场景下的故障排查时间。
图2为本公开实施例提供的一种故障根因定位装置20的示例性框图。在一些实施例中，故障根因定位装置20可以实现为图1中的故障根因定位设备12或者故障根因定位设备12的一部分，用于定位故障根因。
如图2所示，故障根因定位装置20可包括但不限于：故障传播链确定模块21、异常调用链确定模块22和故障根因定位模块23。
故障传播链确定模块21：
故障传播链确定模块21，用于基于代码仓库的数据以及监控平台的数据，确定方法故障传播链集。在一些实施例中，故障传播链确定模块21通过静态扫描代码仓库的代码数据、分析代码仓库的第一提交记录信息集(也即第一Commit集)和获取微服务系统运行时跨服务的方法调用链集，来构造方法故障传播链集，属于方法级的故障传播链，而非服务级的故障传播链。其中，第一Commit集是代码仓库中的Commit集，未经处理的，直接从代码仓库中可获取的Commit集。
在一些实施例中，故障传播链确定模块21可对代码仓库中的代码数据进行静态扫描，确定不同方法间的间接依赖关系。其中，间接依赖关系可以理解为服务内(而非跨服务)方法间的间接依赖关系。具有间接依赖关系的方法通常不在同一条方法调用链上。
在一些实施例中，故障传播链确定模块21可扫描代码仓库中哪些方法使用了同一全局变量，这些方法间具有间接依赖关系。
在一些实施例中，故障传播链确定模块21可扫描代码仓库中哪些方法使用了相同的缓存工具类来访问同一个缓存，例如，扫描哪些方法使用了Jedis类访问Redis，这些方法间具有间接依赖关系。
在一些实施例中，故障传播链确定模块21可扫描代码仓库中哪些方法使用相同的数据库工具类来访问同一个数据库，例如，JPA下哪些方法使用相同的Repository类访问同一个数据库或者Mybatis下哪些方法使用相同的Mapper类访问同一个数据库，这些方法间具有间接依赖关系。
在一些实施例中，故障传播链确定模块21确定方法间的间接依赖关系的方式类似于IDE中的Find Usage功能，实现时，通过JavaParser和Eclipse JDT等工具做静态分析，来构建AST(抽象语法树)，然后对共享状态(全局变量、缓存和数据库)进行分析，确定方法间的间接依赖关系。
在一些实施例中，故障传播链确定模块21可提取某个时间窗内代码仓库的提交记录信息，得到第一提交记录信息集(也即第一Commit集)。故障传播链确定模块21分析第一Commit集得到每个Commit修改的方法，从而确定在所述时间窗内的修改方法集和每个修改方法对应的第二提交记录信息集(也即第二Commit集)，其中，修改方法集可以理解为修改的方法的集合。在一些实施例中，故障传播链确定模块21还可确定第二Commit集中每个Commit所修改的方法的代码行数。由于一个修改方法对应一个第二Commit集，因此第二Commit集中每个Commit修改的是同一个方法，且修改的代码行数可能相同也可能不同。
在一些实施例中，故障传播链确定模块21可从监控平台获取某个时间窗内的方法调用链集，获取方式例如为通过数据提取的方式获取或其他方式获取，无论哪一种获取方式均属于本领域的成熟技术，不再赘述。在一些实施例中，方法调用链(trace)由多个方法调用对(span)组成。
在一些实施例中，故障传播链确定模块21可确定方法故障传播链集，每条方法故障传播链的链头方法(headMethod)为修改方法。在一些实施例中，故障传播链确定模块21可基于方法调用链集、方法间的间接依赖关系、修改方法集和每个修改方法对应的第二Commit集，确定方法故障传播链集。由于方法调用链集为跨服务的方法调用链的集合，因此方法故障传播链为跨服务的方法故障传播链的集合。
例如，一条跨服务的方法调用链为：S1.M1->S2.M2->S3.M3->S3.M4。其中，S1、S2和S3表示三个不同的微服务，M1、M2、M3和M4表示四个方法。S1.M1表示微服务1中的方法1，S2.M2表示微服务2中的方法2，S3.M3表示微服务3中的方法3，S3.M4表示微服务3中的方法4。这条跨服务的方法调用链表示S1.M1调用了S2.M2，S2.M2调用了S3.M3，S3.M3调用了S3.M4。因此，当修改方法为S2.M2时，其正向故障传播链为：S2.M2->S3.M3->S3.M4，是跨服务的方法故障传播链；其反向故障传播链：S2.M2->S1.M1，是跨服务的方法故障传播链。
在一些实施例中，方法故障传播链集包括直接故障传播链集，故障传播链确定模块21可确定直接故障传播链集。在一些实施例中，故障传播链确定模块21可基于方法调用链集，确定不同方法间的直接依赖关系，其中，直接依赖关系可以理解为跨服务的方法间的直接依赖关系。在一些实施例中，故障传播链确定模块21可基于方法调用链集中的正常方法调用链集，确定不同方法间的直接依赖关系。在一些实施例中，故障传播链确定模块21可基于直接依赖关系、修改方法集和每个修改方法对应的第二Commit集，确定直接故障传播链集。本实施例中，故障传播链确定模块21通过查看每个修改方法在哪些方法调用链上出现，来构造直接故障传播链。在一些实施例中，故障传播链确定模块21可根据故障传播方向，将直接故障传播链集分为正向故障传播链集和反向故障传播链集。
例如，跨服务的方法调用链为：S1.M1->S2.M2->S3.M3->S3.M4。其中，S1、S2和S3表示三个不同的微服务，M1、M2、M3和M4表示四个方法。S1.M1表示微服务1中的方法1，S2.M2表示微服务2中的方法2，S3.M3表示微服务3中的方法3，S3.M4表示微服务3中的方法4。这条方法调用链表示S1.M1调用了S2.M2，S2.M2调用了S3.M3，S3.M3调用了S3.M4，也即这条方法调用链包括三个方法调用对：S1.M1调用S2.M2、S2.M2调用S3.M3以及S3.M3调用S3.M4。
若修改方法为S2.M2时，其正反向故障传播链如下：
正向故障传播链为：S2.M2->S3.M3->S3.M4。
反向故障传播链：S2.M2->S1.M1。
一条直接故障传播链信息中可包括但不限于：直接故障传播链本身，标识信息(该标识信息用于表述该直接故障传播链是正向故障传播链还是反向故障传播链)，以及直接故障传播链中修改方法的第二Commit集中每个Commit的ID信息。直接故障传播链集可以理解为多条直接故障传播链信息的集合。
在一些实施例中，故障传播链确定模块21可确定间接故障传播链集。在一些实施例中，故障传播链确定模块21在确定间接故障传播链集的同时，还可确定每条间接故障传播链中的方法所访问的共享状态。在一些实施例中，故障传播链确定模块21基于服务内方法间的间接依赖关系、修改方法集和每个修改方法对应的第二Commit集，确定间接故障传播链集。在一些实施例中，故障传播链确定模块21可基于每个修改方法对应的第二Commit集，确定间接故障传播链中每个方法访问共享状态的代码行(codeLine)。
在一些实施例中，故障传播链确定模块21确定间接故障传播链集的方式为：对于修改方法集中的任一修改方法，找到与该修改方法存在间接依赖关系的一个方法，将该修改方法和存在间接依赖关系的一个方法构成一条间接故障传播链。间接故障传播链可有多条。间接故障传播链表示该修改方法引入的故障会间接影响与该修改方法存在间接依赖关系的方法。
例如，Si.SSj表示微服务i中的共享状态j，若微服务1中有三个方法，分别记为：S1.M1、S1.M2、S1.M3，这三个方法访问了一个全局变量S1.SS1，则这三个方法间的依赖关系为服务内方法间的间接依赖关系。
若修改方法为S1.M1时，间接故障传播链有2条：
S1.M1->S1.M2，表示链头方法为S1.M1，S1.M1引入的故障会影响方法S1.M2。同时记录这条间接故障传播链中的方法所访问的共享状态为全局变量S1.SS1。另外，还可记录这条间接故障传播链中每个方法访问共享状态的代码行。
S1.M1->S1.M3，表示链头方法为S1.M1，S1.M1引入的故障会影响方法S1.M3。同时记录这条间接故障传播链中的方法所访问的共享状态为全局变量S1.SS1。另外，还可记录这条间接故障传播链中每个方法访问共享状态的代码行。
一条间接故障传播链信息中可包括但不限于：间接故障传播链本身，间接故障传播链中的方法所访问的共享状态，以及链头方法的第二Commit集中每个Commit的ID信息。间接故障传播链集可以理解为多条间接故障传播链信息的集合。
异常调用链确定模块22
异常调用链确定模块22，用于对监控平台的数据进行预处理，确定异常方法调用链集。本实施例中，考虑到监控平台的数据包括方法调用链集和应用日志，因此，异常调用链确定模块22可对这些数据进行预处理，将应用日志与方法调用链集进行关联，同时将同类型的方法调用链进行聚合归类。
在一些实施例中，异常调用链确定模块22可识别方法调用链集中的异常方法调用链。在一些实施例中，异常调用链确定模块22识别异常方法调用链的方式为：基于方法调用链的调用结果来识别异常方法调用链，其中，调用结果包括响应码和异常类型。在一些实施例中，若一条方法调用链上存在调用失败的方法，则异常调用链确定模块22识别这条方法调用链为异常方法调用链。
在一些实施例中，异常调用链确定模块22可聚合同类型的方法调用链，得出有多少种正常方法调用链和异常方法调用链。在一些实施例中，异常调用链确定模块22可基于应用日志和链路聚合条件进行聚合，链路聚合条件包括：正常链路聚合条件和异常链路聚合条件。正常链路聚合条件例如包括：聚合链路经过的方法及顺序均相同的正常方法调用链。异常链路聚合条件例如包括：聚合链路经过的方法及顺序、抛出异常的方法和异常类型均相同的异常方法调用链，其中，抛出异常的方法相同例如为在相同的方法处抛出了空指针异常。在一些实施例中，聚合得到的正常方法调用链集用于构建直接故障传播链。
在一些实施例中，异常调用链确定模块22可将应用日志与方法调用链集(包括聚合后得到的正常方法调用链集和异常方法调用链集)进行关联，完善方法调用链的信息，如异常调用方法链的异常类型和堆栈信息等。在一些实施例中，异常调用链确定模块22可基于应用日志中的链路ID等标识，将应用日志与方法调用链进行关联，例如将具有相同链路标识的应用日志和方法调用链进行关联。在一些实施例中，异常调用链确定模块22可基于时间戳和方法名，将应用日志与方法调用链进行关联，例如，若应用日志的时间戳和方法调用链的时间戳处于预设的时间范围内，且应用日志中的方法名和方法调用链中的方法名相同，则将应用日志和方法调用链进行关联，以完善异常信息。
故障根因定位模块23
故障根因定位模块23，用于基于方法故障传播链集和异常方法调用链集，确定故障根因信息，所述故障根因信息包括可疑方法。在一些实施例中，所述故障根因信息还包括可疑提交记录信息。在一些实施例中，所述故障根因信息还包括：异常位置和异常类型。
在一些实施例中，故障根因定位模块23可对异常方法调用链集进行故障诊断，得到可疑方法集。在一些实施例中，故障根因定位模块23基于方法故障传播链集和方法调用链集对异常方法调用链集进行故障诊断。在一些实施例中，故障根因定位模块23可输出多个可疑方法作为故障根因信息。
在一些实施例中，故障根因定位模块23在输出多个可疑方法后，对这些可疑方法对应的第三Commit集进行可疑分析，找到与本次异常最相关的可疑Commit集。在一些实施例中，故障根因信息中可包括多个可疑方法，多个可疑Commit，每个可疑方法的异常位置和异常类型。
在一些实施例中，故障根因定位模块23可确定异常位置。对于直接依赖关系，可疑方法必然在异常方法调用链上，故障根因定位模块23获取关联应用日志的异常方法调用链后，可确定该可疑方法抛出异常的代码行和该可疑方法所在的异常方法调用链上最后一个异常方法抛出异常的代码行，将这两个异常的代码行位置作为异常位置输出。对于间接依赖关系，则无法找到可疑方法与异常调用链相关的直接异常代码行，故障根因定位模块23依次输出可疑方法访问或修改共享状态变量的代码行位置作为异常位置。
在一些实施例中，故障根因定位模块23可确定异常类型。对于直接依赖关系，故障根因定位模块23获取关联应用日志的异常方法调用链后，可确定该可疑方法抛出的异常类型和该可疑方法所在的异常方法调用链上最后一个异常方法抛出的异常类型，将这两个异常类型作为输出。对于间接依赖关系，故障根因定位模块23输出与该可疑方法相关的异常方法抛出的异常类型和该异常方法所在的异常方法调用链上最后一个异常方法所抛出的异常类型。其中，与可疑方法相关的异常方法例如为：与可疑方法具有间接依赖关系的异常方法。
在一些实施例中，故障根因定位装置20中各单元的划分仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如故障传播链确定模块21、异常调用链确定模块22和故障根因定位模块23中的至少两个模块可以实现为一个模块；故障传播链确定模块21、异常调用链确定模块22或故障根因定位模块23也可以划分为多个单元。可以理解的是，各个模块或单元能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可对每个特定的应用来使用不同方法来实现所描述的功能。
图3为本公开实施例提供的一种故障根因定位模块30的示例性框图。在一些实施例中，故障根因定位模块30可以实现为图2中的故障根因定位模块23或者故障根因定位模块23的一部分。
如图3所示，故障根因定位模块30可包括但不限于：故障诊断单元31和代码比对单元32。
故障诊断单元31
故障诊断单元31，可以实现为故障诊断引擎，用于可对异常方法调用链集进行故障诊断，得到可疑方法集。在一些实施例中，故障诊断单元31基于方法故障传播链集和方法调用链集对异常方法调用链集进行故障诊断。
在一些实施例中，故障诊断单元31基于异常方法调用链集匹配方法故障传播链集(包括直接故障传播链集和间接故障传播链集)，得到可疑故障传播链集。对于某一类异常方法调用链集，选出一条异常方法调用链，与方法故障传播链集进行匹配。在一些实施例中，故障诊断单元31将异常方法调用链上的异常方法与方法故障传播链集进行匹配，若异常方法出现在某条方法故障传播链上，则确定这条方法故障传播链为可疑故障传播链。
例如，异常方法调用链“S1.M1->S2.M2->S3.M3->S3.M4”中，S2.M2，S3.M3，S3.M4抛出了异常或者响应码异常或者调用失败，则这条异常方法调用链上的异常方法为S2.M2，S3.M3和S3.M4。故障诊断单元31使用每个异常方法与方法故障传播链集进行匹配。
在一些实施例中，故障诊断单元31对可疑故障传播链集进行过滤，滤除与本次调用不相关的可疑故障传播链。其中，可疑故障传播链集中包括直接故障传播链集和间接故障传播链集，故障诊断单元31保留间接故障传播链集，对直接故障传播链集进行滤除。其中，所述调用不相关可以理解为：可疑故障传播链为直接故障传播链，且可疑故障传播链上异常方法之前和之后的方法，均未出现在异常方法调用链上，则可疑故障传播链与异常方法调用链不相关。
例如，异常方法调用链“S1.M1->S2.M2->S3.M3”中S2.M2是异常方法，S3.M3是修改方法，那么方法故障传播链“S3.M3->S2.M2->S1.M1”会被匹配到。此时，如果另有方法故障传播链“S4.M4->S2.M2->S5.M5”，由于S2.M2在其上，那么这条方法故障传播链也将被匹配出来，这种由直接依赖关系形成的方法故障传播链是需要滤除的，因为本次的异常方法调用链“S1.M1->S2.M2->S3.M3”与方法故障传播链“S4.M4->S2.M2->S5.M5”无关。
在一些实施例中，故障诊断单元31对过滤后的可疑故障传播链集，提取每个可疑故障传播链的链头方法，得到可疑方法集。在一些实施例中，若可疑方法数量为0，即没有修改方法与该异常方法调用链相关；若可疑方法数量为1，即只有1个修改方法与该异常方法调用链相关；若可疑方法数量大于1，即有多个修改方法与该异常方法调用链相关。
在一些实施例中，故障诊断单元31可确定可疑方法集中每个可疑方法的失败率。在一些实施例中，针对任一可疑方法，故障诊断单元31可确定经过该可疑方法的所有方法调用链(包括正常方法调用链和异常方法调用链)中异常方法调用链的数量，进而确定异常方法调用链的数量和经过该可疑方法的所有方法调用链的数量，确定该可疑方法的失败率。
在一些实施例中，故障诊断单元31确定每个可疑方法所在的一个或多个方法调用链。本实施例中，故障诊断单元31可基于每个方法调用链上的方法，构建倒排索引，进而确定经过可疑方法的方法调用链有哪些。在一些实施例中，故障诊断单元31通过下式确定可疑方法的失败率：
Figure BDA0003001918630000131
其中，Si表示可疑方法i的失败率，Tf表示经过可疑方法i的异常方法调用链的数量，Tt表示经过可疑方法i的方法调用链的总数量。
例如，可疑方法共有三个：S1.M1，S2.M2，S3.M3。在时间窗口内与以上三个可疑方法相关的方法调用链(包括正常方法调用链和异常方法调用链，且异常方法调用链可能是由异常方法的直接传播或间接传播导致的异常)如下：
链路序号 链路经过的方法 是否异常
1 S1.M1->S2.M2->S3.M3 是
2 S2.M1->S1.M1->S3.M4->S3.M2 否
3 S3.M1->S2.M2->S3.M3 是
4 S4.M1->S2.M2->S3.M3 是
5 S5.M1->S5.M2->S4.M2->S3.M3 否
6 S3.M1->S1.M1->S3.M2 否
统计经过这三个可疑方法的失败率如下：
Figure BDA0003001918630000132
在一些实施例中，故障诊断单元31可确定异常方法调用链上每个方法的失败率，且其计算方式类似于可疑方法失败率的计算方法，不再赘述。
在一些实施例中，故障诊断单元31可确定可疑方法的可疑率。在一些实施例中，故障诊断单元31可基于可疑方法对应的第三Commit集，确定可疑方法的代码修改总行数和Commit次数。其中，可疑方法的Commit次数可以理解为可疑方法对应的第三Commit集中包括的Commit数量。在一些实施例中，故障诊断单元31可基于可疑方法的失败率、可疑方法的代码修改总行数和Commit次数，确定可疑方法的可疑率。
例如，故障诊断单元31通过下式确定可疑方法的可疑率：
Figure BDA0003001918630000141
其中，Fi表示可疑方法i的可疑率，Si表示可疑方法i的失败率，Li表示可疑方法i的代码修改总行数，Lt表示微服务系统代码修改总行数，Ci表示可疑方法i的修改总次数(也即可疑方法i所对应的Commit次数)，Ct表示微服务系统修改总次数；Kl和Kc分别表示可疑方法的修改面积和修改次数的影响因子，取值范围为[0,1]。在一些实施例中，Kl为0.7，Kc为0.3，需要说明的是，针对不同微服务系统，Kl和Kc可设置不同取值，本领域技术人员可根据实际需要自行设置Kl和Kc的取值。
在一些实施例中，若可疑方法数量为0，则Fi与Si相同，故障诊断单元31将异常方法调用链上每个方法的失败率排序后，输出Top k的方法作为故障根因信息，其中，Top k的方法表示失败率由大至小排序的前k个方法；若可疑方法数量为1，则故障诊断单元31输出该方法作为故障根因信息；若可疑方法数量大于1，则故障诊断单元31将可疑方法按照可疑率由大至小排序，并输出Top k个可疑方法作为故障根因信息。
代码比对单元32
代码比对单元32，可以实现为代码分析(Code diff)引擎，用于在输出Top k个可疑方法后，对这些可疑方法对应的第三Commit集进行可疑分析。
在一些实施例中，若可疑方法数量为0，代码比对单元32输出的是Top k个方法，这Top k个方法属于异常方法调用链集中的方法，则代码比对单元32对这Top k个方法对应的Commit集进行可疑分析，且其可疑分析类似于Top k个可疑方法对应的第三Commit集的可疑分析。
在一些实施例中，若可疑方法为直接依赖故障传播链的链头方法，则代码比对单元32基于关联应用日志的异常方法调用链集，确定可疑方法抛异常的代码行；然后基于该代码行对该可疑方法对应的第三Commit集进行比对分析，得到可疑Commit集，其中，可疑Commit集中包括修改了该代码行所对应的代码的Commit，若该代码行是方法调用，则可疑Commit集中还包括修改了该方法调用的参数的Commit。
在一些实施例中，若可疑方法为间接依赖故障传播链的链头方法，则代码比对单元32确定该可疑方法访问或修改的共享状态；然后对该可疑方法对应的第三Commit集进行比对分析，得到可疑Commit集，其中，可疑Commit集中包括访问或修改了该共享状态的可疑Commit。
在一些实施例中，代码比对单元32确定可疑Commit集中每个Commit对应的代码修改行数，然后基于代码修改行数和修改时间进行排序，输出Top k的可疑Commit。在一些实施例中，代码修改行数越多，可疑Commit排序越靠前；代码修改行数相同时，修改时间越早，可疑Commit排序越靠前。
在一些实施例中，代码比对单元32输出的故障根因信息包括：可疑方法、可疑提交记录信息(即可疑Commit)、异常位置和异常类型。其中，异常位置为可疑方法发生异常或与异常相关的代码行位置。在一些实施例中，故障根因信息中包括Top k个可疑方法，Top k个可疑Commit，每个可疑方法的异常位置和异常类型。
在一些实施例中，故障根因定位模块30中各单元的划分仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如故障诊断单元31和代码比对单元32可以实现为一个单元；故障诊断单元31或代码比对单元32也可以划分为多个子单元。可以理解的是，各个单元或子单元能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可对每个特定的应用来使用不同方法来实现所描述的功能。
图4是本公开实施例提供的一种电子设备的结构示意图。在一些实施例中，所述电子设备可以实现为图1中的故障根因定位设备12或者故障根因定位设备12的一部分。
如图4所示，电子设备包括：至少一个处理器41、至少一个存储器42和至少一个通信接口43。电子设备中的各个组件通过总线系统44耦合在一起。通信接口43，用于与外部设备之间的信息传输。可以理解，总线系统44用于实现这些组件之间的连接通信。总线系统44除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但为了清楚说明，在图4中将各种总线都标为总线系统44。
可以理解，本实施例中的存储器42可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。
在一些实施方式中，存储器42存储了如下的元素，可执行单元或者数据结构，或者他们的子集，或者他们的扩展集：操作系统和应用程序。
其中，操作系统，包含各种系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务。应用程序，包含各种应用程序，例如媒体播放器(Media Player)、浏览器(Browser)等，用于实现各种应用业务。实现本公开实施例提供的微服务系统故障根因定位方法的程序可以包含在应用程序中。
在本公开实施例中，处理器41通过调用存储器42存储的程序或指令，具体的，可以是应用程序中存储的程序或指令，处理器41用于执行本公开实施例提供的微服务系统故障根因定位方法各实施例的步骤。
本公开实施例提供的微服务系统故障根因定位方法可以应用于处理器41中，或者由处理器41实现。处理器41可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器41中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器41可以是通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
本公开实施例提供的微服务系统故障根因定位方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件单元组合执行完成。软件单元可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器42，处理器41读取存储器42中的信息，结合其硬件完成方法的步骤。
图5为本公开实施例提供的一种微服务系统故障根因定位方法的示例性流程图。该方法的执行主体为电子设备。为便于描述，以下实施例中以电子设备为执行主体说明一种微服务系统故障根因定位方法的流程。
在步骤501中，电子设备基于所述代码仓库的数据以及所述监控平台的数据，确定方法故障传播链集。其中，代码仓库的数据包括：代码数据和提交记录信息集。监控平台的数据包括：方法调用链集和应用日志，其中，应用日志至少包括异常方法调用链的异常类型和堆栈信息等。方法调用链集可以理解为微服务系统运行时跨服务的方法调用链的集合，这个方法调用链集可用于表征跨服务的方法间的直接依赖关系。
在一些实施例中，电子设备可对代码仓库中的代码数据进行静态扫描，确定不同方法间的间接依赖关系。其中，间接依赖关系可以理解为服务内(而非跨服务)方法间的间接依赖关系。具有间接依赖关系的方法通常不在同一条方法调用链上。
在一些实施例中，电子设备可扫描代码仓库中哪些方法使用了同一全局变量，这些方法间具有间接依赖关系。
在一些实施例中，电子设备可扫描代码仓库中哪些方法使用了相同的缓存工具类来访问同一个缓存，例如，扫描哪些方法使用了Jedis类访问Redis，这些方法间具有间接依赖关系。
在一些实施例中，电子设备可扫描代码仓库中哪些方法使用相同的数据库工具类来访问同一个数据库，例如，JPA下哪些方法使用相同的Repository类访问同一个数据库或者Mybatis下哪些方法使用相同的Mapper类访问同一个数据库，这些方法间具有间接依赖关系。
在一些实施例中，电子设备确定方法间的间接依赖关系的方式类似于IDE中的Find Usage功能，实现时，通过JavaParser和Eclipse JDT等工具做静态分析，来构建AST(抽象语法树)，然后对共享状态(全局变量、缓存和数据库)进行分析，确定方法间的间接依赖关系。
在一些实施例中，电子设备可提取某个时间窗内代码仓库的提交记录信息，得到第一提交记录信息集(也即第一Commit集)。电子设备分析第一Commit集得到每个Commit修改的方法，从而确定在所述时间窗内的修改方法集和每个修改方法对应的第二提交记录信息集(也即第二Commit集)，其中，修改方法集可以理解为修改的方法的集合。在一些实施例中，电子设备还可确定第二Commit集中每个Commit所修改的方法的代码行数。由于一个修改方法对应一个第二Commit集，因此第二Commit集中每个Commit修改的是同一个方法，且修改的代码行数可能相同也可能不同。
在一些实施例中，电子设备可从监控平台获取某个时间窗内的方法调用链集，获取方式例如为通过数据提取的方式获取或其他方式获取，无论哪一种获取方式均属于本领域的成熟技术，不再赘述。在一些实施例中，方法调用链(trace)由多个方法调用对(span)组成。
在一些实施例中，电子设备可确定方法故障传播链集，每条方法故障传播链的链头方法(headMethod)为修改方法。在一些实施例中，电子设备可基于方法调用链集、方法间的间接依赖关系、修改方法集和每个修改方法对应的第二Commit集，确定方法故障传播链集。由于方法调用链集为跨服务的方法调用链的集合，因此方法故障传播链为跨服务的方法故障传播链的集合。
在一些实施例中，方法故障传播链集包括直接故障传播链集，电子设备可确定直接故障传播链集。在一些实施例中，电子设备可基于方法调用链集，确定不同方法间的直接依赖关系，其中，直接依赖关系可以理解为跨服务的方法间的直接依赖关系。在一些实施例中，电子设备基于方法调用链集中的正常方法调用链集，确定不同方法间的直接依赖关系。在一些实施例中，电子设备可基于直接依赖关系、修改方法集和每个修改方法对应的第二Commit集，确定直接故障传播链集。本实施例中，电子设备通过查看每个修改方法在哪些方法调用链上出现，来构造直接故障传播链。在一些实施例中，电子设备可根据故障传播方向，将直接故障传播链集分为正向故障传播链集和反向故障传播链集。
例如，跨服务的方法调用链为：S1.M1->S2.M2->S3.M3->S3.M4。其中，S1、S2和S3表示三个不同的微服务，M1、M2、M3和M4表示四个方法。S1.M1表示微服务1中的方法1，S2.M2表示微服务2中的方法2，S3.M3表示微服务3中的方法3，S3.M4表示微服务3中的方法4。这条方法调用链表示S1.M1调用了S2.M2，S2.M2调用了S3.M3，S3.M3调用了S3.M4，也即这条方法调用链包括三个方法调用对：S1.M1调用S2.M2、S2.M2调用S3.M3以及S3.M3调用S3.M4。
若修改方法为S2.M2时，其正反向故障传播链如下：
正向故障传播链为：S2.M2->S3.M3->S3.M4。
反向故障传播链：S2.M2->S1.M1。
在一些实施例中，电子设备可确定间接故障传播链集。在一些实施例中，电子设备在确定间接故障传播链集的同时，还可确定每条间接故障传播链中的方法所访问的共享状态。在一些实施例中，电子设备基于服务内方法间的间接依赖关系、修改方法集和每个修改方法对应的第二Commit集，确定间接故障传播链集。在一些实施例中，电子设备可基于每个修改方法对应的第二Commit集，确定每个方法访问共享状态的代码行(codeLine)。
例如，Si.SSj表示微服务i中的共享状态j，若微服务1中有三个方法，分别记为：S1.M1、S1.M2、S1.M3，这三个方法访问了一个全局变量S1.SS1，则这三个方法间的依赖关系为服务内方法间的间接依赖关系。
若修改方法为S1.M1时，间接故障传播链有2条：
S1.M1->S1.M2，表示链头方法为S1.M1，S1.M1引入的故障会影响方法S1.M2。同时记录这条间接故障传播链中的方法所访问的共享状态为全局变量S1.SS1。另外，还可记录这条间接故障传播链中每个方法访问共享状态的代码行。
S1.M1->S1.M3，表示链头方法为S1.M1，S1.M1引入的故障会影响方法S1.M3。同时记录这条间接故障传播链中的方法所访问的共享状态为全局变量S1.SS1。另外，还可记录这条间接故障传播链中每个方法访问共享状态的代码行。
在步骤502中，电子设备可对监控平台的数据进行预处理，确定异常方法调用链集。本实施例中，考虑到监控平台的数据包括方法调用链集和应用日志，因此，电子设备可对这些数据进行预处理，将应用日志与方法调用链集进行关联，同时将同类型的方法调用链进行聚合归类。
在一些实施例中，电子设备可识别方法调用链集中的异常方法调用链。在一些实施例中，电子设备识别异常方法调用链的方式为：基于方法调用链的调用结果来识别异常方法调用链，其中，调用结果包括响应码和异常类型。在一些实施例中，若一条方法调用链上存在调用失败的方法，则电子设备识别这条方法调用链为异常方法调用链。
在一些实施例中，电子设备可聚合同类型的方法调用链，得出有多少种正常方法调用链和异常方法调用链。在一些实施例中，电子设备可基于应用日志和链路聚合条件进行聚合，链路聚合条件包括：正常链路聚合条件和异常链路聚合条件。正常链路聚合条件例如包括：聚合链路经过的方法及顺序均相同的正常方法调用链。异常链路聚合条件例如包括：聚合链路经过的方法及顺序、抛出异常的方法和异常类型均相同的异常方法调用链，其中，抛出异常的方法相同例如为在相同的方法处抛出了空指针异常。在一些实施例中，聚合得到的正常方法调用链集用于构建直接故障传播链。
在一些实施例中，电子设备可将应用日志与方法调用链集(包括聚合后得到的正常方法调用链集和异常方法调用链集)进行关联，完善方法调用链的信息，如异常调用方法链的异常类型和堆栈信息等。在一些实施例中，电子设备可基于应用日志中的链路ID等标识，将应用日志与方法调用链进行关联，例如将具有相同链路标识的应用日志和方法调用链进行关联。在一些实施例中，电子设备可基于时间戳和方法名，将应用日志与方法调用链进行关联，例如，若应用日志的时间戳和方法调用链的时间戳处于预设的时间范围内，且应用日志中的方法名和方法调用链中的方法名相同，则将应用日志和方法调用链进行关联。
在步骤503中，电子设备可基于方法故障传播链集和异常方法调用链集，确定故障根因信息，所述故障根因信息包括可疑方法。在一些实施例中，所述故障根因信息还包括可疑提交记录信息。在一些实施例中，所述故障根因信息还包括：异常位置和异常类型。
在一些实施例中，电子设备可对异常方法调用链集进行故障诊断，得到可疑方法集。在一些实施例中，电子设备基于方法故障传播链集和方法调用链集对异常方法调用链集进行故障诊断。
在一些实施例中，电子设备基于异常方法调用链集匹配方法故障传播链集(包括直接故障传播链集和间接故障传播链集)，得到可疑故障传播链集。对于某一类异常方法调用链集，选出一条异常方法调用链，与方法故障传播链集进行匹配。在一些实施例中，电子设备将异常方法调用链上的异常方法与方法故障传播链集进行匹配，若异常方法出现在某条方法故障传播链上，则确定这条方法故障传播链为可疑故障传播链。
例如，异常方法调用链“S1.M1->S2.M2->S3.M3->S3.M4”中，S2.M2，S3.M3，S3.M4抛出了异常或者响应码异常或者调用失败，则这条异常方法调用链上的异常方法为S2.M2，S3.M3和S3.M4。电子设备使用每个异常方法与方法故障传播链集进行匹配。
在一些实施例中，电子设备对可疑故障传播链集进行过滤，滤除与本次调用不相关的可疑故障传播链。其中，可疑故障传播链集中包括直接故障传播链集和间接故障传播链集，电子设备保留间接故障传播链集，对直接故障传播链集进行滤除。其中，所述调用不相关可以理解为：可疑故障传播链为直接故障传播链，且可疑故障传播链上异常方法之前和之后的方法，均未出现在异常方法调用链上，则可疑故障传播链与异常方法调用链不相关。
例如，异常方法调用链“S1.M1->S2.M2->S3.M3”中S2.M2是异常方法，S3.M3是修改方法，那么方法故障传播链“S3.M3->S2.M2->S1.M1”会被匹配到。此时，如果另有方法故障传播链“S4.M4->S2.M2->S5.M5”，由于S2.M2在其上，那么这条方法故障传播链也将被匹配出来，这种由直接依赖关系形成的方法故障传播链是需要滤除的，因为本次的异常方法调用链“S1.M1->S2.M2->S3.M3”与方法故障传播链“S4.M4->S2.M2->S5.M5”无关。
在一些实施例中，电子设备对过滤后的可疑故障传播链集，提取每个可疑故障传播链的链头方法，得到可疑方法集。在一些实施例中，若可疑方法数量为0，即没有修改方法与该异常方法调用链相关；若可疑方法数量为1，即只有1个修改方法与该异常方法调用链相关；若可疑方法数量大于1，即有多个修改方法与该异常方法调用链相关。
在一些实施例中，电子设备可确定可疑方法集中每个可疑方法的失败率。在一些实施例中，针对任一可疑方法，电子设备可确定经过该可疑方法的所有方法调用链(包括正常方法调用链和异常方法调用链)中异常方法调用链的数量，进而确定异常方法调用链的数量和经过该可疑方法的所有方法调用链的数量，确定该可疑方法的失败率。
在一些实施例中，电子设备确定每个可疑方法所在的一个或多个方法调用链。本实施例中，电子设备可基于每个方法调用链上的方法，构建倒排索引，进而确定经过可疑方法的方法调用链有哪些。在一些实施例中，电子设备通过下式确定可疑方法的失败率：
Figure BDA0003001918630000191
其中，Si表示可疑方法i的失败率，Tf表示经过可疑方法i的异常方法调用链的数量，Tt表示经过可疑方法i的方法调用链的总数量。
例如，可疑方法共有三个：S1.M1，S2.M2，S3.M3。在时间窗口内与以上三个可疑方法相关的方法调用链(包括正常方法调用链和异常方法调用链，且异常方法调用链可能是由异常方法的直接传播或间接传播导致的异常)如下：
链路序号 链路经过的方法 是否异常
1 S1.M1->S2.M2->S3.M3 是
2 S2.M1->S1.M1->S3.M4->S3.M2 否
3 S3.M1->S2.M2->S3.M3 是
4 S4.M1->S2.M2->S3.M3 是
5 S5.M1->S5.M2->S4.M2->S3.M3 否
6 S3.M1->S1.M1->S3.M2 否
统计经过这三个可疑方法的失败率如下：
Figure BDA0003001918630000201
在一些实施例中，电子设备可确定异常方法调用链上每个方法的失败率，且其计算方式类似于可疑方法失败率的计算方法，不再赘述。
在一些实施例中，电子设备可确定可疑方法的可疑率。在一些实施例中，电子设备可基于可疑方法对应的第三Commit集，确定可疑方法的代码修改总行数和Commit次数。其中，可疑方法的Commit次数可以理解为可疑方法对应的第三Commit集中包括的Commit数量。在一些实施例中，电子设备可基于可疑方法的失败率、可疑方法的代码修改总行数和Commit次数，确定可疑方法的可疑率。
例如，电子设备通过下式确定可疑方法的可疑率：
Figure BDA0003001918630000211
其中，Fi表示可疑方法i的可疑率，Si表示可疑方法i的失败率，Li表示可疑方法i的代码修改总行数，Lt表示微服务系统代码修改总行数，Ci表示可疑方法i的修改总次数(也即可疑方法i所对应的Commit次数)，Ct表示微服务系统修改总次数；Kl和Kc分别表示可疑方法的修改面积和修改次数的影响因子，取值范围为[0,1]。在一些实施例中，Kl为0.7，Kc为0.3，需要说明的是，针对不同微服务系统，Kl和Kc可设置不同取值，本领域技术人员可根据实际需要自行设置Kl和Kc的取值。
在一些实施例中，若可疑方法数量为0，则Fi与Si相同，电子设备将异常方法调用链上每个方法的失败率排序后，输出Top k的方法作为故障根因信息，其中，Top k的方法表示失败率由大至小排序的前k个方法；若可疑方法数量为1，则电子设备输出该方法作为故障根因信息；若可疑方法数量大于1，则电子设备将可疑方法按照可疑率由大至小排序，并输出Top k个可疑方法作为故障根因信息。
在一些实施例中，电子设备在输出Top k个可疑方法后，对这些可疑方法对应的第三Commit集进行可疑分析。在一些实施例中，若可疑方法数量为0，电子设备输出的是Top k个方法，这Top k个方法属于异常方法调用链集中的方法，则电子设备对这Top k个方法对应的Commit集进行可疑分析，且其可疑分析类似于Top k个可疑方法对应的第三Commit集的可疑分析。
在一些实施例中，若可疑方法为直接依赖故障传播链的链头方法，则电子设备基于关联应用日志的异常方法调用链集，确定可疑方法抛异常的代码行；然后基于该代码行对该可疑方法对应的第三Commit集进行比对分析，得到可疑Commit集，其中，可疑Commit集中包括修改了该代码行所对应的代码的Commit，若该代码行是方法调用，则可疑Commit集中还包括修改了该方法调用的参数的Commit。
在一些实施例中，若可疑方法为间接依赖故障传播链的链头方法，则电子设备确定该可疑方法访问或修改的共享状态；然后对该可疑方法对应的第三Commit集进行比对分析，得到可疑Commit集，其中，可疑Commit集中包括访问或修改了该共享状态的可疑Commit。
在一些实施例中，电子设备确定可疑Commit集中每个Commit对应的代码修改行数，然后基于代码修改行数和修改时间进行排序，输出Top k的可疑Commit。在一些实施例中，代码修改行数越多，可疑Commit排序越靠前；代码修改行数相同时，修改时间越早，可疑Commit排序越靠前。
在一些实施例中，电子设备输出的故障根因信息包括：可疑方法、可疑提交记录信息(即可疑Commit)、异常位置和异常类型。其中，异常位置为可疑方法发生异常或与异常相关的代码行位置。在一些实施例中，故障根因信息中包括Top k个可疑方法，Top k个可疑Commit，每个可疑方法的异常位置和异常类型。
在一些实施例中，电子设备可确定异常位置。对于直接依赖关系，可疑方法必然在异常方法调用链上，电子设备获取关联应用日志的异常方法调用链后，可确定该可疑方法抛出异常的代码行和该可疑方法所在的异常方法调用链上最后一个异常方法抛出异常的代码行，将这两个异常的代码行位置作为异常位置输出。对于间接依赖关系，则无法找到可疑方法与异常调用链相关的直接异常代码行，电子设备依次输出可疑方法访问或修改共享状态变量的代码行位置作为异常位置。
在一些实施例中，电子设备可确定异常类型。对于直接依赖关系，电子设备获取关联应用日志的异常方法调用链后，可确定该可疑方法抛出的异常类型和该可疑方法所在的异常方法调用链上最后一个异常方法抛出的异常类型，将这两个异常类型作为输出。对于间接依赖关系，电子设备输出与该可疑方法相关的异常方法抛出的异常类型和该异常方法所在的异常方法调用链上最后一个异常方法所抛出的异常类型。其中，与可疑方法相关的异常方法例如为：与可疑方法具有间接依赖关系的异常方法。
可见，本公开的至少一个实施例中，采用微服务系统运行时跨服务的方法级调用链来描述方法间的直接依赖关系，以构造直接故障传播链；采用代码静态扫描共享状态访问情况来描述方法间的间接依赖关系，以构造间接故障传播链。在一些实施例中，若需要线上实时地进行故障根因定位，同时微服务系统运行时跨服务的方法级调用链数据不多，也可通过代码静态扫描的方式来获取方法间的直接依赖关系，以构建直接故障传播链，但是可能会有一部分代码静态扫描所得的方法调用链是在微服务系统运行时从未经过的。
图6是本公开实施例提供的一种微服务系统故障根因定位方法的示例性流程图，该方法的执行主体为电子设备，为便于描述，省略执行主体，该方法包括如下步骤601至608：
在步骤601中，对代码仓库中的代码数据进行静态扫描，确定不同方法间的间接依赖关系。
在步骤602中，对代码仓库中的第一Commit集进行分析每个Commit修改的方法，从而确定修改方法集和每个修改方法对应的第二Commit集。
在步骤603中，对监控平台进行数据提取，得到应用日志和方法调用链集。
在步骤604中，对应用日志和方法调用链集进行预处理，得到关联应用日志的异常方法调用链集。
在步骤605中，将方法调用链集、间接依赖关系、修改方法集和每个修改方法对应的第二Commit集进行数据整合，得到方法故障传播链集。
在步骤606中，对关联应用日志的异常方法调用链集和方法故障传播链集进行故障诊断，得到可疑方法集。
在步骤607中，将可疑方法集、修改方法集和每个修改方法对应的第二Commit集进行代码比对(也即Code diff)，得到可疑Commit集。
在步骤608中，对关联应用日志的异常方法调用链集、可疑方法集和可疑Commit集进行数据整合，得到故障根因信息，所述故障根因信息可包括：可疑方法、可疑提交记录信息、异常位置和异常类型。
需要说明的是，图6所示的微服务系统故障根因定位方法与图5所示的方法实质相同，仅在文字表述上有所区别，图6中各步骤的详细实施方式可参考图5的相关实施例，在此不再赘述。
图7是本公开实施例提供的一种确定间接故障传播链集的示例性流程图，该方法的执行主体为电子设备，为便于描述，省略执行主体，该方法包括如下步骤701至702：
在步骤701中，基于间接依赖关系进行方法匹配，确定具有间接依赖关系的多个方法。
在步骤702中，基于修改方法集和每个修改方法对应的第二Commit集，确定间接传播的途径。
由步骤701和702的结果可以确定间接故障传播链集。
需要说明的是，图7所示的确定间接故障传播链集与图5相关的实施例中涉及到间接故障传播链集的实施例实质相同，仅在文字表述上有所区别，图7中各步骤的详细实施方式可参考图5的相关实施例，在此不再赘述。
图8是本公开实施例提供的一种确定直接故障传播链集的实例性流程图，该方法的执行主体为电子设备，为便于描述，省略执行主体，该方法包括如下步骤801至804：
在步骤801中，对方法调用链集进行数据提取，得到直接依赖关系。
在步骤802中，基于直接依赖关系、修改方法集和每个修改方法对应的第二Commit集进行方法匹配。
在步骤803中，确定正向传播轨迹，得到正向故障传播链集。
在步骤804中，确定反向传播轨迹，得到反向故障传播链集。
需要说明的是，图8所示的确定直接故障传播链集与图5相关的实施例中涉及到直接故障传播链集的实施例实质相同，仅在文字表述上有所区别，图8中各步骤的详细实施方式可参考图5的相关实施例，在此不再赘述。
图9是本公开实施例提供的一种确定异常方法调用链集的示例性流程图，该方法的执行主体为电子设备，为便于描述，省略执行主体，该方法包括如下步骤901和902：
在步骤901中，对方法调用链集进行异常方法调用链的识别并对同类型的方法调用链进行聚合归类，得出有多少种正常方法调用链和异常方法调用链。
在步骤902中，对应用日志和聚合后的异常方法调用链集进行数据整合，得到关联应用日志的异常方法调用链集。
需要说明的是，图9所示的确定异常方法调用链集与图5相关的实施例中涉及到异常方法调用链集的实施例实质相同，仅在文字表述上有所区别，图9中各步骤的详细实施方式可参考图5的相关实施例，在此不再赘述。
图10是本公开实施例提供的一种输出可疑方法的示例性流程图，该方法的执行主体为电子设备，为便于描述，省略执行主体，该方法包括如下步骤101和104：
在步骤101中，采用方法调用链集中的异常方法调用链集匹配方法故障传播链集，得到可疑故障传播链集。
在步骤102中，对可疑故障传播链集进行过滤和提取链头方法，得到可疑方法集。
在步骤103中，基于方法调用链集中的正常方法调用链集和异常方法调用链集，确定可疑方法集中每个可疑方法的失败率以及异常方法调用链集中每个方法的失败率。
在步骤104中，基于可疑方法集中每个可疑方法的失败率和可疑方法集中每个可疑方法对应的第三Commit集，计算每个可疑方法的可疑率，并基于可疑率进行排序，输出Top k个可疑方法。
需要说明的是，图10所示的输出可疑方法与图5相关的实施例中涉及到输出可疑方法的实施例实质相同，仅在文字表述上有所区别，图10中各步骤的详细实施方式可参考图5的相关实施例，在此不再赘述。
图11是本公开实施例提供的一种输出可疑方法的可疑Commit集的示例性流程图，该方法的执行主体为电子设备，为便于描述，省略执行主体，该方法包括如下步骤111和113：
在步骤111中，将关联应用日志的异常方法调用链集与可疑方法(可疑方法为直接依赖故障传播链的链头方法)进行方法匹配，得到可疑方法抛出异常的代码行。
在步骤112中，将间接故障传播链与可疑方法(可疑方法为间接依赖故障传播链的链头方法)进行方法匹配，得到可疑方法访问或修改共享状态的代码行。
在步骤113中，基于可疑方法抛出异常的代码行、可疑方法访问或修改共享状态的代码行和可疑方法对应的第三Commit集，匹配代码行相关的修改，输出Top k个可疑Commit。
需要说明的是，图11所示的输出可疑方法的可疑Commit集与图5相关的实施例中涉及到可疑Commit集的实施例实质相同，仅在文字表述上有所区别，图11中各步骤的详细实施方式可参考图5的相关实施例，在此不再赘述。
基于以上各实施例确定故障根因信息后，进一步展示告警消息，该告警消息中包括故障根因信息。
例如，告警消息为邮件。具体地，在确定故障根因信息，可向开发人员的预设邮箱发送告警邮件，故障根因信息以文本或图片等方式添加在告警邮件的正文或附件中，或，告警邮件中携带故障根因链接，故障根因链接被点击后弹出故障根因页面，在该页面中展示故障根因信息。
又例如，告警消息为告警界面。具体地，在确定故障根因信息后，可通过社交软件建立与开发人员聊天的告警界面，在该界面中展示故障根因信息或故障根因链接，故障根因链接被点击后弹出故障根因页面，在该页面中展示故障根因信息。
在页面中展示故障根因信息时，可采用故障列表的方式展示故障根因信息，也可以采用图示方式展示故障根因信息，还可以采用其他方式展示故障根因信息，本领域技术人员可根据实际需要在页面中布局故障根因信息的展示方式。
展示的故障根因信息可包括但不限于：可疑方法、可疑方法对应的可疑提交记录信息、可疑方法的异常代码行位置、可疑方法的异常类型等。在展示故障根因信息的同时还可以展示具体故障的链接，具体故障的链接被点击后，可跳转至该具体故障(也即可疑方法)所在位置。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员能够理解，本公开实施例并不受所描述的动作顺序的限制，因为依据本公开实施例，某些步骤可以采用其他顺序或者同时进行。另外，本领域技术人员能够理解，说明书中所描述的实施例均属于可选实施例。
本公开实施例还提出一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行如微服务系统故障根因定位方法各实施例的步骤，为避免重复描述，在此不再赘述。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本公开的范围之内并且形成不同的实施例。
本领域的技术人员能够理解，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
虽然结合附图描述了本公开的实施方式，但是本领域技术人员可以在不脱离本公开的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims (34)

1.一种微服务系统故障根因定位方法，其特征在于，包括：
获取代码数据、第一提交记录信息集、应用日志和方法调用链集；
基于所述代码数据、第一提交记录信息集、应用日志和方法调用链集，确定方法故障传播链集；
识别所述方法调用链集中的异常方法调用链；
基于所述应用日志和异常链路聚合条件对识别的异常方法调用链进行聚合，得到一个或多个异常方法调用链集；
基于所述方法故障传播链集和所述异常方法调用链集，确定故障根因信息，所述故障根因信息包括可疑方法。
2.根据权利要求1所述的方法，其特征在于，所述代码数据和所述第一提交记录信息集来源于代码仓库；所述监控平台的数据包括：所述应用日志和所述方法调用链集来源于监控平台；所述微服务系统包括所述代码仓库和所述监控平台。
3.根据权利要求1所述的方法，其特征在于，所述基于所述代码数据、第一提交记录信息集、应用日志和方法调用链集，确定方法故障传播链集包括：
对所述代码数据进行静态扫描，确定方法间的间接依赖关系；
基于所述第一提交记录信息集，确定修改方法集和每个修改方法对应的第二提交记录信息集；
基于所述方法调用链集、所述间接依赖关系、所述修改方法集和每个修改方法对应的第二提交记录信息集，确定方法故障传播链集。
4.根据权利要求3所述的方法，其特征在于，所述对所述代码数据进行静态扫描，确定方法间的间接依赖关系包括：
对所述代码数据访问的共享状态进行静态扫描，确定访问同一共享状态的不同方法具有间接依赖关系。
5.根据权利要求4所述的方法，其特征在于，所述共享状态包括：全局变量、缓存和数据库。
6.根据权利要求3所述的方法，其特征在于，所述方法故障传播链集包括直接故障传播链集和间接故障传播链集。
7.根据权利要求6所述的方法，其特征在于，所述直接故障传播链集的确定方式包括：
基于所述方法调用链集，确定方法间的直接依赖关系；
基于所述直接依赖关系、所述修改方法集和每个修改方法对应的第二提交记录信息集，确定直接故障传播链集。
8.根据权利要求7所述的方法，其特征在于，所述直接故障传播链集包括：正向故障传播链集和反向故障传播链集。
9.根据权利要求6所述的方法，其特征在于，所述间接故障传播链集的确定方式包括：
基于所述间接依赖关系、所述修改方法集和每个修改方法对应的第二提交记录信息集，确定间接故障传播链集。
10.根据权利要求1所述的方法，其特征在于，所述得到一个或多个异常方法调用链集后，所述方法还包括：
将所述应用日志与所述异常方法调用链集进行关联。
11.根据权利要求10所述的方法，其特征在于，所述识别所述方法调用链集中的异常方法调用链包括：
将调用结果中包括异常识别码和/或异常类型的方法调用链识别为异常方法调用链；和/或，
将存在调用失败的方法的方法调用链识别为异常方法调用链。
12.根据权利要求10所述的方法，其特征在于，所述异常链路聚合条件包括：聚合链路经过的方法及顺序、抛出异常的方法和异常类型均相同的异常方法调用链。
13.根据权利要求10所述的方法，其特征在于，所述方法还包括：基于正常链路聚合条件聚合正常方法调用链，得到一个或多个正常方法调用链集；
所述正常链路聚合条件包括：聚合链路经过的方法及顺序均相同的正常方法调用链。
14.根据权利要求13所述的方法，其特征在于，所述正常方法调用链集至少用于确定方法间的直接依赖关系。
15.根据权利要求10所述的方法，其特征在于，所述将所述应用日志与所述异常方法调用链集进行关联包括：
将具有相同链路标识的应用日志和异常方法调用链进行关联；
和/或，
基于时间戳和方法名，将所述应用日志与所述异常方法调用链集进行关联。
16.根据权利要求6所述的方法，其特征在于，所述基于所述方法故障传播链集和所述异常方法调用链集，确定故障根因信息包括：
基于所述方法故障传播链集和所述异常方法调用链集，确定可疑方法集和每个可疑方法对应的第三提交记录信息集；
基于所述方法调用链集、所述可疑方法集和每个可疑方法对应的第三提交记录信息集，筛选所述可疑方法集中作为故障根因的至少一个可疑方法。
17.根据权利要求16所述的方法，其特征在于，所述确定可疑方法集和每个可疑方法对应的第三提交记录信息集包括：
基于所述异常方法调用链集匹配所述方法故障传播链集，得到可疑故障传播链集；
将所述可疑故障传播链集中与所述异常方法调用链集不相关的可疑故障传播链进行滤除操作；
对所述滤除操作后得到的可疑故障传播链集，提取每个可疑故障传播链的链头方法作为可疑方法，得到可疑方法集和每个可疑方法对应的第三提交记录信息集。
18.根据权利要求17所述的方法，其特征在于，所述基于所述异常方法调用链集匹配所述方法故障传播链集，得到可疑故障传播链集包括：
若异常方法调用链上的异常方法为方法故障传播链上的方法，则确定该方法故障传播链为可疑故障传播链。
19.根据权利要求17所述的方法，其特征在于，所述与所述异常方法调用链集不相关的可疑故障传播链包括：
可疑故障传播链为直接故障传播链，且可疑故障传播链上异常方法之前和之后的方法，均未出现在异常方法调用链上，则可疑故障传播链与异常方法调用链不相关。
20.根据权利要求16所述的方法，其特征在于，所述基于所述方法调用链集、所述可疑方法集和每个可疑方法对应的第三提交记录信息集，筛选所述可疑方法集中作为故障根因的至少一个可疑方法包括：
基于所述方法调用链集，确定每个可疑方法的失败率；
基于每个可疑方法对应的第三提交记录信息集，确定每个可疑方法的代码修改总行数和第三提交信息的数量；
基于每个可疑方法的失败率、每个可疑方法的代码修改总行数和第三提交信息的数量，确定每个可疑方法的可疑率；
基于每个可疑方法的可疑率筛选所述可疑方法集中作为故障根因的至少一个可疑方法。
21.根据权利要求20所述的方法，其特征在于，所述基于所述方法调用链集，确定每个可疑方法的失败率包括：
针对每个可疑方法，确定经过所述可疑方法的所有方法调用链中异常方法调用链的数量；
基于所述异常方法调用链的数量和经过所述可疑方法的所有方法调用链的数量，确定所述可疑方法的失败率。
22.根据权利要求20所述的方法，其特征在于，基于每个可疑方法的可疑率筛选所述可疑方法集中作为故障根因的至少一个可疑方法包括：
若可疑方法数量为0，则将异常方法调用链上每个方法的失败率排序后，输出Top k的方法作为故障根因信息；
若可疑方法数量为1，则将该可疑方法作为故障根因信息；
若可疑方法数量大于1，则将可疑方法按照可疑率由大至小排序，并输出Top k个可疑方法作为故障根因信息。
23.根据权利要求20所述的方法，其特征在于，所述故障根因信息还包括可疑提交记录信息集；
基于所述间接故障传播链集、所述异常方法调用链集、每个作为故障根因的可疑方法所对应的第三提交记录信息集，确定可疑提交记录信息集。
24.根据权利要求23所述的方法，其特征在于，所述确定可疑提交记录信息集包括：
若作为故障根因的可疑方法为直接依赖故障传播链的链头方法，则基于关联应用日志的异常方法调用链集，确定所述可疑方法抛出异常的代码行；
基于所述代码行对所述可疑方法对应的第三提交记录信息集进行比对分析，得到可疑提交记录信息集，其中，所述可疑提交记录信息集中包括修改了所述代码行对应的代码的提交记录信息。
25.根据权利要求24所述的方法，其特征在于，所述方法还包括：若所述代码行是方法调用，则所述可疑提交记录信息集中还包括修改了该方法调用的参数的提交记录信息。
26.根据权利要求23所述的方法，其特征在于，所述确定可疑提交记录信息集包括：
若作为故障根因的可疑方法为间接依赖故障传播链的链头方法，则确定所述可疑方法访问或修改的共享状态；
基于所述共享状态对所述可疑方法对应的第三提交记录信息集进行比对分析，得到可疑提交记录信息集，其中，所述可疑提交记录信息集中包括修改了该共享状态的提交记录信息集。
27.根据权利要求23所述的方法，其特征在于，所述方法还包括：
确定可疑提交记录信息集中每个可疑提交记录信息对应的代码修改行数；
基于代码修改行数和修改时间进行排序，输出Top k的可疑提交记录信息作为故障根因信息。
28.根据权利要求23所述的方法，其特征在于，所述故障根因信息还包括：异常位置和异常类型。
29.根据权利要求28所述的方法，其特征在于，所述异常位置包括以下至少一个：
可疑方法抛出异常的代码行位置；
所述可疑方法所在的异常方法调用链上最后一个异常方法抛出异常的代码行位置；
访问或修改共享状态的代码行位置。
30.根据权利要求28所述的方法，其特征在于，所述异常类型包括以下至少一个：
可疑方法抛出的异常类型；
所述可疑方法所在的异常方法调用链上最后一个异常方法抛出的异常类型；
与所述可疑方法相关的异常方法抛出的异常类型；
所述异常方法所在的异常方法调用链上最后一个异常方法所抛出的异常类型。
31.根据权利要求1所述的方法，其特征在于，所述确定故障根因信息后，所述方法还包括：
展示告警消息，所述告警消息中包括所述故障根因信息。
32.一种微服务系统故障根因定位装置，其特征在于，包括：
获取模块，用于获取代码数据、第一提交记录信息集、应用日志和方法调用链集；
故障传播链确定模块，用于基于所述代码数据、第一提交记录信息集、应用日志和方法调用链集，确定方法故障传播链集；
异常调用链确定模块，用于识别所述方法调用链集中的异常方法调用链；基于所述应用日志和异常链路聚合条件对识别的异常方法调用链进行聚合，得到一个或多个异常方法调用链集；
故障根因定位模块，用于基于所述方法故障传播链集和所述异常方法调用链集，确定故障根因信息，所述故障根因信息包括可疑方法。
33.一种电子设备，其特征在于，包括：处理器和存储器；
所述处理器通过调用所述存储器存储的程序或指令，用于执行如权利要求1至31任一项所述方法的步骤。
34.一种非暂态计算机可读存储介质，其特征在于，所述非暂态计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行如权利要求1至31任一项所述方法的步骤。
CN202110349350.9A 2021-03-31 2021-03-31 微服务系统故障根因定位方法、装置、设备及存储介质 Pending CN115145751A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110349350.9A CN115145751A (zh) 2021-03-31 2021-03-31 微服务系统故障根因定位方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110349350.9A CN115145751A (zh) 2021-03-31 2021-03-31 微服务系统故障根因定位方法、装置、设备及存储介质

Publications (1)

Publication Number Publication Date
CN115145751A true CN115145751A (zh) 2022-10-04

Family

ID=83403445

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110349350.9A Pending CN115145751A (zh) 2021-03-31 2021-03-31 微服务系统故障根因定位方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN115145751A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116820826A (zh) * 2023-08-28 2023-09-29 北京必示科技有限公司 一种基于调用链的根因定位方法、装置、设备及存储介质
CN117520040A (zh) * 2024-01-05 2024-02-06 中国民航大学 一种微服务故障根因确定方法、电子设备及存储介质

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116820826A (zh) * 2023-08-28 2023-09-29 北京必示科技有限公司 一种基于调用链的根因定位方法、装置、设备及存储介质
CN116820826B (zh) * 2023-08-28 2023-11-24 北京必示科技有限公司 一种基于调用链的根因定位方法、装置、设备及存储介质
CN117520040A (zh) * 2024-01-05 2024-02-06 中国民航大学 一种微服务故障根因确定方法、电子设备及存储介质
CN117520040B (zh) * 2024-01-05 2024-03-08 中国民航大学 一种微服务故障根因确定方法、电子设备及存储介质

Similar Documents

Publication Publication Date Title
Lo et al. SMArTIC: Towards building an accurate, robust and scalable specification miner
Liblit et al. Scalable statistical bug isolation
Neuhaus et al. Predicting vulnerable software components
US9483387B1 (en) Tree comparison functionality for services
US7614043B2 (en) Automated product defects analysis and reporting
CN107391369B (zh) 一种基于数据筛选和数据过采样的跨项目缺陷预测方法
US8607198B2 (en) Cross-concern code coverage assessment
US8661125B2 (en) System comprising probe runner, monitor, and responder with associated databases for multi-level monitoring of a cloud service
Elsner et al. Empirically evaluating readily available information for regression test optimization in continuous integration
US20060253837A1 (en) Using a call stack hash to record the state of a process
US20110066908A1 (en) Similarity detection for error reports
US20200348995A1 (en) Fault analysis and prediction using empirical architecture analytics
US20210182389A1 (en) Discrete Processor Feature Behavior Collection
Tan et al. Assessing software quality by program clustering and defect prediction
CN115145751A (zh) 微服务系统故障根因定位方法、装置、设备及存储介质
US10365995B2 (en) Composing future application tests including test action data
US20030125904A1 (en) Log analysis method and recording medium storing log analysis program
CN111859047A (zh) 一种故障解决方法及装置
US20200310952A1 (en) Comparable user interface object identifications
Pan et al. Continuous test suite failure prediction
Al-Sabbagh et al. Selective regression testing based on big data: comparing feature extraction techniques
US8478575B1 (en) Automatic anomaly detection for HW debug
US11790249B1 (en) Automatically evaluating application architecture through architecture-as-code
Maiga et al. An empirical study on the handling of crash reports in a large software company: An experience report
Zhang et al. Does socio-technical congruence have an effect on continuous integration build failures? An empirical study on 10 GitHub projects

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20240310

Address after: # 03-06, Lai Zan Da Building 1, 51 Belarusian Road, Singapore

Applicant after: Alibaba Innovation Co.

Country or region after: Singapore

Address before: Room 01, 45th Floor, AXA Building, 8 Shanton Road

Applicant before: Alibaba Singapore Holdings Ltd.

Country or region before: Singapore