CN114598539A - 根因定位方法、装置、存储介质及电子设备 - Google Patents

根因定位方法、装置、存储介质及电子设备 Download PDF

Info

Publication number
CN114598539A
CN114598539A CN202210261913.3A CN202210261913A CN114598539A CN 114598539 A CN114598539 A CN 114598539A CN 202210261913 A CN202210261913 A CN 202210261913A CN 114598539 A CN114598539 A CN 114598539A
Authority
CN
China
Prior art keywords
service
abnormal
dependent
detection information
equipment
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.)
Granted
Application number
CN202210261913.3A
Other languages
English (en)
Other versions
CN114598539B (zh
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.)
Jingdong Technology Information Technology Co Ltd
Original Assignee
Jingdong Technology Information Technology Co 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 Jingdong Technology Information Technology Co Ltd filed Critical Jingdong Technology Information Technology Co Ltd
Priority to CN202210261913.3A priority Critical patent/CN114598539B/zh
Publication of CN114598539A publication Critical patent/CN114598539A/zh
Application granted granted Critical
Publication of CN114598539B publication Critical patent/CN114598539B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425Traffic logging, e.g. anomaly detection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0677Localisation of faults

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Debugging And Monitoring (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本公开涉及计算机处理领域,具体涉及根因定位方法、根因定位装置、存储介质及电子设备。该根因定位方法包括:在基于设备调用对中被调用的服务设备的调用指标数据进行服务异常检测得到结果为服务异常时,获取服务异常检测信息;基于服务异常检测信息中异常服务设备对应的依赖设备的依赖指标数据进行依赖异常检测得到依赖异常检测信息;根据服务异常检测信息和依赖异常检测信息构建异常属性图;在存在多个异常服务设备时,利用异常属性图计算各异常服务设备的根因分值,并基于各异常服务设备的根因分值进行排序得到服务设备根因排序结果。本公开提供的根因定位方法能够准确、快速地进行***中设备的故障根因定位。

Description

根因定位方法、装置、存储介质及电子设备
技术领域
本公开涉及计算机处理领域,具体涉及根因定位方法、根因定位装置、存储介质及电子设备。
背景技术
服务***异常可能是由多方面原因造成,有的时候是因为网络的抖动,有的时候是因为机器的故障,有的时候甚至是因为人为的变更。因此,有效的根因定位可以更好地进行异常追溯,快速定位问题。
随着人工智能的飞速发展,越来越多的机器学习算法应用于故障定位中。在实际应用中,可以通过对数据进行处理,利用归纳算法生成可读的规则和决策树,然后使用决策树对新数据进行分析,但是随着软硬件的更新、业务规模的增长,会导致分析规则失效,归纳算法生成可读的规则和决策树需要不断地迭代更新,更加剧了根本原因定位的难度。
需要说明的是,在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解,因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。
发明内容
本公开的目的在于提供一种根因定位方法、根因定位装置、存储介质及电子设备,旨在解决准确、快速地进行***中设备的故障根因定位问题。
本公开的其他特性和优点将通过下面的详细描述变得显然,或部分地通过本公开的实践而习得。
根据本公开实施例的一方面,提供了一种根因定位方法,包括:在基于设备调用对中被调用的服务设备的调用指标数据进行服务异常检测得到结果为服务异常时,获取服务异常检测信息;基于所述服务异常检测信息中异常服务设备对应的依赖设备的依赖指标数据进行依赖异常检测得到依赖异常检测信息;在根据所述服务异常检测信息和所述依赖异常检测信息确定存在多个异常服务设备或一个异常服务设备对应多个异常依赖设备时,根据所述服务异常检测信息和所述依赖异常检测信息构建异常属性图;在存在多个异常服务设备时,利用所述异常属性图计算各所述异常服务设备的根因分值,并基于各所述异常服务设备的根因分值进行排序得到服务设备根因排序结果。
根据本公开的一些实施例,基于前述方案,所述根据所述服务异常检测信息和所述依赖异常检测信息构建异常属性图,包括:获取检测到服务异常时的当前业务标识,并基于所述当前业务标识提取当前业务的业务属性图;根据所述服务异常检测信息和所述依赖异常检测信息从所述业务属性图中提取目标信息以构建所述异常属性图。
根据本公开的一些实施例,基于前述方案,所述方法还包括:预先构建业务标识对应的业务属性图,所述预先构建业务标识对应的业务属性图,包括:获取预先构建的***调用关系图;其中,所述***调用关系图包括根据***中服务设备以及所述服务设备对应的依赖设备配置的节点,以及根据所述服务设备与所述依赖设备的依赖关系构建的所述节点之间的依赖有向边;以及基于业务标识获取该业务标识对应的调用链路信息,并根据所述调用链路信息中所述服务设备之间的调用关系构建所述节点之间的调用有向边;将所述调用有向边添加至所述***调用关系图中得到所述业务标识对应的业务属性图。
根据本公开的一些实施例,基于前述方案,所述根据所述服务异常检测信息和所述依赖异常检测信息从所述业务属性图中提取目标信息以构建所述异常属性图,包括:根据所述服务异常检测信息从所述业务属性图中提取目标服务有向边和目标服务节点;以及根据所述依赖异常检测信息从所述业务属性图中提取目标依赖有向边和目标依赖节点;基于所述目标服务有向边、所述目标服务节点、所述目标依赖有向边和所述目标依赖节点构建所述异常属性图。
根据本公开的一些实施例,基于前述方案,所述服务异常检测信息包括异常设备调用对和异常服务设备;其中,所述异常服务设备为所述异常设备调用对中被调用的服务设备;所述根据所述服务异常检测信息从所述业务属性图中提取目标服务有向边和目标服务节点,包括:基于所述服务异常检测信息中的异常设备调用对提取所述目标服务有向边;以及基于所述服务异常检测信息中的异常服务设备提取所述目标服务节点。
根据本公开的一些实施例,基于前述方案,所述依赖异常检测信息包括异常设备依赖对和异常依赖设备;其中,所述异常依赖设备为所述异常设备依赖对中的依赖设备;所述根据所述依赖异常检测信息从所述业务属性图中提取目标依赖有向边和目标依赖节点,包括:基于所述依赖异常检测信息中的异常设备依赖对提取所述目标依赖有向边;以及基于所述依赖异常检测信息中的异常依赖设备提取所述目标依赖节点。
根据本公开的一些实施例,基于前述方案,所述利用所述异常属性图计算各所述异常服务设备的根因分值,包括:计算所述异常属性图中有向边的权重;其中,所述有向边包括异常调用有向边和异常依赖有向边;基于所述有向边的权重计算所述异常属性图中异常服务节点的根因分值,以得到所述异常服务节点对应的异常服务设备的根因分值。
根据本公开的一些实施例,基于前述方案,所述计算所述异常属性图中有向边的权重,包括:在所述有向边为异常服务有向边且所述有向边对应的两个节点包括一个异常服务节点和一个正常服务节点时,基于所述有向边对应的异常服务节点的响应时间和平均异常响应时间计算所述有向边的权重;以及在所述有向边为异常服务有向边且所述有向边对应的两个节点均为异常服务节点时,将所述有向边的权重配置为预设值;在所述有向边为异常依赖有向边时,基于所述有向边对应的异常服务节点的平均异常响应时间和所述有向边对应的异常依赖节点的资源利用率计算所述有向边的权重。
根据本公开的一些实施例,基于前述方案,所述基于所述有向边的权重计算所述异常属性图中异常服务节点的根因分值,包括:基于所述异常服务节点的平均响应时间、所述异常服务节点依赖的异常依赖节点的资源利用率以及所述异常服务节点对应的异常有向边的权重计算该异常服务节点的根因分值。
根据本公开的一些实施例,基于前述方案,所述方法还包括:在确定一个异常服务设备对应多个异常依赖设备时,基于各异常依赖设备分别对应的依赖指标数据计算各异常依赖设备的根因分值;基于各异常依赖设备的根因分值进行排序得到该异常服务设备的异常依赖设备根因排序结果。
根据本公开的一些实施例,基于前述方案,所述方法还包括:在异常依赖设备的依赖指标数据中包括多个依赖指标时,基于各依赖指标分别对应的指标值计算各依赖指标的根因分值;基于各依赖指标的根因分值进行排序得到该异常依赖设备的依赖指标根因排序结果。
根据本公开实施例的第二方面,提供了一种根因定位装置,包括:服务检测模块,用于在基于设备调用对中被调用的服务设备的调用指标数据进行服务异常检测得到结果为服务异常时,获取服务异常检测信息;依赖检测模块,用于基于所述服务异常检测信息中异常服务设备对应的依赖设备的依赖指标数据进行依赖异常检测得到依赖异常检测信息;属性图构建模块,用于在根据所述服务异常检测信息和所述依赖异常检测信息确定存在多个异常服务设备或一个异常服务设备对应多个异常依赖设备时,根据所述服务异常检测信息和所述依赖异常检测信息构建异常属性图;根因定位模块,在存在多个异常服务设备时,利用所述异常属性图计算各所述异常服务设备的根因分值,并基于各所述异常服务设备的根因分值进行排序得到服务设备根因排序结果。
根据本公开实施例的第三方面,提供了一种计算机可读存储介质,其上存储有计算机程序,所述程序被处理器执行时实现如上述实施例中的根因定位方法。
根据本公开实施例的第四方面,提供了一种电子设备,其特征在于,包括:一个或多个处理器;存储装置,用于存储一个或多个程序,当所述一个或多个程序被所述一个或多个处理器执行时,使得所述一个或多个处理器实现如上述实施例中的根因定位方法。
本公开示例性实施例可以具有以下部分或全部有益效果:
在本公开的一些实施例所提供的技术方案中,在基于服务设备的指标数据检测到服务异常时,便获取服务异常检测信息以及依赖异常检测信息,进而根据依赖异常检测信息和依赖异常检测信息构建异常属性图,最后对异常属性图进行根因节点分析得到最终的异常根因排序结果。通过本公开提供的根因定位方法,一方面能够在检测到服务异常时不仅获取服务异常检测信息,还对异常服务设备对应的依赖设备进行依赖检测得到依赖异常检测信息,进而从服务设备一级依赖设备承载关系的全局考量出发,能够更加深入地挖掘异常存在的底层问题,根因定位准确率更高;另一方面,通过构建异常属性图,再基于异常属性图进行根因节点分析,能够将根因定位转换为基于属性图的异常节点挖掘得到排序结果,简化根因定位步骤,加快定位时间,进而帮助运维人员更快地进行故障排查。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本公开的实施例,并与说明书一起用于解释本公开的原理。显而易见地,下面描述中的附图仅仅是本公开的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。在附图中:
图1示意性示出本公开示例性实施例中一种根因定位方法的流程示意图;
图2示意性示出本公开示例性实施例中一种响应时间的检测结果示意图;
图3示意性示出本公开示例性实施例中一种构建异常属性图方法的流程示意图;
图4示意性示出本公开示例性实施例中一种***调用关系图的示意图;
图5示意性示出本公开示例性实施例中一种业务属性图的示意图;
图6示意性示出本公开示例性实施例中一种异常属性图的示意图;
图7示意性示出本公开示例性实施例中一种计算异常服务设备根因分值方法的示意图;
图8示意性示出本公开示例性实施例中一种异常属性图计算结果的示意图;
图9示意性示出本公开示例性实施例中一种根因定位装置的组成示意图;
图10示意性示出本公开示例性实施例中一种计算机可读存储介质的示意图;
图11示意性示出本公开示例性实施例中一种电子设备的计算机***的结构示意图。
具体实施方式
现在将参考附图更全面地描述示例实施方式。然而,示例实施方式能够以多种形式实施,且不应被理解为限于在此阐述的范例;相反,提供这些实施方式使得本公开将更加全面和完整,并将示例实施方式的构思全面地传达给本领域的技术人员。
此外,所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中,提供许多具体细节从而给出对本公开的实施例的充分理解。然而,本领域技术人员将意识到,可以实践本公开的技术方案而没有特定细节中的一个或更多,或者可以采用其它的方法、组元、装置、步骤等。在其它情况下,不详细示出或描述公知方法、装置、实现或者操作以避免模糊本公开的各方面。
附图中所示的方框图仅仅是功能实体,不一定必须与物理上独立的实体相对应。即,可以采用软件形式来实现这些功能实体,或在一个或多个硬件模块或集成电路中实现这些功能实体,或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
附图中所示的流程图仅是示例性说明,不是必须包括所有的内容和操作/步骤,也不是必须按所描述的顺序执行。例如,有的操作/步骤还可以分解,而有的操作/步骤可以合并或部分合并,因此实际执行的顺序有可能根据实际情况改变。
传统的故障根因定位方法有监控警告和日志分析两种。其中,从监控告警角度发现问题的流程一般是运维工程师收到告警后,查看Dashboard(business intelligencedashboard,BI dashboard,商业智能仪表盘)大屏幕,根据排查问题的经验,查看可能与故障相关的数据,缩小范围,经过对框选的范围一步一步排查,最终定位故障点。而基于日志分析的问题定位技术主要是因为问题出现过会留下与其对应的日志,从CMDB(Configuration Management Database,配置管理数据库)中拿到服务/***间的调用关系,可以将单个请求的链路访问过程展示出来,有助于对问题进行定位。
但传统的故障定位技术非常依赖人的经验,一方面,随着软硬件的更新、业务规模的增长,会导致分析规则失效,经验总结的规则可能会失效;另一方面,这些代表经验或知识的规则显然是隐含的,很难被人为地总结成基于显式规则的专家***。同时传统方法的故障检测手段单一,故障定位繁琐,排障过程耗时长。
随着人工智能的火热,越来越多的机器学习算法替代传统方法应用于故障定位,例如基于关联规则的相关性分析和基于决策树的故障诊断。关联规则(Apriori算法)挖掘是一种基于规则的机器学习算法,它的目的是利用一些度量指标来分辨数据集中存在的强规则,主要根据最小支持度阈值找出数据集DB中的所有频繁项集,利用频繁项集构造出满足用户最小置信度的规则。也可以通过对数据进行处理,利用归纳算法生成可读的规则和决策树,当某个应用发生告警时,通过其决策树判断逻辑对其根因定位。
基于关联规则和决策树算法的故障定位而在微服务根因定位中,服务之间的依赖关系比传统的分布式***复杂得多,一项服务的性能下降可以广泛传播并引起多个警报,现有的关联规则技术难以挖掘其强规则,同时监控指标数量非常多,如果将所有这些指标都用于性能问题诊断,将会造成很大的开销,从而难以定位根本原因。决策树算法需要运维专家花好久时间慢慢梳理一套规则,人力成本高,而且也不一定会比算法几个小时训练的模型效果好,再加上微服务频繁更新,更加剧了根本原因定位的难度。
因此,针对现有技术中存在的问题,本公开提供了一种根因定位方法,通过对服务设备进行异常检测,并在异常时构建实时的属性图,将根因定位问题转化为对属性图上异常节点的挖掘,进而得到异常根因排序结果,用于提高排查故障的效率。
以下对本公开实施例的技术方案的实现细节进行详细阐述。
图1示意性示出本公开示例性实施例中一种根因定位方法的流程示意图。如图1所示,该根因定位方法包括步骤S101至步骤S104:
步骤S101,在基于设备调用对中被调用的服务设备的调用指标数据进行服务异常检测得到结果为服务异常时,获取服务异常检测信息;
步骤S102,基于所述服务异常检测信息中异常服务设备对应的依赖设备的依赖指标数据进行依赖异常检测得到依赖异常检测信息;
步骤S103,在根据所述服务异常检测信息和所述依赖异常检测信息确定存在多个异常服务设备或一个异常服务设备对应多个异常依赖设备时,根据所述服务异常检测信息和所述依赖异常检测信息构建异常属性图;
步骤S104,在存在多个异常服务设备时,利用所述异常属性图计算各所述异常服务设备的根因分值,并基于各所述异常服务设备的根因分值进行排序得到服务设备根因排序结果。
在本公开的一些实施例所提供的技术方案中,在基于服务设备的指标数据检测到服务异常时,便获取服务异常检测信息以及依赖异常检测信息,进而根据依赖异常检测信息和依赖异常检测信息构建异常属性图,最后对异常属性图进行根因节点分析得到最终的异常根因排序结果。通过本公开提供的根因定位方法,一方面能够在检测到服务异常时不仅获取服务异常检测信息,还对异常服务设备对应的依赖设备进行依赖检测得到依赖异常检测信息,进而从服务设备一级依赖设备承载关系的全局考量出发,能够更加深入地挖掘异常存在的底层问题,根因定位准确率更高;另一方面,通过构建异常属性图,再基于异常属性图进行根因节点分析,能够将根因定位转换为基于属性图的异常节点挖掘得到排序结果,简化根因定位步骤,加快定位时间,进而帮助运维人员更快地进行故障排查。
下面,将结合附图及实施例对本示例实施方式中的根因定位方法的各个步骤进行更详细的说明。
在步骤S101中,在基于设备调用对中被调用的服务设备的调用指标数据进行服务异常检测得到结果为服务异常时,获取服务异常检测信息。
在本公开的一个实施例中,当***在执行业务时会调用多个服务设备,可记为节点,服务设备节点可以是微服务或***的服务器。
服务异常检测是实时进行的,每一次检测可以基于当前检测时间,可以通过数据收集模块获取该时间之前的预设时间范围内的历史调用数据进行检测,例如拉取15分钟或半小时的数据以进行检测。
服务异常检测是以设备调用对为单元来检测的,这样可以清楚该次调用的起点和终点,设备调用对包含了一对服务设备,分别为调用的服务设备和被调用的服务设备。同时,在异常检测时是基于被调用的服务设备的调用指标数据来进行检测,调用指标数据可以是被调用的服务设备的响应时间。以[节点1]调用[节点2]([节点1]→[节点2])为例,即基于节点2的响应时间进行检测。
图2示意性示出本公开示例性实施例中一种响应时间的检测结果示意图。参考图2所示,其中横轴代表时间,纵轴代表该服务设备的响应时间,根据图2中响应时间的检测结果,发现响应时间有突增的现象,即可认为服务异常。
具体地,可以对被调用的服务设备的响应时间进行BIRCH(Balanced IterativeReducing and Clustering using Hierarchies,综合层次聚类)算法快速异常检测。BIRCH算法比较适合于数据量大,类别数K也比较多的情况。BIRCH算法的层次聚类思想近似地计算weight(权重)的BirchOut算法,以降低其复杂度,同时利用挖掘孤立点的思想对每个节点做异常检测。
当基于BIRCH算法检测到服务设备的响应时间异常时,记录当前的设备调用对为异常设备调用对,并且将该服务设备标记为异常服务设备。接着通过异常时执行的业务标识,即日志中记录的trace_id获取多个服务设备之间的访问记录,同样采用上述方法就可以得到此次异常检测的所有异常设备调用对和异常服务设备得到服务异常检测信息。
在步骤S102中,基于所述服务异常检测信息中异常服务设备对应的依赖设备的依赖指标数据进行依赖异常检测得到依赖异常检测信息。
在本公开的一个实施例中,当确定了异常服务设备之后,还可以对该异常服务设备所依赖的设备进行依赖异常检测。
其中,依赖设备是指承载服务设备[节点]的设备,可记为[基础资源(主机/数据库/中间件等)]。不同的服务设备[节点]所依赖的设备存在不同,所以依赖设备可以是主机、数据库或者中间件。
依赖异常检测是基于依赖设备的依赖指标数据实现,不同的依赖设备检测的指标也有所不同。当依赖设备为主机时,检测的依赖指标数据可以是CPU(Central ProcessingUnit,中央处理器)、内存、负载、IO性能、磁盘空间、线程数、连接数、进程数等一种或多种;当依赖设备为数据库时,检测的依赖指标数据可以是慢SQL、表空间使用率等;当依赖设备为主机时,检测的依赖指标数据可以是TPS(Transactions Per Second,每秒传输事物处理个数)、内存使用率、key总量、流入总量、流出总量等。
在基于依赖指标数据进行依赖异常检测时,与服务异常检测类似,通过数据收集模块收集各依赖设备的依赖指标数据,然后也是基于设备依赖对进行检测,一对设备依赖对中包括异常服务设备以及该异常服务设备所依赖的依赖设备。
在检测到依赖异常时,将该设备依赖对标记为异常设备依赖对,并将该异常设备依赖对中的依赖设备标记为异常依赖设备,进而得到依赖异常检测信息。
需要说明的是,在进行依赖异常检测,可能存在该异常设备所依赖的设备没有问题,也就是表示该异常可能是由于服务设备本身存在的问题。所以依赖异常检测信息中不一定包括每一个服务设备依赖异常检测结果。
在步骤S103中,在根据所述服务异常检测信息和所述依赖异常检测信息确定存在多个异常服务设备或一个异常服务设备对应多个异常依赖设备时,根据所述服务异常检测信息和所述依赖异常检测信息构建异常属性图。
在本公开的一个实施例中,当存在多个异常服务设备或者一个异常服务设备对应多个异常依赖设备时,需要构建检测到当前异常时对应的异常属性图。这是因为如果存在多个异常设备(服务设备节点/依赖设备基础资源(主机、数据库、中间件等))时需要确定各设备的根因分数来进行根因重要性的排序。
异常属性图是一个有向图,包括节点以及节点之间的有向边,也就是将所有产生异常的路径用属性图的方式展示出来。其中节点表示的是异常的设备,也就是根据服务异常检测信息和依赖异常检测信息中确定的异常服务设备节点和异常依赖设备基础资源(主机、数据库、中间件等);节点之间的有向边可以根据异常设备调用对以及异常设备依赖对确定。
在步骤S104中,在存在多个异常服务设备时,利用所述异常属性图计算各所述异常服务设备的根因分值,并基于各所述异常服务设备的根因分值进行排序得到服务设备根因排序结果。
在本公开的一个实施例中,当构建了包括服务异常检测信息和依赖异常检测信息的异常属性图之后,根因定位就转换为了对异常属性图的信息挖掘。
异常属性图中包括多个节点,以及各节点之间的有向边,可以根据检测到的指标定义各有向边的权重以及各节点的分值,从而能够根据权重和分值利用图算法以及多维加权评分排序算法等方法实现异常服务设备对应异常节点的异常重要性排序,最终得到服务设备根因排序结果作为根因分析的结果,能够帮助运维人员快速定位异常服务。
例如确定了一个业务中的异常服务设备有[节点2]、[节点3]、[节点4],那么得到节点的重要程度由高到低的排序结果可以是[节点4]-[节点2]-[节点3],也就是说[节点4]的根因重要程度最高。
在本公开的一个实施例中,在步骤S103中,所述根据所述服务异常检测信息和所述依赖异常检测信息构建异常属性图,包括:获取检测到服务异常时的当前业务标识,并基于所述当前业务标识提取当前业务的业务属性图;根据所述服务异常检测信息和所述依赖异常检测信息从所述业务属性图中提取目标信息以构建所述异常属性图。
具体地,异常属性图可以从完整的业务属性图提取得来,因此为了能够得到异常属性图,还需要预先根据***调用关系图构建业务属性图。
图3示意性示出本公开示例性实施例中一种构建异常属性图方法的流程示意图。参考图3所示,构建异常属性图方法的步骤主要包括:
步骤S301,获取检测到服务异常时的当前业务标识,并基于所述当前业务标识提取当前业务的业务属性图;
步骤S302,根据所述服务异常检测信息和所述依赖异常检测信息从所述业务属性图中提取目标信息以构建所述异常属性图。
接下来,结合具体的实施例对上述步骤进行详细说明。需要说明的是在步骤S301中需要获取业务属性图,因此,该方法还包括步骤S300,预先构建业务标识对应的业务属性图;
在步骤S300中,所述预先构建业务标识对应的业务属性图,包括:
步骤S3001,获取预先构建的***调用关系图。具体来说,***调用关系图可以表示***中各服务设备,以及各服务设备对应依赖设备的承载关系。
在本公开的一个实施例中,***调用关系图可以在***形成时预先构建,以此节省根因定位的时间。可以通过数据收集模块对***中的服务设备以及依赖设备额承载关系进行分析,将***中的服务设备和依赖设备用节点表示,之后再根据服务设备的依赖关系建立节点之间的连接,由服务设备指向依赖设备形成有向边得到拓扑图作为***调用关系图。
图4示意性示出本公开示例性实施例中一种***调用关系图的示意图。参考图4所示,圆形节点表示服务设备[节点],方向节点表示依赖设备[基础资源(主机/数据库/中间件等)]。该***中一共包括[节点1]~[节点5]共5个设备[节点],其中,[节点1]、[节点3]、[节点5]依赖于[基础资源1(主机/数据库/中间件等)],所以它们都指向[基础资源1(主机/数据库/中间件等)],[节点2]和[节点4]依赖于[基础资源2(主机/数据库/中间件等)],所以它们都指向[基础资源2(主机/数据库/中间件等)]。
需要说明的是,一个***中可能包括一个或多个服务设备,每一个服务设备也可能依赖一个或多个依赖设备,一个依赖设备也可能承载着一个或多个服务设备。
步骤S3002,基于业务标识获取该业务标识对应的调用链路信息,并根据所述调用链路信息中所述服务设备之间的调用关系构建所述节点之间的调用有向边。
具体地,不同的业务对应着不同的业务属性图。在***执行业务时,会为该业务创建一个业务标识,即trace_id,之后可以通过***的运营日志中记录的trace_id获取相应的调用链路信息,即在执行该业务时服务设备之间的调用关系。
根据调用链路信息中服务设备之间的调用关系,由调用设备指向被调用设备即可构成业务属性图中的调用有向边。
步骤S3003,将所述调用有向边添加至所述***调用关系图中得到所述业务标识对应的业务属性图。
具体地,根据确定的调用有向边在***调用关系图中找到对应的节点进行添加,进而得到业务属性图,同时创建该业务标识与业务属性图之间的关系。
需要说明的是,***调用关系图和业务属性图的构建时机可以根据需求设置。一种如上述实施例中介绍,可以根据***搭建完成时便构建***调用关系图,或者是在创建业务标识后建立对应的业务属性图,但果然也可以在检测到异常需要进行根因定位时再实时构建,以节省资源占用,本公开在此不做具体限定。
图5示意性示出本公开示例性实施例中一种业务属性图的示意图。例如该业务的调用链路信息为[节点1]→[节点2]&[节点3]、[节点2]→[节点3]&[节点4]、[节点3]→[节点5],构建的业务属性图如图5所示,在***调用关系图增加了[节点1]→[节点2]、[节点1]→[节点3]、[节点2]→[节点3]、[节点2]→[节点4]、[节点3]→[节点5]的有向边。
在步骤S301中,获取检测到服务异常时的当前业务标识,并基于所述当前业务标识提取当前业务的业务属性图。
在本公开的一个实施例中,不同的trace_id对应其预先构建的业务属性图。所以可以确定检测为异常时对应的业务标识trace_id,然后基于trace_id提取相应的业务属性图。
在步骤S302中,所述根据所述服务异常检测信息和所述依赖异常检测信息从所述业务属性图中提取目标信息以构建所述异常属性图,包括:
步骤S3021,根据所述服务异常检测信息从所述业务属性图中提取异常服务有向边和异常服务节点。
具体来说,服务异常检测信息包括异常设备调用对和异常服务设备,异常服务设备也就是异常设备调用对中被调用的服务设备。在提取目标信息时,根据异常设备调用对可以提取目标服务有向边;根据异常服务设备可以提取目标服务节点。
步骤S3022,根据所述依赖异常检测信息从所述业务属性图中提取异常依赖有向边和异常依赖节点。
具体来说,依赖异常检测信息包括异常设备依赖对和异常依赖设备,异常依赖设备也就是异常设备依赖对中的依赖设备。在提取目标信息时,根据异常设备依赖对可以提取目标依赖有向边;根据异常依赖设备可以提取目标依赖节点。
步骤S3023,基于所述目标服务有向边、所述目标服务节点、所述目标依赖有向边和所述目标依赖节点构建所述异常属性图。
图6示意性示出本公开示例性实施例中一种异常属性图的示意图。在本实施例中服务异常检测信息为[节点1]→[节点2]、[节点2]→[节点3]、[节点2]→[节点4]调用异常,依赖异常检测信息为[节点3]→[基础资源1(主机/数据库/中间件等)]、[节点2]→[基础资源2(主机/数据库/中间件等)]、[节点4]→[基础资源2(主机/数据库/中间件等)]依赖异常,得到的异常属性图如图6所示。
需要说明的是,在提取出的异常属性图中的节点不一定全是异常节点,参考图6所示,根据检测结果[节点1]→[节点2]调用异常,但[节点1]节点本身是正常的,只是在调用时出现了异常,所以为了标识调用的源设备,还需要将正常的节点[节点1]提取出来。可以在异常属性图中将正常节点和异常节点区别表示,例如采用不同的边框颜色、填充颜色或者线型的等等用于区别。
图7示意性示出本公开示例性实施例中一种计算异常服务设备根因分值方法的示意图。参考图7所示,所述利用所述异常属性图计算各所述异常服务设备的根因分值,包括:
步骤S701,计算所述异常属性图中有向边的权重;其中,所述有向边包括异常调用有向边和异常依赖有向边;
步骤S702,基于所述有向边的权重计算所述异常属性图中异常服务节点的根因分值,以得到所述异常服务节点对应的异常服务设备的根因分值。
在本公开的一个实施例中,异常属性图中包括两种类型的有向边:一种是根据服务异常检测信息确定的异常服务有向边,这其中又分为两种情况,两个异常服务节点之间以及正常服务节点和异常服务节点之间;而另一种是根据异常依赖检测信息确定的异常依赖有向边,这三种有向边的权重计算方式不同。
因此,在步骤S701中,所述计算所述异常属性图中有向边的权重,包括:
在所述有向边为异常服务有向边且所述有向边对应的两个节点包括一个异常服务节点和一个正常服务节点时,基于所述有向边对应的异常服务节点的响应时间和平均异常响应时间计算所述有向边的权重。
具体来说,异常服务节点和正常服务节点之间的权重记为wn。wn是该有向边对应的调用对中异常服务节点的响应时间以及该异常服务节点的平均响应时间这两个指标之间的相关性系数。其中,异常服务节点的平均响应时间可以根据历史响应数据计算得到,是一个常数。相关性系数表示两个指标异常变化的相关性,系数值越高,则一起出现异常的概率越大。
计算相关性系数时,可以根据一段时间范围内,不同时间点,两个指标的异常检测标签取值为0或者1,组成的两个序列,计算皮尔逊相关系数。
在所述有向边为异常服务有向边且所述有向边对应的两个节点均为异常服务节点时,将所述有向边的权重配置为预设值。
具体来说,两个异常服务节点之间的权重会设置一个预设值,可以记为wa
在所述有向边为异常依赖有向边时,基于所述有向边对应的异常服务节点的平均异常响应时间和所述有向边对应的异常依赖节点的资源利用率计算所述有向边的权重。
具体来说,异常依赖有向边的权重记为wh。wh也是需要计算两个指标之间的相关性系数,两个指标即异常服务节点的平均响应时间以及异常依赖节点的资源利用率。其中,异常依赖节点的资源利用率可以通过数据收集模块预先得到。
在步骤S702中,基于所述有向边的权重计算所述异常属性图中异常服务节点的根因分值,包括:基于所述异常服务节点的平均响应时间、所述异常服务节点依赖的异常依赖节点的资源利用率以及所述异常服务节点对应的异常有向边的权重计算该异常服务节点的根因分值。
具体地,异常服务设备在异常属性图中表示为异常服务节点,因此节点的根因分值即为该设备的根因分值。
由于异常服务设备[节点]的异常根因分值时,由于服务设备[节点]的异常会受到依赖设备[基础资源(主机/数据库/中间件等)]的影响,所以将异常[节点]的分值计算转换为求异常服务[节点]的平均异常响应时间与其依赖的依赖设备[基础资源(主机/数据库/中间件等)]之间的最大相关系数,同时考虑该异常服务设备[节点]对应的有向边的权重,进行加权求和得到[节点]的根因分值。
图8示意性示出本公开示例性实施例中一种异常属性图计算结果的示意图。参考图8所示,正常节点1采用虚线线框表示,其余异常节点采用深色半填充,可以得到各有向边的权重信息:[节点1]→[节点2]调用出现异常,其中[节点1]节点正常,[节点2]节点异常,因此[节点1]→[节点2]的边权重表示为wn;[节点2]→[节点3]、[节点2]→[节点4]调用出现异常,且[节点2]、[节点3]、[节点4]节点均异常,所以它们的边权重都表示为wa;[节点3]→[基础资源1(主机/数据库/中间件等)]、[节点2]→[基础资源2(主机/数据库/中间件等)]、[节点4]→[基础资源2(主机/数据库/中间件等)]依赖异常,则它们的边权重都表示为wh。同时可以根据各有向边的权重信息计算各异常服务节点的根因分值,分别表示为Aps2、Aps3、Aps4
在本公开的一个实施例中,所述方法还包括:在一个异常服务设备对应多个异常依赖设备时,基于各异常依赖设备分别对应的依赖指标数据计算各异常依赖设备的根因分值;基于各异常依赖设备的根因分值进行排序得到该异常服务设备的异常依赖设备根因排序结果。
具体地,如果根据依赖异常检测信息得到一个异常服务设备依赖的多个依赖设备都存在依赖异常,那么可以计算各异常依赖设备的根因分值进行排序,以得到异常依赖设备根因排序结果。
在计算异常依赖设备[基础资源(主机/数据库/中间件等)]的根因分值时,可以将同一[基础资源(主机/数据库/中间件等)]的多个依赖指标数据同时输入iForest(Isolation Forest,孤立森林)算法计算,从多个维度诊断异常,返回[基础资源(主机/数据库/中间件等)]当前检测点的根因分值。
之后将根因分值由高到底进行排序得到异常依赖设备根因排序结果,分值最高表示重要程度越高。例如[节点4]节点依赖于[基础资源2(主机/数据库/中间件等)]、[基础资源3(主机/数据库/中间件等)]设备都存在异常,得到节点的重要程度由高到低的排序结果可以是[基础资源2(主机/数据库/中间件等)]-[基础资源3(主机/数据库/中间件等)],也就是说节点[基础资源2(主机/数据库/中间件等)]的根因重要程度最高。
在本公开的一个实施例中,所述方法还包括:在异常依赖设备的依赖指标数据中包括多个依赖指标时,基于各依赖指标分别对应的指标值计算各依赖指标的根因分值;基于各依赖指标的根因分值进行排序得到该异常依赖设备的依赖指标根因排序结果。
具体地,如果根据依赖异常检测信息得到异常依赖设备存在多个异常指标时,可以计算各指标的根因分值进行排序,以得到指标根因排序结果。
基于前述方法可以知道不同的依赖设备检测的依赖指标有所不同,检测时会进行多项依赖指标的检测,根据依赖异常检测信息可以得到依赖异常时对应的异常指标。因此,可以将[基础资源(主机/数据库/中间件等)]的每个指标单独输入iForest算法计算,从指标自身维度诊断异常,返回[基础资源(主机/数据库/中间件等)]对应的单个指标的当前检测点的根因分值,以用于排序。
本公开提供的根因定位方法可以在根据检测结果判断在需要进行根因定位时,基于日志中的trace_id将复杂的服务/***间的调用和依赖关系转化为图数据,构建实时的异常属性图,定义节点和边的权重,最终实现对异常服务节点、异常依赖设备以及异常依赖指标进行根因排序,进行根因汇总聚合。进而解决告警滞后、无效告警繁多,静态配置繁琐,从故障发生到故障定位整个过程耗时较长等问题,并且可以解决服务/***间复杂调用场景故障发生排查时间慢,故障排查问题难,故障排查流程繁琐的问题。
图9示意性示出本公开示例性实施例中一种根因定位装置的组成示意图,如图9所示,该根因定位装置900可以包括服务检测模块901、依赖检测模块902、属性图构建模块903以及根因定位模块904。其中:
服务检测模块901,用于在基于设备调用对中被调用的服务设备的调用指标数据进行服务异常检测得到结果为服务异常时,获取服务异常检测信息;
依赖检测模块902,用于基于所述服务异常检测信息中异常服务设备对应的依赖设备的依赖指标数据进行依赖异常检测得到依赖异常检测信息;
属性图构建模块903,用于在根据所述服务异常检测信息和所述依赖异常检测信息确定存在多个异常服务设备或一个异常服务设备对应多个异常依赖设备时,根据所述服务异常检测信息和所述依赖异常检测信息构建异常属性图;
根因定位模块904,在存在多个异常服务设备时,利用所述异常属性图计算各所述异常服务设备的根因分值,并基于各所述异常服务设备的根因分值进行排序得到服务设备根因排序结果。
根据本公开的示例性实施例,所述属性图构建模块903包括提取单元和构建单元,所述提取单元用于获取检测到服务异常时的当前业务标识,并基于所述当前业务标识提取当前业务的业务属性图;所述构建单元用于根据所述服务异常检测信息和所述依赖异常检测信息从所述业务属性图中提取目标信息以构建所述异常属性图。
根据本公开的示例性实施例,所述属性图构建模块903还包括业务单元,所述业务单元用于获取预先构建的***调用关系图;其中,所述***调用关系图包括根据***中服务设备以及所述服务设备对应的依赖设备配置的节点,以及根据所述服务设备与所述依赖设备的依赖关系构建的所述节点之间的依赖有向边;以及基于业务标识获取该业务标识对应的调用链路信息,并根据所述调用链路信息中所述服务设备之间的调用关系构建所述节点之间的调用有向边;将所述调用有向边添加至所述***调用关系图中得到所述业务标识对应的业务属性图。
根据本公开的示例性实施例,所述构建单元还用于根据所述服务异常检测信息从所述业务属性图中提取目标服务有向边和目标服务节点;以及根据所述依赖异常检测信息从所述业务属性图中提取目标依赖有向边和目标依赖节点;基于所述目标服务有向边、所述目标服务节点、所述目标依赖有向边和所述目标依赖节点构建所述异常属性图。
根据本公开的示例性实施例,所述服务异常检测信息包括异常设备调用对和异常服务设备;其中,所述异常服务设备为所述异常设备调用对中被调用的服务设备;所述构建单元还用于基于所述服务异常检测信息中的异常设备调用对提取所述目标服务有向边;以及基于所述服务异常检测信息中的异常服务设备提取所述目标服务节点。
根据本公开的示例性实施例,所述依赖异常检测信息包括异常设备依赖对和异常依赖设备;其中,所述异常依赖设备为所述异常设备依赖对中的依赖设备;所述构建单元还用于基于所述依赖异常检测信息中的异常设备依赖对提取所述目标依赖有向边;以及基于所述依赖异常检测信息中的异常依赖设备提取所述目标依赖节点。
根据本公开的示例性实施例,根因定位模块904包括权重单元和分值单元,所述权重单元用于计算所述异常属性图中有向边的权重;其中,所述有向边包括异常调用有向边和异常依赖有向边;所述分值单元用于基于所述有向边的权重计算所述异常属性图中异常服务节点的根因分值,以得到所述异常服务节点对应的异常服务设备的根因分值。
根据本公开的示例性实施例,所述权重单元还用于在所述有向边为异常服务有向边且所述有向边对应的两个节点包括一个异常服务节点和一个正常服务节点时,基于所述有向边对应的异常服务节点的响应时间和平均异常响应时间计算所述有向边的权重;以及在所述有向边为异常服务有向边且所述有向边对应的两个节点均为异常服务节点时,将所述有向边的权重配置为预设值;在所述有向边为异常依赖有向边时,基于所述有向边对应的异常服务节点的平均异常响应时间和所述有向边对应的异常依赖节点的资源利用率计算所述有向边的权重。
根据本公开的示例性实施例,所述分值单元还用关于基于所述异常服务节点的平均响应时间、所述异常服务节点依赖的异常依赖节点的资源利用率以及所述异常服务节点对应的异常有向边的权重计算该异常服务节点的根因分值。
根据本公开的示例性实施例,所述根因定位模块904还包括依赖设备排序单元,所述依赖设备排序单元用于在确定一个异常服务设备对应多个异常依赖设备时,基于各异常依赖设备分别对应的依赖指标数据计算各异常依赖设备的根因分值;基于各异常依赖设备的根因分值进行排序得到该异常服务设备的异常依赖设备根因排序结果。
根据本公开的示例性实施例,所述根因定位模块904还包括依赖指标排序单元,所述依赖指标排序单元用于在异常依赖设备的依赖指标数据中包括多个依赖指标时,基于各依赖指标分别对应的指标值计算各依赖指标的根因分值;基于各依赖指标的根因分值进行排序得到该异常依赖设备的依赖指标根因排序结果。
上述的根因定位装置900中各模块的具体细节已经在对应的根因定位方法中进行了详细的描述,因此此处不再赘述。
应当注意,尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元,但是这种划分并非强制性的。实际上,根据本公开的实施方式,上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之,上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
在本公开的示例性实施例中,还提供了一种能够实现上述方法的存储介质。图10示意性示出本公开示例性实施例中一种计算机可读存储介质的示意图,如图10所示,描述了根据本公开的实施方式的用于实现上述方法的程序产品1000,其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码,并可以在终端设备,例如手机上运行。然而,本公开的程序产品不限于此,在本文件中,可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行***、装置或者器件使用或者与其结合使用。
在本公开的示例性实施例中,还提供了一种能够实现上述方法的电子设备。图11示意性示出本公开示例性实施例中一种电子设备的计算机***的结构示意图。
需要说明的是,图11示出的电子设备的计算机***1100仅是一个示例,不应对本公开实施例的功能和使用范围带来任何限制。
如图11所示,计算机***1100包括中央处理单元(Central Processing Unit,CPU)1101,其可以根据存储在只读存储器(Read-Only Memory,ROM)1102中的程序或者从存储部分1108加载到随机访问存储器(Random Access Memory,RAM)1103中的程序而执行各种适当的动作和处理。在RAM 1103中,还存储有***操作所需的各种程序和数据。CPU1101、ROM 1102以及RAM 1103通过总线1104彼此相连。输入/输出(Input/Output,I/O)接口1105也连接至总线1104。
以下部件连接至I/O接口1105:包括键盘、鼠标等的输入部分1106;包括诸如阴极射线管(Cathode Ray Tube,CRT)、液晶显示器(Liquid Crystal Display,LCD)等以及扬声器等的输出部分1107;包括硬盘等的存储部分1108;以及包括诸如LAN(Local AreaNetwork,局域网)卡、调制解调器等的网络接口卡的通信部分1109。通信部分1109经由诸如因特网的网络执行通信处理。驱动器1110也根据需要连接至I/O接口1105。可拆卸介质1111,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器1110上,以便于从其上读出的计算机程序根据需要被安装入存储部分1108。
特别地,根据本公开的实施例,下文参考流程图描述的过程可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分1109从网络上被下载和安装,和/或从可拆卸介质1111被安装。在该计算机程序被中央处理单元(CPU)1101执行时,执行本公开的***中限定的各种功能。
需要说明的是,本公开实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory,EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory,CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行***、装置或者器件使用或者与其结合使用。而在本公开中,计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、有线等等,或者上述的任意合适的组合。
附图中的流程图和框图,图示了按照本公开各种实施例的***、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图或流程图中的每个方框、以及框图或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的***来实现,或者可以用专用硬件与计算机指令的组合来实现。
描述于本公开实施例中所涉及到的单元可以通过软件的方式实现,也可以通过硬件的方式来实现,所描述的单元也可以设置在处理器中。其中,这些单元的名称在某种情况下并不构成对该单元本身的限定。
作为另一方面,本公开还提供了一种计算机可读介质,该计算机可读介质可以是上述实施例中描述的电子设备中所包含的;也可以是单独存在,而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被一个该电子设备执行时,使得该电子设备实现上述实施例中所述的方法。
应当注意,尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元,但是这种划分并非强制性的。实际上,根据本公开的实施方式,上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之,上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
通过以上的实施方式的描述,本领域的技术人员易于理解,这里描述的示例实施方式可以通过软件实现,也可以通过软件结合必要的硬件的方式来实现。因此,根据本公开实施方式的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中或网络上,包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本公开实施方式的方法。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。
应当理解的是,本公开并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (14)

1.一种根因定位方法,其特征在于,包括:
在基于设备调用对中被调用的服务设备的调用指标数据进行服务异常检测得到结果为服务异常时,获取服务异常检测信息;
基于所述服务异常检测信息中异常服务设备对应的依赖设备的依赖指标数据进行依赖异常检测得到依赖异常检测信息;
在根据所述服务异常检测信息和所述依赖异常检测信息确定存在多个异常服务设备或一个异常服务设备对应多个异常依赖设备时,根据所述服务异常检测信息和所述依赖异常检测信息构建异常属性图;
在存在多个异常服务设备时,利用所述异常属性图计算各所述异常服务设备的根因分值,并基于各所述异常服务设备的根因分值进行排序得到服务设备根因排序结果。
2.根据权利要求1所述的根因定位方法,其特征在于,所述根据所述服务异常检测信息和所述依赖异常检测信息构建异常属性图,包括:
获取检测到服务异常时的当前业务标识,并基于所述当前业务标识提取当前业务的业务属性图;
根据所述服务异常检测信息和所述依赖异常检测信息从所述业务属性图中提取目标信息以构建所述异常属性图。
3.根据权利要求2所述的根因定位方法,其特征在于,所述方法还包括:预先构建业务标识对应的业务属性图,所述预先构建业务标识对应的业务属性图,包括:
获取预先构建的***调用关系图;其中,所述***调用关系图包括根据***中服务设备以及所述服务设备对应的依赖设备配置的节点,以及根据所述服务设备与所述依赖设备的依赖关系构建的所述节点之间的依赖有向边;以及
基于业务标识获取该业务标识对应的调用链路信息,并根据所述调用链路信息中所述服务设备之间的调用关系构建所述节点之间的调用有向边;
将所述调用有向边添加至所述***调用关系图中得到所述业务标识对应的业务属性图。
4.根据权利要求2所述的根因定位方法,其特征在于,所述根据所述服务异常检测信息和所述依赖异常检测信息从所述业务属性图中提取目标信息以构建所述异常属性图,包括:
根据所述服务异常检测信息从所述业务属性图中提取目标服务有向边和目标服务节点;以及
根据所述依赖异常检测信息从所述业务属性图中提取目标依赖有向边和目标依赖节点;
基于所述目标服务有向边、所述目标服务节点、所述目标依赖有向边和所述目标依赖节点构建所述异常属性图。
5.根据权利要求4所述的根因定位方法,其特征在于,所述服务异常检测信息包括异常设备调用对和异常服务设备;其中,所述异常服务设备为所述异常设备调用对中被调用的服务设备;
所述根据所述服务异常检测信息从所述业务属性图中提取目标服务有向边和目标服务节点,包括:
基于所述服务异常检测信息中的异常设备调用对提取所述目标服务有向边;以及
基于所述服务异常检测信息中的异常服务设备提取所述目标服务节点。
6.根据权利要求4所述的根因定位方法,其特征在于,所述依赖异常检测信息包括异常设备依赖对和异常依赖设备;其中,所述异常依赖设备为所述异常设备依赖对中的依赖设备;
所述根据所述依赖异常检测信息从所述业务属性图中提取目标依赖有向边和目标依赖节点,包括:
基于所述依赖异常检测信息中的异常设备依赖对提取所述目标依赖有向边;以及
基于所述依赖异常检测信息中的异常依赖设备提取所述目标依赖节点。
7.根据权利要求1所述的根因定位方法,其特征在于,所述利用所述异常属性图计算各所述异常服务设备的根因分值,包括:
计算所述异常属性图中有向边的权重;其中,所述有向边包括异常调用有向边和异常依赖有向边;
基于所述有向边的权重计算所述异常属性图中异常服务节点的根因分值,以得到所述异常服务节点对应的异常服务设备的根因分值。
8.根据权利要求7所述的根因定位方法,其特征在于,所述计算所述异常属性图中有向边的权重,包括:
在所述有向边为异常服务有向边且所述有向边对应的两个节点包括一个异常服务节点和一个正常服务节点时,基于所述有向边对应的异常服务节点的响应时间和平均异常响应时间计算所述有向边的权重;以及
在所述有向边为异常服务有向边且所述有向边对应的两个节点均为异常服务节点时,将所述有向边的权重配置为预设值;
在所述有向边为异常依赖有向边时,基于所述有向边对应的异常服务节点的平均异常响应时间和所述有向边对应的异常依赖节点的资源利用率计算所述有向边的权重。
9.根据权利要求7所述的根因定位方法,其特征在于,所述基于所述有向边的权重计算所述异常属性图中异常服务节点的根因分值,包括:
基于所述异常服务节点的平均响应时间、所述异常服务节点依赖的异常依赖节点的资源利用率以及所述异常服务节点对应的异常有向边的权重计算该异常服务节点的根因分值。
10.根据权利要求1所述的根因定位方法,其特征在于,所述方法还包括:
在确定一个异常服务设备对应多个异常依赖设备时,基于各异常依赖设备分别对应的依赖指标数据计算各异常依赖设备的根因分值;
基于各异常依赖设备的根因分值进行排序得到该异常服务设备的异常依赖设备根因排序结果。
11.根据权利要求1所述的根因定位方法,其特征在于,所述方法还包括:
在异常依赖设备的依赖指标数据中包括多个依赖指标时,基于各依赖指标分别对应的指标值计算各依赖指标的根因分值;
基于各依赖指标的根因分值进行排序得到该异常依赖设备的依赖指标根因排序结果。
12.一种根因定位装置,其特征在于,包括:
服务检测模块,用于在基于设备调用对中被调用的服务设备的调用指标数据进行服务异常检测得到结果为服务异常时,获取服务异常检测信息;
依赖检测模块,用于基于所述服务异常检测信息中异常服务设备对应的依赖设备的依赖指标数据进行依赖异常检测得到依赖异常检测信息;
属性图构建模块,用于在根据所述服务异常检测信息和所述依赖异常检测信息确定存在多个异常服务设备或一个异常服务设备对应多个异常依赖设备时,根据所述服务异常检测信息和所述依赖异常检测信息构建异常属性图;
根因定位模块,在存在多个异常服务设备时,利用所述异常属性图计算各所述异常服务设备的根因分值,并基于各所述异常服务设备的根因分值进行排序得到服务设备根因排序结果。
13.一种计算机可读存储介质,其上存储有计算机程序,所述程序被处理器执行时实现如权利要求1至11任一项所述的根因定位方法。
14.一种电子设备,其特征在于,包括:
一个或多个处理器;
存储装置,用于存储一个或多个程序,当所述一个或多个程序被所述一个或多个处理器执行时,使得所述一个或多个处理器实现如权利要求1至11任一项所述的根因定位方法。
CN202210261913.3A 2022-03-16 2022-03-16 根因定位方法、装置、存储介质及电子设备 Active CN114598539B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210261913.3A CN114598539B (zh) 2022-03-16 2022-03-16 根因定位方法、装置、存储介质及电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210261913.3A CN114598539B (zh) 2022-03-16 2022-03-16 根因定位方法、装置、存储介质及电子设备

Publications (2)

Publication Number Publication Date
CN114598539A true CN114598539A (zh) 2022-06-07
CN114598539B CN114598539B (zh) 2024-03-01

Family

ID=81809321

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210261913.3A Active CN114598539B (zh) 2022-03-16 2022-03-16 根因定位方法、装置、存储介质及电子设备

Country Status (1)

Country Link
CN (1) CN114598539B (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115150255A (zh) * 2022-07-12 2022-10-04 北京云集智造科技有限公司 一种自适应的基于知识图谱的应用故障自动根因定位方法
CN116820826A (zh) * 2023-08-28 2023-09-29 北京必示科技有限公司 一种基于调用链的根因定位方法、装置、设备及存储介质
CN116962673A (zh) * 2023-09-21 2023-10-27 四川君恒泰电子电器有限公司 一种应用于智能电视主板***的异常检测方法及***
CN117149500A (zh) * 2023-10-30 2023-12-01 安徽思高智能科技有限公司 基于指标数据和日志数据的异常根因获得方法及***

Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130097183A1 (en) * 2011-10-14 2013-04-18 Zenoss, Inc. Method and apparatus for analyzing a root cause of a service impact in a virtualized environment
US20150033084A1 (en) * 2013-07-28 2015-01-29 OpsClarity Inc. Organizing network performance metrics into historical anomaly dependency data
US20150347936A1 (en) * 2014-05-29 2015-12-03 International Business Machines Corporation Database partition
CN110888755A (zh) * 2019-11-15 2020-03-17 亚信科技(中国)有限公司 一种微服务***异常根因节点的查找方法及装置
CN111538616A (zh) * 2020-04-30 2020-08-14 深圳前海微众银行股份有限公司 异常定位方法、装置、***与计算机可读存储介质
CN111737033A (zh) * 2020-05-26 2020-10-02 复旦大学 一种基于运行时图谱分析的微服务故障定位方法
CN112087320A (zh) * 2020-08-16 2020-12-15 中信百信银行股份有限公司 一种异常定位方法、装置、电子设备和可读存储介质
CN112104407A (zh) * 2020-09-07 2020-12-18 西安电子科技大学 基于隐私保护的无人机群通信网络异常检测及溯源方法
WO2021056197A1 (zh) * 2019-09-24 2021-04-01 西门子(中国)有限公司 根本原因分析方法、装置、电子设备、介质以及程序产品
CN113014421A (zh) * 2021-02-08 2021-06-22 武汉大学 一种面向云原生***的微服务根因定位方法
CN113098723A (zh) * 2021-06-07 2021-07-09 新华三人工智能科技有限公司 一种故障根因定位方法、装置、存储介质及设备
CN113190373A (zh) * 2021-05-31 2021-07-30 中国人民解放军国防科技大学 一种基于故障特征比较的微服务***故障根因定位方法
CN113467421A (zh) * 2021-07-01 2021-10-01 中国科学院计算技术研究所 获取微服务健康状态指标的方法和微服务异常诊断方法
CN113641526A (zh) * 2021-09-01 2021-11-12 京东科技信息技术有限公司 告警根因定位方法、装置、电子设备及计算机存储介质
CN113657715A (zh) * 2021-07-15 2021-11-16 福建新大陆软件工程有限公司 一种基于核密度估计调用链的根因定位方法及***
CN113900844A (zh) * 2021-09-26 2022-01-07 北京必示科技有限公司 一种基于服务码级别的故障根因定位方法、***及存储介质
US11269718B1 (en) * 2020-06-29 2022-03-08 Amazon Technologies, Inc. Root cause detection and corrective action diagnosis system

Patent Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130097183A1 (en) * 2011-10-14 2013-04-18 Zenoss, Inc. Method and apparatus for analyzing a root cause of a service impact in a virtualized environment
US20150033084A1 (en) * 2013-07-28 2015-01-29 OpsClarity Inc. Organizing network performance metrics into historical anomaly dependency data
US20150347936A1 (en) * 2014-05-29 2015-12-03 International Business Machines Corporation Database partition
WO2021056197A1 (zh) * 2019-09-24 2021-04-01 西门子(中国)有限公司 根本原因分析方法、装置、电子设备、介质以及程序产品
CN110888755A (zh) * 2019-11-15 2020-03-17 亚信科技(中国)有限公司 一种微服务***异常根因节点的查找方法及装置
CN111538616A (zh) * 2020-04-30 2020-08-14 深圳前海微众银行股份有限公司 异常定位方法、装置、***与计算机可读存储介质
CN111737033A (zh) * 2020-05-26 2020-10-02 复旦大学 一种基于运行时图谱分析的微服务故障定位方法
US11269718B1 (en) * 2020-06-29 2022-03-08 Amazon Technologies, Inc. Root cause detection and corrective action diagnosis system
CN112087320A (zh) * 2020-08-16 2020-12-15 中信百信银行股份有限公司 一种异常定位方法、装置、电子设备和可读存储介质
CN112104407A (zh) * 2020-09-07 2020-12-18 西安电子科技大学 基于隐私保护的无人机群通信网络异常检测及溯源方法
CN113014421A (zh) * 2021-02-08 2021-06-22 武汉大学 一种面向云原生***的微服务根因定位方法
CN113190373A (zh) * 2021-05-31 2021-07-30 中国人民解放军国防科技大学 一种基于故障特征比较的微服务***故障根因定位方法
CN113098723A (zh) * 2021-06-07 2021-07-09 新华三人工智能科技有限公司 一种故障根因定位方法、装置、存储介质及设备
CN113467421A (zh) * 2021-07-01 2021-10-01 中国科学院计算技术研究所 获取微服务健康状态指标的方法和微服务异常诊断方法
CN113657715A (zh) * 2021-07-15 2021-11-16 福建新大陆软件工程有限公司 一种基于核密度估计调用链的根因定位方法及***
CN113641526A (zh) * 2021-09-01 2021-11-12 京东科技信息技术有限公司 告警根因定位方法、装置、电子设备及计算机存储介质
CN113900844A (zh) * 2021-09-26 2022-01-07 北京必示科技有限公司 一种基于服务码级别的故障根因定位方法、***及存储介质

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
刘文瑞;易世界;栗娟;杨威;刘进;: "基于贝叶斯服务依赖图的错误定位", 武汉大学学报(理学版), no. 03 *
孙贺;吴礼发;洪征;颜慧颖;张亚丰;: "一种结合动态与静态分析的函数调用图提取方法", 计算机工程, no. 03 *
贾统;李影;吴中海;: "基于日志数据的分布式软件***故障诊断综述", 软件学报, no. 07 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115150255A (zh) * 2022-07-12 2022-10-04 北京云集智造科技有限公司 一种自适应的基于知识图谱的应用故障自动根因定位方法
CN115150255B (zh) * 2022-07-12 2024-05-31 北京云集智造科技有限公司 一种自适应的基于知识图谱的应用故障自动根因定位方法
CN116820826A (zh) * 2023-08-28 2023-09-29 北京必示科技有限公司 一种基于调用链的根因定位方法、装置、设备及存储介质
CN116820826B (zh) * 2023-08-28 2023-11-24 北京必示科技有限公司 一种基于调用链的根因定位方法、装置、设备及存储介质
CN116962673A (zh) * 2023-09-21 2023-10-27 四川君恒泰电子电器有限公司 一种应用于智能电视主板***的异常检测方法及***
CN116962673B (zh) * 2023-09-21 2023-12-15 四川君恒泰电子电器有限公司 一种应用于智能电视主板***的异常检测方法及***
CN117149500A (zh) * 2023-10-30 2023-12-01 安徽思高智能科技有限公司 基于指标数据和日志数据的异常根因获得方法及***
CN117149500B (zh) * 2023-10-30 2024-01-26 安徽思高智能科技有限公司 基于指标数据和日志数据的异常根因获得方法及***

Also Published As

Publication number Publication date
CN114598539B (zh) 2024-03-01

Similar Documents

Publication Publication Date Title
CN114598539B (zh) 根因定位方法、装置、存储介质及电子设备
CN110309009B (zh) 基于情境的运维故障根因定位方法、装置、设备及介质
EP3418910A1 (en) Big data-based method and device for calculating relationship between development objects
US20200327030A1 (en) Device for testing blockchain network
US10379717B2 (en) Device based visualization and analysis of multivariate data
CN111612038B (zh) 异常用户检测方法及装置、存储介质、电子设备
US20060294220A1 (en) Diagnostics and resolution mining architecture
US20220058172A1 (en) Data accuracy using natural language processing
CN114465874A (zh) 故障预测方法、装置、电子设备与存储介质
CN111177481B (zh) 用户标识映射方法及装置
CN113569162A (zh) 数据处理方法、装置、设备及存储介质
CN115756929A (zh) 一种基于动态服务依赖图的异常根因定位方法及***
CN117151726A (zh) 故障的修复方法、修复装置、电子设备以及存储介质
CN115840738A (zh) 一种数据迁移方法、装置、电子设备及存储介质
US11157267B1 (en) Evaluation of dynamic relationships between application components
CN110782169A (zh) 更新业务流程方法和装置
CN115361266A (zh) 告警根因定位方法、装置、设备及存储介质
CN114881521A (zh) 业务评估方法、装置、电子设备以及存储介质
CN111638926A (zh) 人工智能在Django框架中的一种实现方法
CN113220748B (zh) 一种构建配电网设备负荷热力图及数据分析的方法和***
CN115767601A (zh) 一种基于多维数据的5gc网元自动化纳管方法及装置
CN115292516A (zh) 基于区块链的分布式知识图谱构建方法、装置及***
CN113792114A (zh) 一种城市领域知识图谱可信评估方法及***
CN114896418A (zh) 知识图谱构建方法、装置、电子设备及存储介质
CN114219663A (zh) 产品推荐方法、装置、计算机设备及存储介质

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
GR01 Patent grant
GR01 Patent grant