CN115118574B - 一种数据处理方法、装置及存储介质 - Google Patents

Abstract

本申请实施例提供了一种数据处理方法、装置及存储介质，所述方法包括：获取与目标对象对应的应用调用拓扑图；其中，所述应用调用拓扑图包括多个节点及多条边，所述多个节点为与所述目标对象相关联的多个软硬件；所述多条边为所述软硬件之间的调用关系；根据所述应用调用拓扑图获取所述多个节点对应的软硬件信息及与所述软硬件信息对应的多个指标数据；根据所述软硬件对应的多个指标数据，确定所述多个节点中的疑似根因节点，所述疑似根因节点为调用异常的节点。本申请实施例缩小了根因分析的范围，缩短了根因分析的时间，提高了故障根因定位效率。

Description

一种数据处理方法、装置及存储介质

技术领域

本申请涉及计算机应用技术领域，尤其涉及一种数据处理方法、装置及存储介质。

背景技术

根因定位是运维的一个重要环节，用于在业务系统发生异常时，定位异常的根本原因。在现有技术条件下，根因分析更多依赖监控工具，再加上人工分析的方式。这种情况下，故障识别会耗费大量时间和大量人力，据统计，大多数分布式系统的故障定位时间，占到整个故障修复时间的1/3。具体地，监控人员通过告警监控发现故障并进行派单。派单之后，维护人员通过管理功能、日志分析和专家经验来进行故障诊断。确定故障后，维护人员进行应急恢复措施选择及评估，最后进行网络故障恢复。

然而，随着网络的规模日益增大，告警信息的数量也在成倍增长，甚至达每天百万量级。现有的凭借人工经验进行根因定位的方式，耗时较长，导致网络故障修复效率较低。

发明内容

本申请提供一种数据处理方法、装置及存储介质，以解决传统的依赖人工进行告警信息处理耗时较长的问题。

第一方面，本申请实施例提供了一种数据处理方法，所述方法包括：

获取与目标对象对应的应用调用拓扑图；其中，所述应用调用拓扑图包括多个节点及多条边，所述多个节点为与所述目标对象相关联的多个软硬件；所述多条边为所述软硬件之间的调用关系；

根据所述应用调用拓扑图获取所述多个节点对应的软硬件信息及与所述软硬件对应的多个指标数据；

根据所述软硬件对应的多个指标数据，确定所述多个节点中的疑似根因节点，所述疑似根因节点为调用异常的节点。

第二方面，本申请实施例提供了一种数据处理装置，所述装置包括：

第一获取模块，用于获取与目标对象对应的应用调用拓扑图；其中，所述应用调用拓扑图包括多个节点及多条边，所述多个节点为与所述目标对象相关联的多个软硬件；所述多条边为所述软硬件之间的调用关系；

第二获取模块，用于根据所述应用调用拓扑图获取所述多个节点对应的软硬件信息及与所述软硬件对应的多个指标数据；

确定模块，用于根据所述软硬件对应的多个指标数据，确定所述多个节点中的疑似根因节点，所述疑似根因节点为调用异常的节点。

第三方面，本申请实施例提供了一种电子设备，包括：

处理器；以及，

被安排成存储计算机可执行指令的存储器，所述可执行指令被配置由所述处理器执行，所述可执行指令包括用于执行上述数据处理方法中的步骤。

第四方面，本申请实施例提供了一种存储介质，所述存储介质用于存储计算机可执行指令，所述可执行指令使得计算机执行上述数据处理方法。

根据本申请实施例的方法，在目标对象发生异常时，通过获取目标对象所对应的应用调用拓扑图，所述应用调用拓扑图包括多个节点及多条边，所述多个节点为与所述目标对象相关联的多个软硬件；所述多条边为所述软硬件之间的调用关系，这样的拓扑图具有展示清晰，方便根因定位的特点。本申请实施例在故障分析时只需要分析与目标对象所关联的少数节点，克服了APM全链路追踪系统每次分析时需要调用应用全拓扑图，所有业务和所有应用的关系在这一个应用全拓扑图上展示，未根据不同的业务分别建立对应的调用拓扑图，拓扑图过于复杂，不利于后续进行根因分析的弊端。本申请实施例方法根据不同的业务分别建立有对应的应用调用拓扑图，缩小了数据处理装置的分析数据范围，缩短了数据处理装置根因分析时间，提高了数据处理装置根因分析效率。根据与目标对象所关联的应用调用拓扑图获取所述多个节点对应的软硬件信息及与所述软硬件对应的多个指标数据；根据所述软硬件对应的多个指标数据，确定所述多个节点中的疑似根因节点，具有评价标准客观，获得结果准确的效果，本申请实施例相比于人工判断根因节点及根因指标的方法，缩短了根因分析的时间，提高了根因定位效率，在高效准确地获得了根因节点之后，方便迅速对根因节点故障进行排查，从而提高网络故障修复效率。

附图说明

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

图1为本申请实施例提供的数据处理方法的实施环境示意图；

图2为本申请实施例提供的数据处理方法的流程示意图；

图3为本申请实施例中的与目标对象对应的应用调用拓扑示意图；

图4为未采用MAD进行异常分数确定所获得的异常分数结果展示图；

图5为采用MAD进行异常分数确定所获得的异常分数结果展示图；

图6为本申请应用实例与目标对象对应的应用拓扑图生成方法流程图；

图7为本申请应用实例中与目标对象对应的应用调用拓扑图示意图；

图8为本申请应用实例的用于根因分析的数据处理方法流程图；

图9为本申请应用实例中指标数据与业务异常的相关性判断示意图；

图10为本申请实施例提供的数据处理装置结构示意图；

图11为本申请一个或多个实施例提供的一种电子设备的结构示意图。

具体实施方式

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

根因分析，也称根本原因分析(RCA)，是一项结构化的问题处理方法，用以逐步找出问题的根本原因并加以解决。根因分析对于运维系统来说至关重要。在电商系统领域，某一项具体的业务处理过程可能会产生不同的资源调用。比如用户A通过一个http调用发起一个提交申请单业务请求，用户B也通过一个http调用发起一个提交申请单业务请求，由于用户A与用户B的身份差异，比如根据二者的年龄，用户A为18周岁以下，用户B为18周岁以上，二者的年龄区别导致各个提交申请单业务请求的处理，需要调用各个不同的应用、中间件、数据库，而对于提交申请单业务来说，每天成千上万个http调用，每个http调用涉及各个不同的应用、中间件、数据库，当提交申请单业务发生异常时，比如系统反应超时，需要对导致业务异常发生的根本原因做分析，分析到是哪个应用、中间件、数据库出现了问题，找到根本原因，便于解决根本问题，进而消除业务异常，使业务恢复正常。

在相关技术中，根因分析更多依赖监控工具，再加上人工分析的方式：

凭人工总结的经验，得知某一类业务异常时应该排查哪一些和此异常相关的应用、数据库、中间件，具体包括两个方面：

1、从业务最开始的应用，凭借全链路追踪系统以及这类系统提供的相关信息，比如调用异常信息、调用延时告警信息，再人工定位应用调用链上，是哪个应用(或是其数据库、中间件)引起业务异常，可见每次分析都要从业务最开始的应用开始。

2、凭借监控系统的监控图表或告警，凭借人工经验，观察引起业务异常的应用(或是其数据库、中间件)具体是哪一个或者哪一些指标表现出问题。可以理解的是，应用(或是其数据库、中间件)里有很多指标，比如线程数，响应速度等。

这样，通过先定位到应用(或是其数据库、中间件)，再定位到应用(或是其数据库、中间件)的指标，从而实现具体故障的排查定位。

而上述处理方法的缺点也是显而易见的：

1、单纯凭人工总结的经验，得知业务相关的应用调用拓扑，如果没有对业务和应用非常熟悉的专家在场很难全面的知道应该排查哪些应用、数据库、中间件，如果专家把经验沉淀到文档，也存在文档更新是否及时的问题，另外定期更新文档也是额外的成本。

2、借助于全链路追踪系统以及这类系统提供的调用异常、调用延时告警信息，由于全链路追踪系统的应用调用链路和业务及应用虽然有建立对应关系，但是没有办法直观的区分特定业务与执行该特定业务需要的多个应用的之间关系，需由业务和应用经验丰富的人工来定位应用调用链上，具体是哪个应用(或是其数据库、中间件)引起业务异常。虽然可行，但仍然存在高度依赖问题处理人员的技术或问题处置经验，且定位时间往往较长。定位到具体某个应用为根因往往耗费较长时间，数分钟甚至数小时。

3、对于判断具体的指标来说，凭借监控系统的监控图表或告警，凭借人工经验，观察引起业务异常的应用具体是哪一个指标表现出问题。人工定位时间依然较长，有提升的空间。

近年来，微服务框架的应用场景越来越广，在微服务体系结构中，各类“小型服务”独立运行、独立部署，小型服务的落地形式就是一个又一个独立的研发、部署、运行的应用程序，简称应用。在中大型互联网、金融科技等为用户提供互联网服务的公司，应用的数量成百上千，应用之间的调用关系更是千丝万缕，所以应用调用拓扑图异常复杂。以某电商的应用调用拓扑网络图为例，该拓扑网络图包括了所有应用，在发生故障时，故障会在整个动态拓扑网络中传播，从而引起多个节点的告警并出现告警风暴，将导致运维难度成倍提高。因此，一旦微服务出现故障又无法迅速定位并解决根因，将直接影响用户体验，给应用的企业带来巨大的经济损失。因此，如何在业务系统发生异常告警时，迅速定位异常告警的根因(Root Cause，根本原因)并及时止损，成为亟待解决的问题。

本申请的主要思想是通过构建与目标对象所对应的应用调用拓扑图，当发生故障时，根据应用调用拓扑图定位疑似根因节点，并进一步对疑似根因节点的指标进行分析，从而定位引起异常的最终根因节点及具体指标，达到缩小根因分析范围，节约故障定位时间的效果。

参照图1所示，为本申请实施例提供的数据处理方法的实施环境示意图。本申请实施例提供的信息处理方法的实施环境包括：无线或有线网络100、终端设备101、102、103以及服务器104。无线或有线网络100在终端设备101、102、103和服务器104之间提供通信链路的介质。无线或有线网络100可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过无线或有线网络100与服务器104进行交互，接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如购物类应用、实名认证类应用、申请网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等，当然，此处例举的各种应用仅为示例，实际可以包括更多种类的应用。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器104是提供各种服务的服务器，可以包括独立的服务器，或者由多个服务器组成的服务器集群等。例如对用户利用终端设备101、102、103所浏览的网站提供支持的后台管理服务器。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果反馈给终端设备。例如根据用户请求获取或生成的网页、信息、或数据等反馈给终端设备。

本申请实施例所提供的数据处理方法一般可以由服务器104执行。

相应地，本公开实施例所提供的数据处理装置一般可以设置于服务器104中。本公开实施例所提供的数据处理方法也可以由不同于服务器104且能够与终端设备101、102、103和/或服务器104通信的服务器或服务器集群执行。相应地，本公开实施例所提供的数据处理装置也可以设置于不同于服务器104且能够与终端设备101、102、103和/或服务器104通信的服务器或服务器集群中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

以下将基于图1描述的实施环境，对本公开实施例的数据处理方法进行详细描述。

图2为本申请实施例提供的数据处理方法的流程示意图，参照图2所示，所述数据处理方法应用于由众多分布式应用支撑的业务发生异常时的根因分析，本申请实施例中的根因分析指：探究引起业务异常的根本原因，包括以下两方面：1、是哪个应用或是其数据库、中间件(应用、其数据库、中间件在本实施例中统称为节点)引起业务异常；2、引起业务异常的具体是节点的哪一个指标表现出问题，此处的指标包括线程数，响应速度等。本申请实施例的数据处理方法包括以下步骤：

步骤201，获取与目标对象对应的应用调用拓扑图；其中，所述应用调用拓扑图包括多个节点及多条边，所述多个节点为与所述目标对象相关联的多个软硬件；所述多条边为所述软硬件之间的调用关系；

本申请实施例中的目标对象可以为各种业务，所述业务可以为：消费金融业务、贷款业务、风险评估业务，授信业务等，或者是其他的各种互联网业务，如电商业务、互联网新闻业务、广告业务等，上述各种业务可以是由多个子业务组成的。本申请实施例中的目标对象也可以是以上业务中的完成特定功能的子业务。在本实施例中，每一个目标对象对应多个应用，一旦发生异常，进行异常排查、修复系统的速度就非常重要。在本实施例中，只要是由众多分布式应用支撑起来的目标对象，都可以采用本申请实施例的方法。比如电商注册业务，如果在实名认证环节出了问题，出现报错或者响应超时等业务异常时，如果在包括了电商所有应用的调用拓扑图中进行查找，由于拓扑图过于庞大、复杂，在这样的应用调用拓扑图中进行故障原因查找分析，通常要对几十个应用进行排查，排查效率很低。在本申请实施例中，所述目标对象可以为电商注册业务，通过获取电商注册业务所关联的应用调用拓扑图，在发生异常时，可以根据和这个业务所关联的应用调用拓扑图确定疑似根因节点，应用调用拓扑图包括：应用及相关的数据库、中间件，减少了需要分析的节点数量，这样的拓扑图具有展示清晰，方便根因定位的特点。

步骤202，根据所述应用调用拓扑图获取所述多个节点对应的软硬件信息及与所述软硬件对应的多个指标数据；

步骤203，根据所述软硬件对应的多个指标数据，确定所述多个节点中的疑似根因节点，所述疑似根因节点为调用异常的节点。

根据本申请实施例的方法，通过获取目标对象所关联的应用调用拓扑图，在目标对象异常发生时，根据和这个目标对象所关联的应用调用拓扑图确定疑似根因节点，所述应用调用拓扑图包括多个节点及多条边，所述多个节点为与所述目标对象相关联的多个软硬件，所述多条边为所述软硬件之间的调用关系，这样的拓扑图具有展示清晰，方便根因定位的特点。

本申请实施例在故障分析时只需要分析与目标对象所关联的少数节点，克服了APM全链路追踪系统每次分析时需要调用应用全拓扑图，所有业务和所有应用的关系在这一个应用全拓扑图上展示，未根据不同的业务分别建立对应的调用拓扑图，拓扑图过于复杂，不利于后续进行根因分析的弊端。本申请实施例方法根据不同的业务分别建立有对应的应用调用拓扑图，缩小了数据处理装置的分析数据范围，缩短了数据处理装置根因分析时间，提高了数据处理装置根因分析效率。根据与目标对象所关联的应用调用拓扑图获取所述多个节点对应的软硬件信息及与所述软硬件对应的多个指标数据；根据所述软硬件对应的多个指标数据，确定所述多个节点中的疑似根因节点，具有评价标准客观，获得结果准确的效果，本申请实施例相比于人工判断根因节点及根因指标的方法，缩短了根因分析的时间，提高了根因定位效率，在高效准确地获得了根因节点之后，方便迅速对根因节点故障进行排查，从而提高网络故障修复效率。

在本申请的一个实施例中，所述软硬件包括但不限于以下中的一种或者两种以上的任意组合：应用、数据库、中间件；

所述软硬件信息，包括但不限于以下中的一种或者两种以上的任意组合：名称信息、类型信息、版本信息；以及，

所述指标数据，包括但不限于以下中的一种或者两种以上的任意组合：调用耗时、调用异常数据、调用次数。

本实施例中，所述应用调用拓扑图包括了具有调用关系的所有软硬件，根据所述应用调用拓扑图获取所述多个节点对应的软硬件信息及与所述软硬件对应的多个指标数据，从而在目标对象异常时，可以根据这些信息确定导致目标对象异常的所有疑似根因节点并进一步确定最终根因节点，为具体故障发生时的根因定位提供了数据基础和查询依据，具有根因定位高效、准确的特点。当然，上述软硬件信息及指标数据可以进行其他的设定，具体视实际应用需求而定，本申请实施例对此不加以限定。

在本申请的一个实施例中，所述多个节点对应的软硬件信息，所述软硬件之间的调用关系通过以下方法确定：

基于对所述软硬件的调用，获取所述软硬件的调用链路标识、所述目标对象的对象标识、以及所述调用链路标识与所述目标对象标识之间的对应关系；

根据所述对应关系，获取与同一目标对象标识相关的具有相同所述调用链路标识的所有软硬件的调用记录；

根据所述调用记录确定软硬件之间的调用关系和软硬件信息。

在本申请的一个实施例中，根据对软硬件的调用被运行的埋点代码获取预存的调用链路标识和业务名称的对应关系，或者，在设置埋点代码时增加调用链路标识，建立起调用链路标识和业务名称的对应关系，之后根据对软硬件的每一次调用被运行的埋点代码获得所述调用链路标识和业务名称的对应关系。

根据所述调用链路标识和目标对象的标识之间的对应关系，获取具有相同调用链路标识的所有软硬件的调用记录，根据所述调用记录获得所述所有软硬件信息以及软硬件之间的调用关系。

在本申请实施例中，基于相同调用链路ID，构建目标对象关联的应用调用拓扑图。从而根据所述调用链路标识和目标对象的标识之间的对应关系，获取具有相同调用链路标识的所有软硬件的调用记录，根据所述调用记录获得所述所有软硬件信息软硬件之间的调用关系。采用本实施例的方法，具有所获取的软硬件信息与目标对象准确对应的特点。

本申请实施例中，目标对象标识用于区分是否是同一个业务，也就是说，同一个业务的目标对象标识相同，不同业务的目标对象标识不同。通过全链路监控系统的业务埋点SDK(软件开发工具包)插件，自动采集对应用的每一次调用的调用链路ID和目标对象的标识绑定关系，用以得到影响该目标对象的所有节点，此处的节点包括应用及其数据库、中间件。埋点代码会因为用户的http(超文本传输协议)请求而被运行起来(技术上是一个http请求，业务上可能是一个“提交申请单”的请求)，每个到代码的http请求，全链路追踪系统都会赋予其一个“链路ID”,在实际的业务处理过程中，由于多个应用间存在依次的调用关系，所以链路ID会在调用过程中传给下一个应用，因此链路ID串联了业务代码+埋点代码，以及上、下游所有应用、中间件、数据库。一个http调用得到一个调用链路ID及其完整的调用记录，每天成千上万个http调用，就得到了与业务对应的完整调用关系，为了便于查看，以拓扑图的形式展现。如图3所示的本申请实施例中的与目标对象对应的应用调用拓扑图示意图。图中的每一个节点代表了一个软硬件，比如应用、中间件、数据库等，图中的每一条边代表软硬件之间的调用关系。

本实施例中，通过代码埋点，得到调用链路ID和目标对象的标识的绑定关系。但对于研发修改代码的情况下，需要做埋点时增加调用链路ID的操作。此种情况下新做埋点，从而建立起调用链路ID和业务名称的对应关系，本质都是基于埋点获得调用链路ID和业务名称的对应关系。

另外，对于要求分析的目标对象属性特别详尽的情况，比如“哪个地域的用户提交的申请单”等附加业务属性，也可以通过给埋点SDK传入参数的方式获取。比如授信业务，埋点的时候可以传入参数标识出发起的请求来源于哪个地域，便于做更进一步的精细分析，比如是哪个地域的操作导致异常等。

在本申请的一个实施例中，所述方法还包括：

在预设时间间隔内调用软硬件的情况下，获取所述软硬件所关联的所有软硬件信息及软硬件之间的调用关系；

根据所述软硬件信息及调用关系，更新所述应用调用拓扑图。

在本实施例中，通过构建与目标对象关联的应用调用拓扑图并实时更新，在预设时间间隔内目标对象调用软硬件的情况下，获取所述软硬件所关联的所有软硬件信息及软硬件之间的调用关系，根据所述软硬件信息及调用关系，更新所述应用调用拓扑图。在本实施例中，所述预设时间间隔可以为1-5分钟，当然，此处的预设时间间隔仅仅为示例，所述预设时间间隔根据实际需求可以进行其他设定，本申请对此不加以限定。

本实施例中，目标对象的应用调用拓扑图具有信息更新及时的特点，当发生故障时，根据目标对象关联的应用调用拓扑图定位疑似异常节点，并进一步定位引起异常的最终异常节点，可以达到节约故障定位时间，故障判断准确快捷的效果。

在本申请的一个实施例中，所述方法还包括：

将所述应用调用拓扑图存储到图数据库。

本实施例中，通过将目标对象所关联的应用调用拓扑图存储到图数据库，并同时存储了具体的软硬件信息，为具体故障发生时的根因定位提供了数据基础和查询依据。可见，在本申请的实施例中，获得了目标对象所关联的节点信息：应用、中间件、数据库等，以便在异常时我们集中精力关注这部分的节点。

在本申请的一个实施例中，所述根据所述软硬件的多个指标数据，确定所述多个节点中的疑似根因节点，包括：

在所述目标对象异常的情况下，获取每个节点对应的软硬件的每个指标数据的异常分数，所述异常分数根据预设的评分标准确定；

若所述指标数据的异常分数符合预设判断规则，则确定所述节点为疑似根因节点。

在本实施例中，通过对节点对应的软硬件的多个指标数据进行异常评分的方式，确定疑似根因节点，能达到评价客观、准确，易于采用的技术效果。

在本申请的一个实施例中，所述根据所述异常分数，若节点对应的所述异常分数符合预设判断规则，确定所述目标根因节点为疑似根因节点，包括：

当判断到所述节点对应的所述异常分数占据的排名满足设定比例，则确定所述节点为疑似根因节点。

比如，当业务异常发生时，如果根据之前实时更新的应用调用拓扑图，发现与所述业务存在调用关系的有四个节点A、B、C、D，在本申请实施例中，所述节点可能为应用、中间件、基础组件等，可以分别针对每个节点，基于预设的评价标准对三个调用信息：调用耗时、调用异常数据、调用次数进行评分，比如A节点，分别对于A节点的调用耗时、调用异常数据、调用次数进行评分；比如B节点，分别对于B节点的调用耗时、调用异常数据、调用次数进行评分；以此类推，这样共获得与四个节点相关的12个异常分数，对所述12个异常分数进行排序，判断前三个分数出现在哪三个节点，并设置预定规则，比如一个节点占了两个以上的前三分数，即可判定为疑似根因节点。当然，具体判定规则可以根据实际应用情况进行不同的设定，本申请对此不加以限定。

在本实施例中，通过对节点对应的软硬件的多个指标数据进行评分，获得异常分数，当判断到节点的异常分数占据的排名满足设定比例，确定节点为疑似根因节点，能达到评价客观、准确，易于采用的技术效果。

在本申请的一个实施例中，所述对所述软硬件之间的多个指标数据进行评分，获得异常分数，包括：

比如，以响应时长指标数据为例，所述异常分数的确定方法包括：

其中，MAD定义为绝对中位差(Median Absolute Deviation，MAD)，为数

据点到中位数的绝对偏差的中位数，也就是说，先计算出数据与它们的中位数之间的残差(偏差)，MAD就是这些偏差的绝对值的中位数。根据MAD确定异常分数，少量的异常值不会影响最终的结果。

以下具体对上述方法进行说明，上述方法具体包括：

针对每一个指标数据，获取功能异常时的每一个节点对应的所述指标数据，比如当前调用耗时；

获取功能异常时刻之前预设时间段内所述节点对应的所述指标数据的中位数，作为第一参考值，比如前N分钟调用耗时的中位数，其中，所述N的取值可以根据应用需求做不同的设定；

将所述功能异常时刻的所述节点对应的所述指标数据与所述参考值相减，获得所述指标数据偏差值；即：当前调用耗时-前N分钟调用耗时的中位数；

获得所述指标数据偏差值的绝对值，作为第二参考值；即：获得当前调用耗时-前N分钟调用耗时的中位数的结果的绝对值；

获取所有节点的所述指标数据的所有偏差值的绝对值的中位数，作为绝对中位差，即MAD；

获得所述第二参考值除以所述绝对中位差的结果，作为异常分数。

当然，需要说明的是，上述仅为一种可能的异常分数确定方法，实际的异常分数确定也可以采用其他的方法，具体视实际应用需求而定。

以下将参照图4及图5说明采用MAD获得的异常分数的效果。参照图4所示，图4为未采用MAD进行异常分数确定所获得的异常分数结果展示图。A节点调用B节点的异常分数确定方法为：

异常分数＝︱当前调用耗时-前N分钟调用耗时的中位数︱

由图4可见，其中包括了两幅图，左图中调用延时数据通常稳定，表现为从稳定到突然飘高，右图中调用延时数据通常不稳定，随意波动，尽管两种情况差异较大，但是采用当前的方法获得的异常分数一样，均为2000。实际上左图是更为明显的异常。而采用当前的异常分数确定方法导致难以对二者进行区分。

再参照图5所示，图5为采用MAD进行异常分数确定所获得的异常分数结果展示图。A节点调用B节点的异常分数确定方法为：

由图5可以看出，采用MAD后，左图获得的异常分数为1333.33，右图获得的异常分数为2.04，从而通过异常分数的差别，区分出左图为更加明显的异常，所以采用该方法可以更好地判定疑似根因节点。

可见，在本实施例中，采用MAD获得异常分数，可以更好地区分指标数据的差别，实现更准确地判定疑似根因节点。

在本申请中，根据异常分数来实现疑似根因节点的确定，可以采取以下方式：

第一种方式，异常分数得分高的排在疑似根因列表的前列，其为疑似根因节点的概率也更高。一种可行的做法是，将异常分数排名TOP3的节点作为疑似根因节点。

第二种方式，得出异常分数后，通过与预设阈值相比较，当异常分数大于预设阈值，确定对应的节点为疑似根因节点。

当异常分数大于30分时，调用延时、调用异常数已经偏离基线很远，再结合生产数据观测、分析，异常分数大于30分时，应用确实异常出现。所以，推荐阈值为30，具有应用中技术人员也可以结合应用自身实际情况做阈值调整。

在本申请的一个实施例中，所述方法还包括：

根据所述疑似根因节点的指标数据的异常分数确定所述所有疑似根因节点的根因概率值；

将根因概率值最大的疑似根因节点确定为最终根因节点。

可以理解的是，异常分数越大，根因概率越大。

在本实施例中，基于本申请的方法获得根因节点的根因概率值，并确定根因概率值最大的疑似根因节点为最终根因节点，相比于人工判断最终根因节点及根因指标的方法，具有缩短了根因分析的时间，可以提高根因节点判断的效率，从而提高故障排除效率，增强故障排除效果。

在本申请的一个实施例中，所述方法还包括：

在所述目标对象异常为应用响应异常的情况下，获取所有疑似根因节点中最下端的疑似根因节点，所述最下端的疑似根因节点为所述所有疑似根因节点的调用关系中没有下一层调用关系的疑似根因节点；

增大所述最下端的疑似根因节点的根因概率值。

在本实施例中，所述增大所述最下端的疑似根因节点的根因概率值，可以为将所述根因概率值增加一个预设值，或者增大一定倍数，或者增大一个系数等，都可以达到增大所述最下端的疑似根因节点的根因概率值的目的。

所述应用响应异常，包括响应报错、响应超时等。

在本实施例中，根据实际实验中的运维经验，在目标对象异常为应用响应异常的情况下，通常是所有疑似根因节点中的最下端的疑似根因节点为最终根因节点的概率值比较大，因此增加相应疑似根因节点的根因概率值，具有方法易用，针对性强的特点，可以提高根因节点判断的效率，从而提高故障排除效率，增强故障排除效果。

在本申请的一个实施例中，所述方法还包括：

在所述目标对象异常为应用流量异常的情况下，获取所有疑似根因节点中最上端的疑似根因节点，所述最上端的疑似根因节点为所述所有疑似根因节点的调用关系中没有上一层调用关系的疑似根因节点；

增大所述最上端的疑似根因节点的根因概率值。

在本实施例中，根据实际实验中的运维经验，在目标对象异常为应用流量异常的情况下，通常是所有疑似根因节点中的最上端的疑似根因节点为最终根因节点的概率值比较大，因此增加相应疑似根因节点的根因概率值，具有方法易用，针对性强的特点，可以提高根因节点判断的效率及准确率，从而提高故障排除效率，增强故障排除效果。

在本申请实施例中，所述方法还包括：获取根据两个以上指标数据的异常分数分别确定的根因概率值，将所述分别确定的根因概率值进行累计，将累计获得的结果作为疑似根因节点的根因概率值。比如根据两个指标数据分别对A应用进行评分，比如当指标数据分别为“响应时长”和“节点的成功率”，根据A应用的响应时长分析出A应用的根因概率为40％，根据A应用的节点的成功率也分析出A应用的根因概率为40％，则相加后，A应用的根因概率为80％。如果相加结果大于100％，则和所有疑似根因节点的概率一起等比缩小到100％以内，便于进一步的分析比较。

在本实施例中，通过对根因概率值进行累计，并确定根因概率累计值最大的疑似根因节点为最终根因节点，具有方法易用，针对性强的特点，可以进一步提高根因节点判断的准确性，从而提高故障排除效率，增强故障排除效果。

在本申请的一个实施例中，所述方法还包括：

获取所述最终根因节点的多个指标数据的第一时序走势数据，以及在所述目标对象异常的情况下，获取所述目标对象预设指标的第二时序走势数据；所述时序走势数据用于表征数据随时间的变化趋势；

根据所述第一时序走势数据和所述第二时序走势数据确定所述最终根因节点的最终根因指标。

在本实施例中，若所述指标数据的第一时序走势数据与所述预设指标的第二时序走势数据相关，则确定所述指标数据对应的指标为最终根因指标。

所述时序走势数据用于表征数据随时间的变化趋势。

在本实施例中，对于根因指标的判断，可以通过将指标数据的时序走势数据与目标对象对应指标数据的时序走势数据相比较，在目标对象对应指标数据的时序走势数据发生突变时，如果指标数据的时序走势数据也发生突变，则认为二者相关，从而可以判断即是该指标数据导致目标对象发生异常，从而确定了根因指标。所述相关可以是相似的情况，也可以是截然相反的情况，即二者的走势数据相似或者截然相反，都可以判断是所述根因指标导致目标对象异常发生，确定所述根因指标为最终根因指标。比如当目标对象为“提交申请单业务”，目标对象异常为响应延时，根据本申请实施例的方法判断到最终根因节点是A应用，那么需要获取A应用的指标数据的时序走势数据，在本实施例中，所述指标数据为FGC(全量垃圾回收)耗时，并且本实施例还获取“提交申请单业务”的响应时长时序走势数据，将FGC耗时的时序走势数据与“提交申请单业务”的响应时长时序走势数据相比较，如果二者在某一时刻均发生突变，则可以判断FGC耗时为A应用的最终根因指标。

在本实施例中，通过比较数据变化趋势，根据最终根因节点的指标数据的时序走势数据与目标对象异常时的预设指标的时序走势数据相比较，当判断到二者相关，则确定所述指标为最终根因指标，可以进一步提高根因指标判断的准确性，从而提高故障排除效率，增强故障排除效果。

下面通过具体应用中的实例对本申请技术方案进行示例性说明。

基于现有的根因定位方法凭人工总结的经验，存在人工判断根因困难、且耗时长的问题，并且在定位具体的根因指标时，也存在人工判断根因指标耗时较长的问题，本申请应用实例提供的方法可以实现快速的根因定位。下面将对本申请应用实例进行详细说明。

在本应用实例中，目标对象为业务，目标对象的标识为业务名称，按数据依赖关系，将本应用实例分为两大方法：业务关联的应用拓扑图生成方法、根因分析方法。参照图6所示，为本申请应用实例与目标对象对应的应用拓扑图生成方法流程图，所述业务关联的应用拓扑图生成方法，包括以下步骤：

步骤601，采集调用链路ID和业务名称绑定关系、调用链路信息；

基于全链路监控系统，通过研发全链路监控系统的业务埋点SDK插件，自动采集对应用的每一次调用的调用链路ID和业务名称绑定关系，用以得到影响该业务的实际应用及其数据库、中间件拓扑图。

举例来说，在一个具体的业务中，比如提交申请单业务，当发生提交申请单业务时A应用被调用，A应用与B中间件具有调用关系，系统可以同时获得A应用、调用链路ID和业务名称绑定关系，A应用处理完，传到B中间件，这样链路ID会传给B中间件，如果涉及调用其他应用，则调用链路ID会传给下一个应用。因为调用链路ID与业务名称有对应关系，并且调用链路ID与应用、数据库、中间件也有对应关系，从而影响该业务的实际应用及其数据库、中间件可以形成一个链条，而基于与业务关联的所有调用的各个链条，可以生成业务关联的应用调用拓扑图，便于后续针对这些应用做有针对性的根因分析。

在本应用实例中，“应用、数据库、中间件”统称为节点，所述中间件可以包括：消息中间件kafka，缓存中间件Redis等。

可见，基于现有的业务监控系统，通过做埋点插件的方式，得到调用链路ID和业务名称的绑定关系。但对应用需要有代码侵入的场景，则需要业务研发修改代码，配合做业务埋点时增加调用链路ID的操作。其目的也是基于埋点获得调用链路ID与业务的对应关系，从而影响该业务事件的实际应用及其数据库、中间件可以形成一个链条，最终生成业务关联的应用调用拓扑图。

此部分数据通过大数据组件Flink实时聚合，并存储下来。

步骤602，业务关联的应用拓扑图生成；

将所有影响业务的实际应用及其数据库、中间件可以形成的所有链条，组成业务关联的应用拓扑图。

以下对本申请应用实例中与目标对象对应的应用拓扑图生成过程进行描述。

使用业务埋点系统的“业务埋点SDK(软件开发工具包)”在“业务代码”里的写的“埋点代码”带有业务属性，比如：“提交申请单”业务代码里的埋点，就可以具有业务属性，表示此埋点代码在执行记录“提交申请单”业务。如图7中所示，示例性的示出了通过业务埋点系统可以区别各个业务，比如：审批业务发生时在业务代码做埋点(每次代码执行有对应的调用链ID)，放款业务发生时在业务代码做埋点；还款业务发生时在业务代码做埋点。而在各个业务被APM全链路追踪系统调用时，系统会获得调用链ID与业务ID的关联，并基于此关联关系通过大数据实时计算获得某类业务相关的应用调用拓扑图，从而某类业务异常时，只需分析相关的少数应用即可。而对比可以看出，现有的APM全链路追踪系统调用时有近千个应用全拓扑，过于复杂，不利于分析。可见，采用本申请的业务关联的应用调用拓扑图，具有提高分析速度，迅速定位根因的技术效果。

另外，根据实际需求，也可以通过给埋点SDK传入参数的方式获取其他附加业务属性，比如，获取在“哪个地域的用户提交的申请单等附加业务属性”，也可以通过给埋点SDK传入参数的方式获取，比如在授信业务领域，通过埋点的时候传入参数的方式标识业务来源于哪个地域，可以更精细区别业务，便于对业务做更多的有针对性的细致的分析。

有了业务属性以后，我们还想得到业务关联了哪些技术方面组件：应用、中间件、数据库等，以便在业务异常时我们该去集中精力关注这部分的组件。

埋点代码是写在业务代码中的，埋点代码会因为用户的http请求而被运行起来(技术上是一个http请求，业务上可能是一个“提交申请单”的请求)，每个到代码的http请求“全链路追踪系统”都会赋予其一个“链路ID”,链路ID串联了业务代码+埋点代码，以及上、下游所有应用、中间件、数据库。本申请应用实例通过获得“链路ID”串联节点的数据记录，获得了通过“链路ID”串联的业务埋点代码及其上、下游应用、数据库、中间件的数据记录情况。

一个http(超文本传输协议)调用得到一个调用链路ID及其完整的调用记录，每天成千上万个http调用，为了便于查看，以拓扑图的形式展现。基于调用链路ID和业务名称绑定关系，以及详尽的链路监控信息，所述链路监控信息包括各个节点的软硬件信息，比如软硬件的名称信息，得到业务指标关联的应用调用拓扑图。参照图7所示，为本申请应用实例中与目标对象对应的应用调用拓扑图示意图。图中第一节点701及第二节点702为最终根因节点，其他节点为普通节点。图中并示出了节点的根因概率值，其中，第一节点701的根因概率值为57.23％，第二节点702的根因概率值为42.45％。可见，采用本申请应用实例中的业务关联的应用调用拓扑图，可以直观的展现根因节点及其相互之间的关系，并能同时展示相关根因概率值，可以给运维系统提供更直观、更精准的参考。

步骤603，拓扑图存储，将业务关联的应用调用拓扑图存储到对应的图数据库。

可见，采用本申请应用实例中的业务所关联的应用调用拓扑图，排除了与业务不相关的节点，克服了APM全链路追踪系统每次分析时需要调用应用全拓扑图，所有业务和所有应用的关系在这一个应用全拓扑图上展示，未根据不同的业务分别建立对应的调用拓扑图，拓扑图过于复杂，不利于后续进行根因分析的弊端，本申请应用实例在故障分析时只需要分析与业务所关联的少数节点，具有缩小分析范围，提高根因分析定位效率的技术效果。

以上对拓扑图的生成方法进行了详细的描述，下面将对本申请应用实例中根因定位方法进行详细的描述。

参照图8所示，为本申请应用实例的用于根因分析的数据处理方法流程图，所述方法包括以下步骤：

步骤801，业务关联的各个节点间调用信息获得；

业务关联的各个节点间调用耗时、调用异常数据实时获得，在本应用实例中，根因分析基于各个节点间的指标数据：各个软硬件间一分钟内的调用耗时平均耗时、调用异常数、调用次数等。此部分数据通过大数据组件Flink实时聚合，并存储下来。需要做根因分析时，直接把数据提供给根因分析应用，即本申请的信息处理装置。从APM全链路追踪系统的原始调用数据包括的：每次调用应用的响应时长、每次调用应用是否异常、每次调用应用的其他数据等，通过大数据实时计算，获得应用的指标数据，比如包括：应用响应平均时长：3s，应用响应成功率：80％，应用流量异常(QPS)：1000，提供给本申请的信息处理装置。

步骤802，根因节点分析；

根因节点分析，根据对各个节点的指标数据进行评分，根据评分判断可能的根因节点列表，及根因列表中的各节点为根本原因的概率。

在本应用实例中，以响应时长指标数据为例，具体说明如何获得响应时长指标数据的异常分数：

其中，MAD定义绝对中位差(Median Absolute Deviation，MAD)，为数据点到中位数的绝对偏差的中位数，也就是说，先计算出数据与它们的中位数之间的残差(偏差)，MAD就是这些偏差的绝对值的中位数。根据MAD确定异常分数，少量的异常值不会影响最终的结果。

在本应用实例中，节点的指标数据异常分数得分高的排在根因列表的前列，其为根因节点的概率也更高。在本应用实例中，采用异常分数TOP3对应的节点作为疑似根因节点。异常分数越大，根因概率越大。

另外，得出异常分数后，也期望有一个阈值，判断异常分数多高才算应用有异常：

当异常分数大于30分时，调用延时、调用异常数已经偏离基线很远，再结合数据观测、分析，异常分数大于30分时，应用确实异常出现。所以，推荐阈值为30，具体也可以结合应用自身实际情况做阈值调整。

另外，本应用实例中，基于运维实验经验，发生业务响应异常时，比如响应慢、响应数据异常时，大概率是所有疑似根因节点中下游应用、中间件、数据库导致的，即下游应用、组件更可能响应慢、响应异常是根因。流量异常时，大概率是所有疑似根因节点中上游的应用就有流量异常，即上游应用更可能是流量异常的根因。

所以，在应用响应异常的情况下，获取所有疑似根因节点中最下端的疑似根因节点，所述最下端的疑似根因节点为所述所有疑似根因节点的调用关系中没有下一层调用关系的疑似根因节点；增大所述最下端的疑似根因节点的根因概率值。

在应用流量异常的情况下，获取所有疑似根因节点中最上端的疑似根因节点，所述最上端的疑似根因节点为所述所有疑似根因节点的调用关系中没有上一层调用关系的疑似根因节点；增大所述最上端的疑似根因节点的根因概率值。

最终汇总所有疑似根因节点的根因概率值：将上述方法的结果合并，同一个节点两个方法都命中，则根因概率值相加。

在本应用实例中，针对每一个指标数据，根据每个节点的所述指标数据的异常分数在多个节点对应的所述指标数据异常分数中的占比，确定所述疑似根因节点的根因概率值。

例如，在业务相关的节点中，计算出各个节点的响应时长的异常分数，比如：A节点异常分为1000分，B节点异常分为500分，C节点为400分，D节点异常分为3分。则把A节点作为响应时长异常的疑似根因节点，并记住A节点的异常分为1000分。

在业务相关的节点中，计算出各个节点的成功率的异常分数，比如：E节点异常分为800分，F节点异常分为700分，G节点为200分，H节点异常分为2分。则把E节点作为成功率异常的疑似根因节点，并记住E节点的异常分为800分。

在业务相关的节点中，计算出各个节点的流量的异常分数，比如：I节点异常分为90分，J节点异常分为60分，K节点为30分，M节点异常分为6分。则把I节点作为流量异常的疑似根因节点并记住I节点的异常分为90分。

最终根据上述三个疑似根因节点的异常分数，计算出疑似根因节点的根因概率值，见下表所示。

表1：疑似根因节点的根因概率计算

如果A节点和E节点为同一个节点，则合并根因概率值。其根因概率值为：52.91％+47.05％＝99.96％。

当然，上述仅为一种可能的示例，实际应用中可以进行其他的调整。

步骤803，根因指标分析：

根因指标分析，用以判断最终根因节点出现异常是由于哪些根因指标数据引起。在本应用实例中，根因指标可以为线程数、响应速度等。

参照图9所示，为本申请应用实例中指标数据与业务的相关性判断示意图。本应用实例中目标对象为“提交申请单业务”，目标对象异常为响应延时，根据本申请实施例的方法判断到最终根因节点是A应用，那么需要获取A应用的指标数据的时序走势数据，在本实施例中，所述指标数据为FGC(全量垃圾回收)耗时，并且本实施例还获取“提交申请单业务”的响应时长时序走势数据，将FGC耗时的时序走势数据与“提交申请单业务”的响应时长时序走势数据相比较。本应用实例中用到的是皮尔逊相关性系数，用监控到的业务的时间序列具体的走势数据与监控到的应用指标时间序列具体的走势数据做皮尔逊相关性分析，得到相关性系数。与业务异常相关性高的指标，就排列在根因指标列表的前列。如上图为一个示例，在本示例中，对应用的指标FGC(全量垃圾回收)耗时进行判断：全量垃圾回收耗时时序走势图和业务响应时长的时序图走势极为相识，都在某一时刻耗时增加，皮尔逊相关系数接近1。在本应用实例中，预设相关性系数阈值为0.5，相关性系数大于0.5的指标，为异常指标。当然，所述阈值仅仅为一个示例，应用负责人也可以根据应用自身情况对相关阈值进行调整。在本示例中，对于业务耗时增加这个业务异常，本应用实例可以确定所述全量垃圾回收指标为具体的最终根因指标。

步骤804，根因列表、拓扑图展现；

再次参见图7所示，拓扑图可以采用特殊颜色标记的方式，比如将第一节点701、第二节点702标红的形式展现最终根因节点(应用、中间件或数据库)，当然也可以通过其他方式，比如高亮的方式。根因指标通过列表形式展现。本申请应用实例具有根因节点及根因指标展示清晰的特点。

可见，采用本申请应用实例的根因分析方法，根据应用调用拓扑图获取业务关联的各个节点，根据对各个节点的指标数据进行评分获得异常分数，根据异常分数判断可能的根因节点，并根据异常分数获得各节点为根本原因的概率值，从而确定最终根因节点，具有评价标准客观，获得结果准确的效果；在确定了最终根因节点之后，对最终根因节点的指标数据走势与业务数据走势的相关性判断，确定根因指标，具有可视性强，对比清晰，获得结果准确的特点。本应用实例确定最终根因节点及根因指标的方法，相比于人工判断最终根因节点及根因指标的方法，缩短了根因分析的时间，提高了定位效率。

参照图10所示，为本申请实施例提供的数据处理装置结构示意图。所述数据处理装置，包括：

第一获取模块1001，用于获取与目标对象对应的应用调用拓扑图；其中，所述应用调用拓扑图包括多个节点及多条边，所述多个节点对应与所述目标对象相关联的多个软硬件；所述多条边对应所述软硬件之间的调用关系；

第二获取模块1002，用于根据所述应用调用拓扑图获取所述多个节点对应的软硬件信息及与所述软硬件对应的多个指标数据；

确定模块1003，用于根据所述软硬件对应的多个指标数据，确定所述多个节点中的疑似根因节点，所述疑似根因节点为调用异常的节点。

基于本申请实施例的装置，本申请实施例通过构建与目标对象所关联的应用调用拓扑图，当发生故障时，只需要根据与目标对象所关联的应用调用拓扑图，分析具有调用关系的各个节点，从而缩小分析的范围，提高了定位效率。

在本申请的一个实施例中，所述软硬件包括但不限于以下中的一种或者两种以上的任意组合：应用、数据库、中间件；

所述软硬件信息，包括但不限于以下中的一种或者两种以上的任意组合：名称信息、类型信息、版本信息；以及，

所述指标数据，包括但不限于以下中的一种或者两种以上的任意组合：调用耗时、调用异常数据、调用次数。

在本申请的一个实施例中，第一获取模块1001中所述多个节点对应的软硬件信息，所述软硬件之间的调用关系通过以下方法确定：

基于对所述软硬件的调用，获取所述软硬件的调用链路标识、所述目标对象的对象标识、以及所述调用链路标识与所述目标对象标识之间的对应关系；

根据所述对应关系，获取与同一目标对象标识相关的具有相同所述调用链路标识的所有软硬件的调用记录；

根据所述调用记录确定软硬件之间的调用关系和软硬件信息。

在本申请的一个实施例中，所述装置还包括定时任务模块，

定时任务模块1004，用于在预设时间间隔内调用软硬件的情况下，获取所述软硬件所关联的所有软硬件信息及软硬件之间的调用关系；

根据所述软硬件信息及调用关系，更新所述应用调用拓扑图。

在本申请的一个实施例中，所述装置还包括：

存储模块1005，用于将所述应用调用拓扑图存储到图数据库。

在本申请的一个实施例中，所述确定模块1003用于根据所述软硬件的多个指标数据，确定所述多个节点中的疑似根因节点，包括：

在所述目标对象异常的情况下，获取每个节点对应的软硬件的每个指标数据的异常分数，所述异常分数根据预设的评分标准确定；

若所述指标数据的异常分数符合预设判断规则，则确定所述节点为疑似根因节点。

在本申请的一个实施例中，所述确定模块1003还用于根据所述疑似根因节点的指标数据的异常分数确定所述疑似根因节点的根因概率值；

将根因概率值最大的疑似根因节点确定为最终根因节点。

在本申请的一个实施例中，所述确定模块1003还用于在所述目标对象为应用响应异常的情况下，获取所有疑似根因节点中最下端的疑似根因节点，所述最下端的疑似根因节点为所述所有疑似根因节点的调用关系中没有下一层调用关系的疑似根因节点；

增大所述最下端的疑似根因节点的根因概率值。

在本申请的一个实施例中，所述确定模块1003还用于在所述目标对象为应用流量异常的情况下，获取所有疑似根因节点中最上端的疑似根因节点，所述最上端的疑似根因节点为所述所有疑似根因节点的调用关系中没有上一层调用关系的疑似根因节点；

增大所述最上端的疑似根因节点的根因概率值。

在本申请的一个实施例中，所述确定模块1003还用于获取所述最终根因节点的多个根因指标的变化趋势；根据所述变化趋势确定最终根因指标。

本申请实施例关于装置的各个方面的描述，对应上述描述的数据处理方法，基于相同的技术构思，本申请实施例关于装置的各个方面的描述可以参考上述关于方法的各个方面的描述，本申请实施例在此不再赘述。

下面对本申请应用实例采用的数据处理方法的处理过程进行详细说明。

在本申请中，基于现有的全链路追踪系统，全链路追踪agent针对此SDK研发特定插件，以便拿到业务埋点中的业务名称等业务属性，同时也可以拿到该业务经过代码的链路ID(链路ID用于串联业务经过的所有应用的关键代码)。通过在应用中做业务监控埋点插件的方式，得到每次用户请求的调用链路信息，包括业务名称和调用链路ID的绑定关系。全链路追踪agent会把采集到的信息传递给链路监控信息收集组件，链路监控信息收集组件将链路监控信息存储在HBASE，实现长久保存，比如几天。以便后续通过链路ID查询链路经过的应用、数据库等组件。同时将调用链路信息及其对应的业务信息放到第一kafka中间件，便于后续的应用拓扑实时计算，后续从kafka取数据，可以降低HBASE压力。应用拓扑实时计算获得业务相关的应用拓扑，存储到neo4J图数据库。同时也计算出每个事件名称对应的链路ID及其链路上各个组件的耗时和异常数据。通过Flink基于应用调用拓扑图获得一个调用链路上的信息，将所述信息存储到第二kafka中间件，第二kafka中间件中的消息包括：每个事件的事件名称、transID及其调用链上个组件的耗时、异常；Flink实时计算各业务指标关联的各组件间的调用耗时、调用异常、调用次数，并将调用耗时、调用异常数据存储到ES(ElasticSearch分布式文档数据库)，提供给本申请应用实例的根因分析系统，本申请实施例提供的数据处理装置设置于根因分析系统，用于确定根因节点，并从应用指标监控系统获得根因节点的各项指标的时序数据，进行根因指标分析。并在根因展现系统通过业务关联的应用调用拓扑图的方式对分析结果进行展示，具体可以通过根因节点在应用拓扑图中标红方式展现根因节点。

在本申请应用实例中，通过在应用中设置埋点代码，从而使所述埋点代码带有业务属性，当承接某项业务时，对应用进行调用时，会同时调用应用的埋点代码，而埋点代码与调用链路ID具有对应关系，从而可以获得调用链路ID对应的业务名称，自动采集对应用的每一次调用的调用链路ID和业务名称绑定关系，用以得到影响该业务事件的实际应用及其数据库、中间件拓扑图。

通过本申请实施例，与业务相关的应用调用拓扑图能够实时生成，分析根因时只需专注于这个实时更新的、准确的拓扑图上的应用和中间件、数据库即可。

结合本本申请实施例提供的方法及装置自动完成的根因分析，可以减少定位根因的难度、协助业务异常问题处置人员更快速的定位根因。快速定位到根因以后才能着手解决根本性问题，进而解决业务异常，使业务恢复正常。

可见，本申请实施例可以解决传统的人工判断根因应用困难、且耗时长的问题，也可以解决传统的人工判断根因指标耗时较长的问题。

进一步地，对应上述描述的数据处理方法，基于相同的技术构思，本申请一个或多个实施例还提供一种电子设备，该设备用于执行上述的数据处理方法，图11为本申请一个或多个实施例提供的一种电子设备的结构示意图。

如图11所示，电子设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上的处理器1101和存储器1102，存储器1102中可以存储有一个或一个以上存储应用程序或数据。其中，存储器1102可以是短暂存储或持久存储。存储在存储器1102的应用程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括电子设备中的一系列计算机可执行指令。更进一步地，处理器1101可以设置为与存储器1102通信，在电子设备上执行存储器1102中的一系列计算机可执行指令。电子设备还可以包括一个或一个以上电源1103，一个或一个以上有线或无线网络接口1104，一个或一个以上输入输出接口1105，一个或一个以上键盘1106等。

在一个具体的实施例中，电子设备包括有存储器，以及一个或一个以上的程序，其中一个或者一个以上程序存储于存储器中，且一个或者一个以上程序可以包括一个或一个以上模块，且每个模块可以包括对电子设备中的一系列计算机可执行指令，且经配置以由一个或者一个以上处理器执行该一个或者一个以上程序包含用于执行以下计算机可执行指令：

获取与目标对象对应的应用调用拓扑图；其中，所述应用调用拓扑图包括多个节点及多条边，所述多个节点对应与所述目标对象相关联的多个软硬件；所述多条边对应所述软硬件之间的调用关系；

根据所述应用调用拓扑图获取所述多个节点对应的软硬件信息及与所述软硬件对应的多个指标数据；

根据所述软硬件对应的多个指标数据，确定所述多个节点中的疑似根因节点，所述疑似根因节点用于表征所述多个节点中调用异常的节点。

根据本申请实施例的方法，通过获取目标对象所关联的应用调用拓扑图，比如获取业务所关联的应用调用拓扑图，在异常发生时，问题处置人员只需要看到和这个目标对象所关联的应用调用拓扑图，所述应用调用拓扑图包括多个节点及多条边，所述多个节点对应与所述目标对象相关联的多个软硬件；所述多条边对应所述软硬件之间的调用关系，这样的拓扑图具有展示清晰，方便根因定位的特点。根据与目标对象所关联的应用调用拓扑图，通过根据所述应用调用拓扑图获取所述多个节点对应的软硬件信息及与所述软硬件对应的多个指标数据；根据所述软硬件对应的多个指标数据，确定所述多个节点中的疑似根因节点，从而缩小了根因分析的范围，缩短了根因分析的时间，提高了定位效率。

需要说明的是，本申请中关于电子设备的实施例与本申请中关于数据处理方法的实施例基于同一发明构思，因此该实施例的具体实施可以参见前述对应的数据处理方法的实施，重复之处不再赘述。

进一步地，对应上述描述的数据处理方法，基于相同的技术构思，本申请一个或多个实施例还提供了一种存储介质，用于存储计算机可执行指令，一个具体的实施例中，该存储介质可以为U盘、光盘、硬盘等，该存储介质存储的计算机可执行指令在被处理器执行时，能实现以下流程：

获取与目标对象对应的应用调用拓扑图；其中，所述应用调用拓扑图包括多个节点及多条边，所述多个节点对应与所述目标对象相关联的多个软硬件；所述多条边对应所述软硬件之间的调用关系；

根据所述应用调用拓扑图获取所述多个节点对应的软硬件信息及与所述软硬件对应的多个指标数据；

根据所述软硬件对应的多个指标数据，确定所述多个节点中的疑似根因节点，所述疑似根因节点用于表征所述多个节点中调用异常的节点。

本申请实施例方法根据不同的业务分别建立有对应的应用调用拓扑图，缩小了数据处理装置的分析数据范围，缩短了数据处理装置根因分析时间，提高了数据处理装置根因分析效率。根据与目标对象所关联的应用调用拓扑图获取所述多个节点对应的软硬件信息及与所述软硬件对应的多个指标数据；根据所述软硬件对应的多个指标数据，确定所述多个节点中的疑似根因节点，具有评价标准客观，获得结果准确的效果，本申请实施例相比于人工判断根因节点及根因指标的方法，缩短了根因分析的时间，提高了根因定位效率，在高效准确地获得了根因节点之后，方便迅速对根因节点故障进行排查，从而提高网络故障修复效率。

需要说明的是，本申请中关于存储介质的实施例与本申请中关于数据处理方法的实施例基于同一发明构思，因此该实施例的具体实施可以参见前述对应的数据处理方法的实施，重复之处不再赘述。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device，PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

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

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

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

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

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

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

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

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

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

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

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

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

Claims (12)

1.一种数据处理方法，其特征在于，所述方法包括：

获取与目标对象对应的应用调用拓扑图；其中，所述应用调用拓扑图包括多个节点及多条边，所述多个节点为与所述目标对象相关联的多个软硬件；所述多条边为所述软硬件之间的调用关系，所述应用调用拓扑图与所述目标对象对应的业务相关联；

根据所述应用调用拓扑图获取所述多个节点对应的软硬件信息及与所述软硬件对应的多个指标数据，所述软硬件，包括以下中的一种或者两种以上的任意组合：应用、数据库、中间件；

根据所述软硬件对应的多个指标数据，确定所述多个节点中的疑似根因节点，所述疑似根因节点为调用异常的节点。

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

所述软硬件信息，包括以下中的一种或者两种以上的任意组合：名称信息、类型信息、版本信息；

所述指标数据，包括以下中的一种或者两种以上的任意组合：

调用耗时、调用异常数据、调用次数。

3.根据权利要求1所述的方法，其特征在于，所述多个节点对应的软硬件信息，所述软硬件之间的调用关系通过以下方法确定：

基于对所述软硬件的调用，获取所述软硬件的调用链路标识、所述目标对象的对象标识、以及所述调用链路标识与所述目标对象标识之间的对应关系；

根据所述对应关系，获取与同一目标对象标识相关的具有相同所述调用链路标识的所有软硬件的调用记录；

根据所述调用记录确定软硬件之间的调用关系和软硬件信息。

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

在预设时间间隔内调用软硬件的情况下，获取所述软硬件所关联的所有软硬件信息及软硬件之间的调用关系；

根据所述软硬件信息及调用关系，更新所述应用调用拓扑图。

5.根据权利要求1所述的方法，其特征在于，

所述根据所述软硬件对应的的多个指标数据，确定所述多个节点中的疑似根因节点，包括：

在所述目标对象异常的情况下，获取每个节点对应的软硬件的每个指标数据的异常分数，所述异常分数根据预设的评分标准确定；

若所述指标数据的异常分数符合预设判断规则，则确定所述节点为疑似根因节点。

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

根据所述疑似根因节点的指标数据的异常分数确定所述疑似根因节点的根因概率值；

将根因概率值最大的疑似根因节点确定为最终根因节点。

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

在所述目标对象异常为应用响应异常的情况下，获取所有疑似根因节点中最下端的疑似根因节点，所述最下端的疑似根因节点为所述所有疑似根因节点的调用关系中没有下一层调用关系的疑似根因节点；

增大所述最下端的疑似根因节点的根因概率值。

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

在所述目标对象异常为应用流量异常的情况下，获取所有疑似根因节点中最上端的疑似根因节点，所述最上端的疑似根因节点为所述所有疑似根因节点的调用关系中没有上一层调用关系的疑似根因节点；

增大所述最上端的疑似根因节点的根因概率值。

9.根据权利要求6至8任意一项所述的方法，其特征在于，所述方法还包括：

获取所述最终根因节点的多个指标数据的第一时序走势数据，以及在所述目标对象异常的情况下，获取所述目标对象预设指标的第二时序走势数据；所述时序走势数据用于表征数据随时间的变化趋势；

根据所述第一时序走势数据和所述第二时序走势数据确定所述最终根因节点的最终根因指标。

10.一种数据处理装置，其特征在于，所述装置包括：

第一获取模块，用于获取与目标对象对应的应用调用拓扑图；其中，所述应用调用拓扑图包括多个节点及多条边，所述多个节点为所述目标对象相关联的多个软硬件；所述多条边为所述软硬件之间的调用关系，所述应用调用拓扑图与所述目标对象对应的业务相关联；

第二获取模块，用于根据所述应用调用拓扑图获取所述多个节点对应的软硬件信息及与所述软硬件对应的多个指标数据，所述软硬件，包括以下中的一种或者两种以上的任意组合：应用、数据库、中间件；

确定模块，用于根据所述软硬件对应的多个指标数据，确定所述多个节点中的疑似根因节点，所述疑似根因节点为调用异常的节点。

11.一种电子设备，包括：

处理器；以及，

被安排成存储计算机可执行指令的存储器，所述可执行指令被配置由所述处理器执行，所述可执行指令包括用于执行如权利要求1-9任一项所述的方法中的步骤。

12.一种存储介质，其特征在于，所述存储介质用于存储计算机可执行指令，所述可执行指令使得计算机执行如权利要求1-9任一项所述的方法。