CN112433915B - 一种基于分布式性能监控工具的数据监控方法及相关装置 - Google Patents

Abstract

本申请公开了一种基于分布式性能监控工具的数据监控方法及相关装置，通过Pinpoint(分布式性能监控工具)对数据进行监控，在获取监控数据时能够根据目标任务的目标任务标识分析出目标任务经过的各个处理节点。根据Pinpoint的预设规则确定各个节点间的继承关系，并以该继承关系作为该目标任务在各处理节点的执行顺序。此外，根据各个处理节点中每处节点针对目标任务所执行的操作来添加如下单、支付等业务层定义，并将该业务层定义作为操作标识添加到每个处理节点上。将该目标任务对应的各个处理节点按照上述执行顺序输出，并展示各处理节点的操作标识。通过上述方法，尽可能的解决现有的APM工具无法满足业务需求的问题。

Description

一种基于分布式性能监控工具的数据监控方法及相关装置

技术领域

本发明涉及数据处理技术领域，特别涉及一种基于分布式性能监控工具的数据监控方法及相关装置。

背景技术

在大数据的时代，分布式系统应用广泛。由于分布式系统内部调用链路复杂，多通过添加APM(Applications Manager，应用性能管理)工具来实现对分布式系统内重要数据的全链路追踪。但现有的APM工具仅能够反映各处理节点间的调用链路以及处理节点内各接口的访问性能，无法满足业务需求。

发明内容

本申请的目的是提供一种基于分布式性能监控工具的数据监控方法。用于解决现有的APM工具无法满足业务需求的问题。

第一方面，本申请实施例提供了一种基于分布式性能监控工具的数据监控方法，所述方法包括：

从分布式性能监控工具Pinpoint获取的监控数据中，根据目标任务的目标任务标识，分析出所述目标任务的处理节点信息；

从所述处理节点信息中识别出处理所述目标任务的各个处理节点，并根据各所述处理节点关联的继承关系，得到各所述处理节点的执行顺序；

根据各所述处理节点中每个所述处理节点针对所述目标任务执行的操作，得到各所述处理节点各自对应的操作标识；

输出所述目标任务的处理流程图，所述处理流程图中展示各所述处理节点的执行顺序以及各所述处理节点分别对应的操作标识。

在一些可能的实施例中，各处理节点支持至少一种接口，所述处理节点信息中包括各所述处理节点中与所述目标任务相关的各个接口；所述方法还包括：

针对每个所述处理节点，基于接口之间的调用关系，确定所述处理节点的与所述目标任务相关的各个接口之间的执行顺序；

所述根据各所述处理节点中每个所述处理节点针对所述目标任务执行的操作，得到各所述处理节点各自对应的操作标识，包括：

针对每个所述处理节点，基于接口之间的时序信息，确定所述处理节点的与所述目标任务相关的各个接口之间的执行顺序，并，基于接口与操作标识之间的预设对应关系，确定所述与所述目标任务相关的各个接口各自对应的所述操作标识；

其中，所述处理流程图中还包括与所述目标任务相关的各接口之间的执行顺序以及各接口对应的所述操作标识。

在一些可能的实施例中，根据所述目标任务的目标任务标识，分析出所述处理节点信息中的所述各个接口，包括：

从所述Pinpoint获取的所述监控数据中，筛选出处理节点的接口参数包含所述目标任务标识的接口。

在一些可能的实施例中，所述监控数据中包括所述各个接口被调用时的时序信息，所述方法还包括：

从监控数据分析出所述各个接口对应的所述时序信息，并根据所述时序信息确定所述各个接口的执行顺序；并，确定各所述接口分别处理的任务数量；

生成接口分析图并输出，所述接口分析图用于描述各个所述接口的任务标识以及各所述接口处理的任务数量。

在一些可能的实施例中，各所述接口处理的任务数量之间具有预设数量关系，所述方法还包括：

根据所述预设数量关系，分析出丢任务的异常接口。

在一些可能的实施例中，所述目标任务标识为目标任务编号，所述方法还包括：

响应于用户对所述目标任务编号的输入操作，获得所述目标任务的所述目标任务标识；

所述根据目标任务的目标任务标识，分析出所述目标任务的处理节点信息，包括：

当存在多个处理系统时，针对每个处理系统，从所述处理系统的统一资源定位符中的用于指示任务编号的字段中查询所述目标任务标识；

将查询到所述目标任务标识的统一资源定位符对应的接口确定为所述处理节点信息中包含的接口，并将所述接口对应的处理节点确定为处理所述目标任务的所述处理节点。

在一些可能的实施例中，各节点的所述监控数据中包括所述节点的节点标识，所述节点处理过的历史任务的历史任务标识，以及各所述历史任务标识对应的父节点标识；

根据目标任务的目标任务标识，分析出所述目标任务的各个处理节点信息中的处理节点，包括：

从所述监控数据的历史任务标识中查找所述目标任务标识，并将查找到的历史任务标识对应的节点作为目标任务的处理节点；

所述根据所述各个处理节点关联的继承关系，得到所述目标任务的所述各个处理节点的执行顺序，包括：

从所述各个处理节点的监控数据中，得到所述目标任务标识对应的父节点标识；

根据各所述处理节点的节点标识及其分别对应的父节点标识之间的父子关系，构建节点继承树，得到所述各个处理节点针对所述目标任务的执行顺序。

在一些可能的实施例中，所述方法还包括：

响应报错节点发送的报错消息，从所述报错消息中解析报错节点的报错节点标识以及事务标识符；

在数据库中查找所述报错节点标识以及所述事务标识符对应的统一资源定位符；

从所述统一资源定位符中获取所述目标任务的任务编号，生成携带所述任务编号的告警信息，并发送给指定终端设备。

在一些可能的实施例中，所述告警信息中还包括所述报错节点在指定时长内的处理日志信息。

在一些可能的实施例中，所述报错节点关联有日志信息，所述方法还包括：

对所述日志信息中的指定接口的处理日志部分进行分析，确定被调用失败的接口；

将所述被调用失败的接口以及调用所述被调用失败的接口作为目标接口并输出所述目标接口的信息。

第二方面，本申请实施例提供了一种基于分布式性能监控工具的数据监控装置，包括：

节点获取模块，用于从分布式性能监控工具Pinpoint获取的监控数据中，根据目标任务的目标任务标识，分析出所述目标任务的处理节点信息；

节点确定模块，用于从所述处理节点信息中识别出处理所述目标任务的各个处理节点，并根据各所述处理节点关联的继承关系，得到各所述处理节点的执行顺序；

节点标识模块，用于根据各所述处理节点中每个所述处理节点针对所述目标任务执行的操作，得到各所述处理节点各自对应的操作标识；

节点输出模块，用于输出所述目标任务的处理流程图，所述处理流程图中展示各所述处理节点的执行顺序以及各所述处理节点分别对应的操作标识。

在一些可能的实施例中，各处理节点支持至少一种接口，所述装置还包括：

接口获取模块，用于针对每个所述处理节点，基于接口之间的调用关系，确定所述处理节点的与所述目标任务相关的各个接口之间的执行顺序；

所述节点输出模块执行根据各所述处理节点中每个所述处理节点针对所述目标任务执行的操作，得到各所述处理节点各自对应的操作标识时，被配置为：

针对每个所述处理节点，基于接口之间的时序信息，确定所述处理节点的与所述目标任务相关的各个接口之间的执行顺序，并，基于接口与操作标识之间的预设对应关系，确定所述与所述目标任务相关的各个接口各自对应的所述操作标识；

其中，所述处理流程图中还包括与所述目标任务相关的各接口之间的执行顺序以及各接口对应的所述操作标识。

在一些可能的实施例中，所述接口获取模块执行根据所述目标任务的目标任务标识，分析出所述处理节点信息中的所述各个接口时，被配置为：

从所述Pinpoint获取的所述监控数据中，筛选出处理节点的接口参数包含所述目标任务标识的接口。

在一些可能的实施例中，所述监控数据中包括所述各个接口被调用时的时序信息，所述装置还包括：

接口确认单元，用于从监控数据分析出所述各个接口对应的所述时序信息，并根据所述时序信息确定所述各个接口的执行顺序；并，确定各所述接口分别处理的任务数量；

接口输出单元，用于生成接口分析图并输出，所述接口分析图用于描述各个所述接口的任务标识以及各所述接口处理的任务数量。

在一些可能的实施例中，各所述接口处理的任务数量之间具有预设数量关系，所述装置还包括：

异常接口识别单元，用于根据所述预设数量关系，分析出丢任务的异常接口。

在一些可能的实施例中，所述目标任务标识为目标任务编号，所述装置还包括：

标识获取模块，用于响应于用户对所述目标任务编号的输入操作，获得所述目标任务的所述目标任务标识；

所述节点获取模块执行根据目标任务的目标任务标识，分析出所述目标任务的处理节点信息时，被配置为：

当存在多个处理系统时，针对每个处理系统，从所述处理系统的统一资源定位符中的用于指示任务编号的字段中查询所述目标任务标识；

将查询到所述目标任务标识的统一资源定位符对应的接口确定为所述处理节点信息中包含的接口，并将所述接口对应的处理节点确定为处理所述目标任务的所述处理节点。

在一些可能的实施例中，各节点的所述监控数据中包括所述节点的节点标识，所述节点处理过的历史任务的历史任务标识，以及各所述历史任务标识对应的父节点标识；

所述节点确定模块执行根据目标任务的目标任务标识，分析出所述目标任务的各个处理节点信息中的处理节点时，被配置为：

从所述监控数据的历史任务标识中查找所述目标任务标识，并将查找到的历史任务标识对应的节点作为目标任务的处理节点；

所述根据所述各个处理节点关联的继承关系，得到所述目标任务的所述各个处理节点的执行顺序，包括：

从所述各个处理节点的监控数据中，得到所述目标任务标识对应的父节点标识；

根据各所述处理节点的节点标识及其分别对应的父节点标识之间的父子关系，构建节点继承树，得到所述各个处理节点针对所述目标任务的执行顺序。

在一些可能的实施例中，所述装置还包括：

报错消息解析模块，用于响应报错节点发送的报错消息，从所述报错消息中解析报错节点的报错节点标识以及事务标识符；

报错节点处理模块，用于在数据库中查找所述报错节点标识以及所述事务标识符对应的统一资源定位符；

告警信息发送模块，用于从所述统一资源定位符中获取所述目标任务的任务编号，生成携带所述任务编号的告警信息，并发送给指定终端设备。

在一些可能的实施例中，所述告警信息中还包括所述报错节点在指定时长内的处理日志信息。

在一些可能的实施例中，所述报错节点关联有日志信息，所述装置还包括：

日志分析模块，用于对所述日志信息中的指定接口的处理日志部分进行分析，确定被调用失败的接口；

目标接口处理模块，用于将所述被调用失败的接口以及调用所述被调用失败的接口作为目标接口并输出所述目标接口的信息。

第三方面，本申请另一实施例还提供了一种电子设备，包括至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本申请实施例提供的任一基于分布式性能监控工具的数据监控方法。

第四方面，本申请另一实施例还提供了一种计算机存储介质，所述计算机存储介质存储有计算机程序，所述计算机程序用于使计算机执行本申请实施例提供的任一基于分布式性能监控工具的数据监控方法。

本申请实施例，采用Pinpoint(分布式性能监控工具)对数据进行监控，在获取监控数据时能够根据目标任务的目标任务标识分析出目标任务经过的各个处理节点。根据Pinpoint的预设规则确定各个节点间的继承关系，并以该继承关系作为该目标任务在各处理节点的执行顺序。此外，根据各个处理节点中每处节点针对目标任务所执行的操作来添加如下单、支付等业务层定义，并将该业务层定义作为操作标识添加到每个处理节点上。将该目标任务对应的各个处理节点按照上述执行顺序输出，并展示各处理节点的操作标识。通过上述方法，尽可能的解决现有的APM工具无法满足业务需求的问题。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

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

图1为根据本申请一个实施例的应用环境的示意图；

图2a为根据本申请一个实施例的整体流程示意图；

图2b为根据本申请一个实施例的各处理节点执行顺序示意图；

图2c为根据本申请一个实施例的保险单号在分布式系统中的处理流程图；

图2d为根据本申请一个实施例的接口分析图；

图2e为根据本申请一个实施例的关联关系示意图；

图3为根据本申请一个实施例的数据监控装置图；

图4为根据本申请一个实施例的电子设备结构图。

具体实施方式

下面将结合附图对本申请实施例中的技术方案进行清楚、详尽地描述。在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；文本中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，另外，在本申请实施例的描述中，“多个”是指两个或多于两个。

在本申请实施例的描述中，除非另有说明，术语“多个”是指两个或两个以上，其它量词与之类似应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请，并且在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

为进一步说明本申请实施例提供的技术方案，下面结合附图以及具体实施方式对此进行详细的说明。虽然本申请实施例提供了如下述实施例或附图所示的方法操作步骤，但基于常规或者无需创造性的劳动在方法中可以包括更多或者更少的操作步骤。在逻辑上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本申请实施例提供的执行顺序。方法在实际的处理过程中或者控制设备执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行。

发明人发现，现有的APM工具无法以业务的角度反映出例如某一条业务数据如何在各系统中的执行情况，例如在保险业务场景中，当投保人投保时由于系统报错而无法成功投保时，针对该报错信息进行问题定位时，仅能从数据库及各节点的日志信息中逐个排查来进行问题定位，而无法通过APM工具所采集到的数据直接定位到问题点。故而导致人力资源和时间的浪费。再例如，APM工具虽然能够识别到系统中调用链路失败的节点，但无法通过对该节点所监控到的信息定位到引该节点调用链路失败而受到影响的保险单号，即，无法定位到对哪笔业务造成了影响。为解决上述问题，需要Pinpoint能够以业务角度展示业务数据在各系统中执行的可视化，并且在现有的Pinpoint能够检测到各处理节点间的调用链路基础上添加能够直接定位到具体业务的告警功能。故此，相关技术中APM监控的效果无法满足业务需求。

需要说明的是，发明人研究发现的内容不作为现有技术，其本质上属于本申请的一部分。

鉴于相关技术中APM监控的效果无法满足业务需求的问题，本申请提供了解决方案。本申请的发明构思为：在各开源APM工具中采用Pinpoint(分布式性能监控工具)对数据进行监控，在所获取的监控数据中根据目标任务的目标任务标识能够识别该目标任务所经过的各个处理节点。识别各个处理节点在Pinpoint中的继承关系，以各个处理节点间的继承关系作为目标任务在各处理节点间的执行顺序。此外，根据每各处理节点针对目标任务所执行的操作下达业务层定义(如保险行业中，针对保险单号各个处理节点会分别执行如下单、支付等功能)。将针对目标任务的各个处理节点按照执行顺序输出，并展示各节点处的业务层定义，通过上述方法，尽可能的解决现有的APM工具无法满足业务需求的问题。

此外，本申请在各节点的统一资源定位符中添加用于表示目标任务的业务字段，以使Pinpoint监控到目标任务的各处理节点中存在报错节点时，能够根据该报错节点在Pinpoint中的节点标识以及事务标识符在数据库中查询到该报错节点的统一资源定位符，进而获取统一资源定位符中的业务字段。以此实现Pinpoint能够从业务角度对数据进行监控。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

下面结合附图对本申请实施例中的基于分布式性能监控工具的数据监控方法进行详细说明。

参见图1，为根据本申请一个实施例的应用环境的示意图。

如图1所示，该应用环境中例如可以包括网络10、服务器20、至少一种终端设备30以及数据库40。其中：服务器20中采用Pinpoint通过网络10对终端设备30中执行的数据信息进行监控，并将监控信息存储到数据库40中。

服务器20可以是分布式系统的服务器集群或单个系统。在保险业务场景中，Pinpoint实时监控每笔保险业务在服务器集群或单个系统中的执行流程。并针对每笔保险业务的保险单号执行操作的处理节点进行记录，将该处理节点的url地址通过网络10存储到数据库40中。

在一些可能的实施例中，数据库40用于存储每笔保单的支付记录，终端设备30能够提交保单信息。终端设备30在响应投保人的下单操作后，通过网络10将该笔保险对应的支付记录发送给终端设备30。

本申请中的描述中仅就单个服务器或终端设备加以详述，但是本领域技术人员应当理解的是，图1示出的服务器20以及终端设备30旨在表示本申请的技术方案涉及的服务器为分布式系统中集成服务器中的至少一个，涉及的终端设备可如笔记本电脑、台式电脑、手机等具有页面展示和操作功能终端设备。对单个服务器和终端设备加以详述仅为了说明方便，而非暗示对终端设备和服务器的数量、类型或是位置等具有限制。

需要说明的是，虽然为了方便说明而在图1中示出了从数据库40到服务器20的双向箭头，但本领域技术人员可以理解的是，上述数据的收发也是需要通过网络10实现的。此外，本申请实施例中的存储系统例如可以是缓存系统、也可以是硬盘存储、内存存储等等。

随着大数据时代的到来，分布式服务系统在各大企业广泛应用，面对多台硬件服务器，需要APM工具对服务器中的数据进行监控，以保证服务器在出现报错和异常的情况下能够及时定位到出现问题的位置。在现有的开源APM中，由于Pinpoint具备代码级别的可见性，故此，本申请采用Pinpoint作为APM工具来对分布式系统中的数据进行监控。

图2a为本申请提供的基于分布式性能监控工具的数据监控方法的整体流程图，如图2a所示，包括以下步骤：

在下面针对本申请提供的一种基于分布式性能监控工具的数据监控方法的整体流程进行说明时，将通过如何实现Pinpoint从业务角度对监控数据进行可视化以及如何在Pinpoint添加告警功能进行分别说明，具体包括以下两部分：

部分1：实现Pinpoint从业务角度对监控数据进行可视化

步骤201：从分布式性能监控工具Pinpoint获取的监控数据中，根据目标任务的目标任务标识，分析出所述目标任务的处理节点信息。

Pinpoint在实施监控前需要设置在Pinpoint-Agent(探针采集)中的监控数据，根据Pinpoint的规则，会针对探针中所设置的监控数据添加事务标识符(TransactionId)。该事务标识符是针对目标任务在分布式系统中的唯一标识。例如在保险业务场景中，根据事务标识符能够从监控数据中识别出保险单号对应的各处理节点。而在针对保险单号进行监控时，需要对该保险单号添加用于表述该保险单号的唯一标识，故此，可以将该保险单号在Pinpoint中生成的事务标识符作为目标任务标识。而保险单号作为每份保险的唯一标识，保险单号也同样具备唯一性，还可以将保险单号作为目标任务标识。此外，基于目标任务标识具有唯一性的原则，还可以将保险单号以及该保险单号在Pinpoint中生成的事务标识符进行组合，作为目标任务的目标任务标识。

虽然本申请实施例中多以保险行业中针对保险单号的数据监控举例进行说明。应清楚的是，本申请实施例中的目标任务不仅可以是保险单号，针对不同的行业还可以是如学生卡号、车牌号等数据，只要存在从业务层面来展示业务处理逻辑需求的场景均适用于本申请实施例。

对Pinpoint监控数据进行分析梳理，能够获取到该目标任务所经过的所有处理节点，以及处理节点对应的接口。将目标任务的处理节点和接口作为处理节点信息。针对处理节点信息中包含的，目标任务经过的各个处理节点，执行步骤202：从所述处理节点信息中识别出处理所述目标任务的各个处理节点，并根据各所述处理节点关联的继承关系，得到各所述处理节点的执行顺序。并进一步执行步骤203：根据各所述处理节点中每个所述处理节点针对所述目标任务执行的操作，得到各所述处理节点各自对应的操作标识。

需要说明的是，步骤202和步骤203中关于确定各个处理节点的执行顺序以及操作标识这两个操作之间，无执行顺序的限制。即可以先确定各个处理节点的执行顺序，后确定不同处理节点的各自对应的操作标识，也可以先确定操作标识，后确定不同处理节点的执行顺序，甚至可以同时执行确定执行顺序和识别操作标识的步骤。

1)、关于得到各个处理节点的执行顺序

Pinpoint在对各处理节点进行监控时能够获取到各个处理节点的节点标识(SpanId)、该处理节点处理过的历史任务的历史任务标识以及各历史任务标识对应的父节点标识(ParentSpanId)。例如在对保险单号的处理节点进行监控时获取各处理节点的历史任务标识以及节点标识，针对历史任务标识进行筛选，若存在与目标任务标识相同的历史任务标识，则将该历史任务标识所在的节点作为该保险单号的一个处理节点，并确定该历史任务标识对应的父节点标识。根据各处理节点的节点标识以及父节点标识确定各处理节点间的继承关系，并将该继承关系作为各处理节点的执行顺序。.

为了便于理解如何根据各处理节点的节点数据得到各处理节点的执行顺序，以针对同一保险单号的处理节点Node1、Node2、Node3以及Node4举例进行说明，具体如图2b所示，由于Node1调用Node2，而Node2先后调用了Node3和Node4，故此，Node1对应的节点标识SpanId＝1、Node2对应的节点标识SpanId＝2、Node3对应的节点标识SpanId＝3、Node4对应的节点标识SpanId＝4；由于Node1是发起RPC调用的起点，即Node1没有父节点(或父节点为空)，根据Poinpint的规则，Node1的ParentSpanId＝﹣1；由于Node1调用了Node2，故此，Node1是Node2的父节点，即，Node2的父节点标识应为Node1的节点标识，即Node2的ParentSpanId＝1。在得到处理节点Node1、Node2、Node3以及Node4的继承关系后，以Node1为起始点按照继承顺序确定各处理节点的执行顺序。

2)、关于得到各个处理节点的操作标识

为了能够以业务角度详细的展示各个处理节点执行的操作，本申请实施例中，针对每个节点支持的功能，以及每个节点可调用的接口的功能可预先进行分析整理，得到不同节点与操作功能的对应关系，亦或者不同接口和不同操作功能之间的对应关系。在这两种对象关系中操作功能均采用相应的操作标识来表示。

由此，通过上述的对应关系，可确定各个处理节点对应的操作标识。继续以图2c所示的保单处理为例，针对每个处理节点基于保险单号所执行的操作添加操作标识。例如Node1节点在接收该保险单号后，会执行下单操作，并将该保险单号作为请求参数发送给用于执行支付操作的Node2节点处，故此，在Node1节点处关联“下单”标识，在Node2节点处关联“支付”标识。

此外，由于Pinpoint能够监控到各个处理节点所对应的接口，还可以更细粒度的针对每个接口基于保险单号所执行的操作添加操作标识。例如用户在投保时，会调用Node1节点用于执行投保操作的接口，执行投保操作后会调用Node2节点中用于执行核保操作的接口。故此，在Node1节点用于执行投保操作的接口处关联“投保”标识，在Node2节点用于执行核保操作的接口处关联“核保”标识。

基于前述步骤202和步骤203，得到的各处理节点的执行顺序和操作标识之后，可以在步骤204：输出所述目标任务的处理流程图，所述处理流程图中展示各所述处理节点的执行顺序以及各所述处理节点分别对应的操作标识。

在一些可能的实施例中，将该保险单号对应的各处理节点按照各处理节点的继承关系构建节点继承树，并根据节点继承树确定各处理节点的执行顺序。将各处理节点按照执行顺序输出，并展示各处理节点处添加的操作标识，以此作为保险单号在分布式系统中的处理流程图，具体如图2c所示。

在一些可能的实施例中，将该保险单号对应的各处理节点的继承关系作为执行顺序进行输出，同时在各处理节点处添加该处理节点所对应的接口。并展示各处理节点处添加的操作标识以及各接口处添加的操作标识，以此作为保险单号在分布式系统中的处理流程图。

基于上述为各处理节点添加操作标识的思想，可以更细粒度的拓扑到处理节点下的各个接口。在接口的url地址中添加用于表示该接口针对保单号所执行的业务操作的操作标识，如投保请求接口、核保请求接口、承保请求接口以及支付请求接口等。根据各接口的操作标识能够在使用Pinpoint对分布式系统集群内的接口或单独某个系统内的接口进行监控时，按照接口的操作标识将执行同一业务操作的接口根据预设时间进行统计，有助于从业务角度分析数据。

在一些可能的实施例中，针对各接口的调用次数预设数量关系。若识别到某一接口的调用次数不满足预设数量关系，则确定该接口为记录丢失的异常接口。例如承保接口的调用次数预设与支付接口的调用次数相同，若识别到承保接口被调用10万次，而支付接口调用了8万次，则说明支付接口处丢失了2万笔业务数据，该支付接口为丢失记录的异常接口。

根据接口的操作标识对接口进行分类后，可按照操作标识的执行顺序将携带有接口调用次数的数据生成接口分析图，进行输出展示，以便于监管人员查看。具体可如图2d所示，按照接口操作标识的业务顺序(先投保，然后核保，之后承保，最后支付)。将预设时间为24小时内的分布式系统集群中，用于执行对保单进行投保、核保、承保以及支付功能的接口的调用次数进行展示。

另需说明的是上述流程中通过确定接口调用次数来确认该接口所执行的任务数量与按照时序信息确定各个接口的调用顺序在执行时的先后顺序本申请对此不作限定，可根据实际应用场景自行设定。

在一些可能的实施例中，基于ORM(Object Relational Mapping，对象关系映射)的思想，将接口url中所添加的用于表示操作标识的字段映射到数据库表中，以此实现针对每一次接口调用的统计。

此外，由于分布式系统集群中的接口数量过于庞大，对所有接口进行记录并存储会造成资源浪费。在一些可能的实施例中，针对用于监控的接口url中添加用于被Pinpoint探针所监控的请求参数。Pinpoint针对监控到的数据进行识别操作，若监控数据中识别到接口url中的包含目标任务标识的请求参数，则将该接口所对应的处理节点及接口作为处理节点信息进行存储。若未从接口url中识别到包含目标任务标识的请求参数，则自动过滤该监控数据。

由此，本申请实施例中通过对目标任务标识的处理节点的监控数据进行跟踪处理，能够得到目标业务的业务层面的相关信息，并输出展示，以便于能够根据实际业务需求监控每个业务的处理历史。

此外，本申请实施例中，不仅可以在业务层面实现对业务的监控，还可以实现对业务的报警处理，下面将对此进行说明。

部分2：在Pinpoint添加告警功能

发明人考虑到现有的APM工具中不具备告警需求，本申请实施例中Pinpoint能够识别到各处理节点的调用状态，并定位出调用失败的处理节点。例如本申请实施例中可以将定位失败的处理节点标红显示。

例如实施时，在各处理节点所对应的url地址参数中添加用于表示保险单号的字段，采用url地址携带用于表示保单号的字段，作为向不同系统下发任务时的请求参数。当检测到存在报错节点时，针对该报错节点进行识别，获取该报错节点的节点标识以及事务标识符。根据该报错节点的节点标识和事务标识符在数据库中查找到该报错节点的url地址，并从url地址中识别到保险单号，根据该保险单号定位到保险单号对应的业务，以此实现通过Pinpoint从业务角度对数据进行监控。

在一些可能的实施例中，通过修改数据库的配置信息可以在数据库中建立Pinpoint库，当各处理节点针对保险单号执行操作时，Pinpoint库中能够实时记录各处理节点对应的url地址，从而获取订单号。并记录该处理节点当前处理任务的事务标识符，该处理节点的节点标识以及父节点标识，从而针对同一任务，建立订单号(可选项)、url(可选型)、事务标识符、节点标识之间的对应关系。

在Pinpoint发现报错节点时，能够根据该报错节点的节点标识和事务标识符在Pinpoint中定位到该处理节点所对应的url地址。进一步的，在根据报错节点所对应的url地址识别到保险单号后，可将该保险单号对应的订单号作为告警信息，并通过即时通讯应用的API(Application Programming Interface,应用程序编程接口)发送给监管人员，以此实现告警功能。

在一些可能的实施例中，基于AOP技术(面向切面编程)在各处理节点中添加用于记录该处理节点内部各接口调用时间的计时信息，若存在接口调用时长大于指定时长，则确定该接口为出错的问题接口。此外，还可以根据日志中记录的调用失败、或超时处理的消息来确定接口为出错的问题接口，相应的节点为报错节点。

发明人考虑到Pinpoint中的事务标识符虽然全局唯一，但无法仅通过事务标识符定位到业务数据(即，无法通过事务标识查询哪份保单业务出现问题)。为解决上述问题，实施时将分布式系统集群中，各系统内用于表示保单号的字段进行关联，具体可如图2e所示，保单号在A系统中定义为policyNo、在B系统中定义为proposalNo。将不同系统中用于表示保单号的请求参数进行关联设定，若请求参数的字段值相同则建立关联关系。当针对某一保单业务进行查询时，通过对用于表示该保单号的请求参数定位到该节点url地址(统一资源定位符)中，根据与该url地址相关联的其他系统中的url能够确定该保单业务的整个业务流程经历哪些系统、哪些处理节点以及每个处理节点所对应的接口。此外，根据每个接口被调用的时序信息，能够确定针对保单号执行相关操作时，各处理节点及各处理节点对应的接口在不同系统的前后调用关系。

此外，为了使监管人员能够及时定位到报错节点的报错原因，在告警信息中还可以添加报错节点在预设时间内的处理日志信息。具体实施时，可在各处理节点处关联如Log4(日志代码)等日志功能。由于该日志功能可以记录预设时间内该处理节点中各接口的调用情况，故此在Pinpoint识别到报错节点后，通过对报错节点管理的日志信息进行分析，能够识别到该报错节点中的问题接口。例如日志信息中显示报错节点的B接口调用失败，则将B接口以及调用B接口的A接口作为问题接口，并将问题接口添加在告警信息中，以供监管人员能够快速定位到该报错节点产生报错的位置。

本申请通过上述流程对Pinpoint进行二次开发，能够在针对目标任务的处理流程进行监控时，识别到该目标任务对应的业务。并在该业务的处理流程出现报错时，能够及时定位到该业务的问题所在。例如投保人投保时，会针对该业务在分布式系统中的处理流程输出处理流程图，该处理流程图中具有该业务在各处理节点的执行情况以及各处理节点的操作标识。当投保人下单失败时，通过识别报错节点的url地址获取到该业务对应的保单号，并根据报错节点所产生的告警信息定位到该节点下的问题接口。以此实现从业务的角度展示业务数据在各系统中执行的可视化问题。

基于问题接口还可以根据该问题接口在一定时间段内处理的保单号获得处理失败的保单。例如，定位出问题接口后，可将该问题接口一定时间内处理的保单号筛选出来，然后针对每个保单号，确认该保单号对应的保单的处理流程，分析出该保单是否处理完成，若未处理完成则确认该保单处理失败。

在一些可能的实施例中，若从问题接口的url地址中识别到保单号，则确定该保单号对应的保单业务在该问题接口处受到了影响。进一步按照时序信息确定该问题接口调用的下一接口，若该问题接口调用的下一接口url地址中未识别到保单号，或未识别到该问题接口调用的下一接口，则说明保单业务在该问题接口处流程中断。

基于相同的发明构思，本申请还提供一种基于分布式性能监控工具的数据监控装置300，如图3所示，该装置包括：

节点获取模块301，用于从分布式性能监控工具Pinpoint获取的监控数据中，根据目标任务的目标任务标识，分析出所述目标任务的处理节点信息；

节点确定模块302，用于从所述处理节点信息中识别出处理所述目标任务的各个处理节点，并根据各所述处理节点关联的继承关系，得到各所述处理节点的执行顺序；

节点标识模块303，用于根据各所述处理节点中每个所述处理节点针对所述目标任务执行的操作，得到各所述处理节点各自对应的操作标识；

节点输出模块304，用于输出所述目标任务的处理流程图，所述处理流程图中展示各所述处理节点的执行顺序以及各所述处理节点分别对应的操作标识。

在一些可能的实施例中，各处理节点支持至少一种接口，所述装置还包括：

接口获取模块，用于针对每个所述处理节点，基于接口之间的调用关系，确定所述处理节点的与所述目标任务相关的各个接口之间的执行顺序；

所述节点输出模块执行根据各所述处理节点中每个所述处理节点针对所述目标任务执行的操作，得到各所述处理节点各自对应的操作标识时，被配置为：

针对每个所述处理节点，基于接口之间的时序信息，确定所述处理节点的与所述目标任务相关的各个接口之间的执行顺序，并，基于接口与操作标识之间的预设对应关系，确定所述与所述目标任务相关的各个接口各自对应的所述操作标识；

其中，所述处理流程图中还包括与所述目标任务相关的各接口之间的执行顺序以及各接口对应的所述操作标识。

在一些可能的实施例中，所述接口获取模块执行根据所述目标任务的目标任务标识，分析出所述处理节点信息中的所述各个接口时，被配置为：

从所述Pinpoint获取的所述监控数据中，筛选出处理节点的接口参数包含所述目标任务标识的接口。

在一些可能的实施例中，所述监控数据中包括所述各个接口被调用时的时序信息，所述装置还包括：

接口确认单元，用于从监控数据分析出所述各个接口对应的所述时序信息，并根据所述时序信息确定所述各个接口的执行顺序；并，确定各所述接口分别处理的任务数量；

接口输出单元，用于生成接口分析图并输出，所述接口分析图用于描述各个所述接口的任务标识以及各所述接口处理的任务数量。

在一些可能的实施例中，各所述接口处理的任务数量之间具有预设数量关系，所述装置还包括：

异常接口识别单元，用于根据所述预设数量关系，分析出丢任务的异常接口。

在一些可能的实施例中，所述目标任务标识为目标任务编号，所述装置还包括：

标识获取模块，用于响应于用户对所述目标任务编号的输入操作，获得所述目标任务的所述目标任务标识；

所述节点获取模块执行根据目标任务的目标任务标识，分析出所述目标任务的处理节点信息时，被配置为：

当存在多个处理系统时，针对每个处理系统，从所述处理系统的统一资源定位符中的用于指示任务编号的字段中查询所述目标任务标识；

将查询到所述目标任务标识的统一资源定位符对应的接口确定为所述处理节点信息中包含的接口，并将所述接口对应的处理节点确定为处理所述目标任务的所述处理节点。

在一些可能的实施例中，各节点的所述监控数据中包括所述节点的节点标识，所述节点处理过的历史任务的历史任务标识，以及各所述历史任务标识对应的父节点标识；

所述节点确定模块执行根据目标任务的目标任务标识，分析出所述目标任务的各个处理节点信息中的处理节点时，被配置为：

从所述监控数据的历史任务标识中查找所述目标任务标识，并将查找到的历史任务标识对应的节点作为目标任务的处理节点；

所述根据所述各个处理节点关联的继承关系，得到所述目标任务的所述各个处理节点的执行顺序，包括：

从所述各个处理节点的监控数据中，得到所述目标任务标识对应的父节点标识；

根据各所述处理节点的节点标识及其分别对应的父节点标识之间的父子关系，构建节点继承树，得到所述各个处理节点针对所述目标任务的执行顺序。

在一些可能的实施例中，所述装置还包括：

报错消息解析模块，用于响应报错节点发送的报错消息，从所述报错消息中解析报错节点的报错节点标识以及事务标识符；

报错节点处理模块，用于在数据库中查找所述报错节点标识以及所述事务标识符对应的统一资源定位符；

告警信息发送模块，用于从所述统一资源定位符中获取所述目标任务的任务编号，生成携带所述任务编号的告警信息，并发送给指定终端设备。

在一些可能的实施例中，所述告警信息中还包括所述报错节点在指定时长内的处理日志信息。

在一些可能的实施例中，所述报错节点关联有日志信息，所述装置还包括：

日志分析模块，用于对所述日志信息中的指定接口的处理日志部分进行分析，确定被调用失败的接口；

目标接口处理模块，用于将所述被调用失败的接口以及调用所述被调用失败的接口作为目标接口并输出所述目标接口的信息。

关于监控中各操作的实施以及有益效果可参见前文方法中的描述，此处不再赘述。

在介绍了本申请示例性实施方式的基于分布式性能监控工具的数据监控方法和装置之后，接下来，介绍根据本申请的另一示例性实施方式的电子设备。

所属技术领域的技术人员能够理解，本申请的各个方面可以实现为系统、方法或程序产品。因此，本申请的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

在一些可能的实施方式中，根据本申请的电子设备可以至少包括至少一个处理器、以及至少一个存储器。其中，存储器存储有程序代码，当程序代码被处理器执行时，使得处理器执行本说明书上述描述的根据本申请各种示例性实施方式的基于分布式性能监控工具的数据监控方法中的步骤。例如，处理器可以执行如基于分布式性能监控工具的数据监控方法中的步骤。

下面参照图4来描述根据本申请的这种实施方式的电子设备130。图4显示的电子设备130仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图4所示，电子设备130以通用电子设备的形式表现。电子设备130的组件可以包括但不限于：上述至少一个处理器131、上述至少一个存储器132、连接不同系统组件(包括存储器132和处理器131)的总线133。

总线133表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、外围总线、处理器或者使用多种总线结构中的任意总线结构的局域总线。

存储器132可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)1321和/或高速缓存存储器1322，还可以进一步包括只读存储器(ROM)1323。

存储器132还可以包括具有一组(至少一个)程序模块1324的程序/实用工具1325，这样的程序模块1324包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

电子设备130也可以与一个或多个外部设备134(例如键盘、指向设备等)通信，还可与一个或者多个使得用户能与电子设备130交互的设备通信，和/或与使得该电子设备130能与一个或多个其它电子设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口135进行。并且，电子设备130还可以通过网络适配器136与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器136通过总线133与用于电子设备130的其它模块通信。应当理解，尽管图中未示出，可以结合电子设备130使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

在一些可能的实施方式中，本申请提供的一种基于分布式性能监控工具的数据监控方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在计算机设备上运行时，程序代码用于使计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的一种监控中的步骤。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本申请的实施方式的用于监控的程序产品可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在电子设备上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户电子设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户电子设备上部分在远程电子设备上执行、或者完全在远程电子设备或服务端上执行。在涉及远程电子设备的情形中，远程电子设备可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户电子设备，或者，可以连接到外部电子设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

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

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

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

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

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (9)

1.一种基于分布式性能监控工具的数据监控方法，其特征在于，所述方法包括：

从分布式性能监控工具Pinpoint获取的监控数据中，根据目标任务的目标任务标识，分析出所述目标任务的处理节点信息；

从所述处理节点信息中识别出处理所述目标任务的各个处理节点，并根据各所述处理节点关联的继承关系，得到各所述处理节点的执行顺序；其中，各所述处理节点支持至少一种接口，所述处理节点信息中包括各所述处理节点中与所述目标任务相关的各个接口；

针对每个所述处理节点，基于接口之间的调用关系，确定所述处理节点的与所述目标任务相关的各个接口之间的执行顺序；

针对每个所述处理节点，基于接口之间的时序信息，确定所述处理节点的与所述目标任务相关的各个接口之间的执行顺序，并，

基于接口与操作标识之间的预设对应关系，确定所述与所述目标任务相关的各个接口各自对应的所述操作标识；

输出所述目标任务的处理流程图，所述处理流程图中包括与所述目标任务相关的各接口之间的执行顺序以及各接口对应的所述操作标识。

2.根据权利要求1所述的方法，其特征在于，根据所述目标任务的目标任务标识，分析出所述处理节点信息中的所述各个接口，包括：

从所述Pinpoint获取的所述监控数据中，筛选出处理节点的接口参数包含所述目标任务标识的接口。

3.根据权利要求1所述的方法，其特征在于，所述监控数据中包括所述各个接口被调用时的时序信息，所述方法还包括：

从监控数据分析出所述各个接口对应的所述时序信息，并根据所述时序信息确定所述各个接口的执行顺序；并，

确定各所述接口分别处理的任务数量；

生成接口分析图并输出，所述接口分析图用于描述各个所述接口的任务标识以及各所述接口处理的任务数量。

4.根据权利要求1所述的方法，其特征在于，所述目标任务标识为目标任务编号，所述方法还包括：

响应于用户对所述目标任务编号的输入操作，获得所述目标任务的所述目标任务标识；

所述根据目标任务的目标任务标识，分析出所述目标任务的处理节点信息，包括：

当存在多个处理系统时，针对每个处理系统，从所述处理系统的统一资源定位符中的用于指示任务编号的字段中查询所述目标任务标识；

将查询到所述目标任务标识的统一资源定位符对应的接口确定为所述处理节点信息中包含的接口，并将所述接口对应的处理节点确定为处理所述目标任务的所述处理节点。

5.根据权利要求1所述的方法，其特征在于，各节点的所述监控数据中包括所述节点的节点标识，所述节点处理过的历史任务的历史任务标识，以及各所述历史任务标识对应的父节点标识；

根据目标任务的目标任务标识，分析出所述目标任务的各个处理节点信息中的处理节点，包括：

从所述监控数据的历史任务标识中查找所述目标任务标识，并将查找到的历史任务标识对应的节点作为目标任务的处理节点；

所述根据各所述处理节点关联的继承关系，得到各所述处理节点的执行顺序，包括：

从所述各个处理节点的监控数据中，得到所述目标任务标识对应的父节点标识；

根据各所述处理节点的节点标识及其分别对应的父节点标识之间的父子关系，构建节点继承树，得到所述各个处理节点针对所述目标任务的执行顺序。

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

响应报错节点发送的报错消息，从所述报错消息中解析报错节点的报错节点标识以及事务标识符；

在数据库中查找所述报错节点标识以及所述事务标识符对应的统一资源定位符；

从所述统一资源定位符中获取所述目标任务的任务编号，生成携带所述任务编号的告警信息，并发送给指定终端设备。

7.一种基于分布式性能监控工具的数据监控装置，其特征在于，所述装置包括：

节点获取模块，用于从分布式性能监控工具Pinpoint获取的监控数据中，根据目标任务的目标任务标识，分析出所述目标任务的处理节点信息；

节点确定模块，用于从所述处理节点信息中识别出处理所述目标任务的各个处理节点，并根据各所述处理节点关联的继承关系，得到各所述处理节点的执行顺序；其中，各所述处理节点支持至少一种接口，所述处理节点信息中包括各所述处理节点中与所述目标任务相关的各个接口；

接口获取模块，用于针对每个所述处理节点，基于接口之间的调用关系，确定所述处理节点的与所述目标任务相关的各个接口之间的执行顺序；

节点标识模块，用于针对每个所述处理节点，基于接口之间的时序信息，确定所述处理节点的与所述目标任务相关的各个接口之间的执行顺序，并，基于接口与操作标识之间的预设对应关系，确定所述与所述目标任务相关的各个接口各自对应的所述操作标识；

节点输出模块，用于输出所述目标任务的处理流程图，所述处理流程图中包括与所述目标任务相关的各接口之间的执行顺序以及各接口对应的所述操作标识。

8.一种电子设备，其特征在于，包括至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1-6中任何一项所述的方法。

9.一种计算机存储介质，其特征在于，所述计算机存储介质存储有计算机程序，所述计算机程序用于使计算机执行如权利要求1-6任何一项所述的方法。

Images