CN110516971A - 异常检测的方法、装置、介质和计算设备 - Google Patents

Abstract

本发明的实施方式提供了一种异常检测的方法。该方法包括：获取针对应用程序的多个任务流，多个任务流中的每一任务流包括多个任务节点；确定血缘关系，血缘关系指示了所述多个任务流之间的依赖关系以及多个任务流中各任务节点之间的依赖关系；响应于检测到异常事件，确定与异常事件直接相关的第一任务节点；以及根据第一任务节点和血缘关系，从多个任务流中确定造成异常事件的根源任务流。本发明根据血缘关系和与异常事件直接相关的第一任务节点，能够较为快速地确定造成异常事件的根源任务，从而提高了检测效率。此外，本发明的实施方式提供了一种异常检测的装置、一种介质和一种计算设备。

Description

异常检测的方法、装置、介质和计算设备

技术领域

本发明的实施方式涉及计算机技术领域，更具体地，本发明的实施方式涉及一种异常检测的方法、装置、介质和计算设备。

背景技术

本部分旨在为权利要求书中陈述的本发明的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

数据仓库(Data Warehouse)，是为企业所有级别的决策制度过程提供所有类型数据支持的战略集合。其可以为需要业务智能的企业提供指导业务流程改进、监视时间、成本、质量以及控制。

目前，相关技术对于数据仓库任务(以下简称数仓任务)的异常检测采用如下方法：在发生异常事件时，遍历查询所有数据模型直至找到出错的数据模型，再根据该数据模型找到与之对应的数仓任务，然后根据数仓任务的直接层级(直接上游或者直接下游)递归向该数仓任务上游进行溯源。

但是，相关技术方案根据数仓任务之间直接层级的关系查找异常源头，涉及大量的递归运算。

因此在相关技术中，实现异常检测的过程需要消耗较多运算资源，效率较低，这是非常令人烦恼的过程。

发明内容

为此，非常需要一种改进的异常检测的方法，以减少异常检测消耗的运算资源，提高检测的效率。

在本上下文中，本发明的实施方式期望提供一种异常检测的方法、装置、介质和计算设备。

在本发明实施方式的第一方面中，提供了一种异常检测的方法，包括：获取针对应用程序的多个任务流，所述多个任务流中的每一任务流包括多个任务节点；确定血缘关系，所述血缘关系指示了多个任务流之间的依赖关系以及多个任务流中各任务节点之间的依赖关系；响应于检测到异常事件，确定与异常事件直接相关的第一任务节点；以及根据第一任务节点和血缘关系，从多个任务流中确定造成异常事件的根源任务流。

在本发明的一个实施例中，上述确定血缘关系，包括：执行应用程序；通过监测多个任务流中各任务节点的执行进程，确定血缘关系。

在本发明的另一实施例中，上述根据第一任务节点和所述血缘关系，从多个任务流中确定造成异常事件的根源任务流，包括以下步骤：步骤1，根据血缘关系，确定第一任务节点所依赖的至少一个第二任务节点；步骤2，针对至少一个第二任务节点中的每一个第二任务节点，检测每一个第二任务节点是否异常，若检测到存在异常的第二任务节点，则执行步骤3，若检测不到存在异常的第二任务节点，则执行步骤4；步骤3，将存在异常的第二任务节点确定为新的第一任务节点，并跳转执行步骤1；以及步骤4，将第一任务节点所属的任务流确定为根源任务流。

在本发明的又一个实施例中，上述方法还包括：从多个任务流中确定待恢复任务流；获取待恢复任务流的历史运行数据，所述历史运行数据包括每次执行待恢复任务流前的等待时长以及待恢复任务流每次执行时长；根据历史运行数据，确定待恢复任务流的平均等待时长和平均执行时长；基于待恢复任务流的平均等待时长和平均执行时长，确定异常恢复预估时刻；以及输出异常恢复预估时刻。

在本发明的再一个实施例中，上述基于待恢复任务流的平均等待时长和平均执行时长，确定异常恢复预估时刻包括：获取待恢复任务流所依赖的任务流的预估结束时刻；根据以下公式计算异常恢复预估时刻：异常恢复预估时刻＝待恢复任务流所依赖的任务流的预估结束时刻+待恢复任务流的平均等待时长+待恢复任务流的平均执行时长。

在本发明的再一个实施例中，所述方法还包括：判断异常恢复预估时刻是否大于时间阈值；以及若异常恢复预估时刻大于时间阈值，则生成报警信息。

在本发明的再一个实施例中，上述异常事件包括以下事件中的一种或多种：任务流的执行过程中出现错误；以及任务流的运行结果不符合预定要求。

在本发明实施方式的第二方面中，提供了一种异常检测的装置，包括：任务流获取模块，用于获取针对应用程序的多个任务流，所述多个任务流中的每一任务流包括多个任务节点；血缘关系确定模块，用于确定血缘关系，所述血缘关系指示了多个任务流之间的依赖关系以及多个任务流中各任务节点之间的依赖关系；第一确定模块，用于响应于检测到异常事件，确定与异常事件直接相关的第一任务节点；以及根源任务流确定模块，用于根据第一任务节点和血缘关系，从多个任务流中确定造成异常事件的根源任务流。

在本发明的另一个实施例中，上述血缘确定模块包括：执行子模块，用于执行应用程序；血缘确定子模块，用于通过监测多个任务流中各任务节点的执行进程，确定血缘关系。

在本发明的又一个实施例中，上述根源任务流确定模块，包括：第二确定子模块，用于根据血缘关系，确定第一任务节点所依赖的至少一个第二任务节点；检测子模块，用于针对至少一个第二任务节点中的每一个第二任务节点，检测每一个第二任务节点是否异常；第三确定子模块，用于在检测到存在异常的第二任务节点的情况下，将存在异常的第二任务节点确定为新的第一任务节点；以及第四确定子模块，用于在检测不到存在异常的第二任务节点的情况下，将第一任务节点所属的任务流确定为根源任务流。

在本发明的再一个实施例中，上述装置还包括：待恢复任务流确定模块，用于从多个任务流中确定待恢复任务流；历史运行数据获取模块，用于获取待恢复任务流的历史运行数据，所述历史运行数据包括每次执行所述待恢复任务流前的等待时长以及待恢复任务流每次执行时长；第五确定模块，用于根据历史运行数据，确定待恢复任务流的平均等待时长和平均执行时长；异常恢复预估时刻确定模块，用于基于待恢复任务流的平均等待时长和平均执行时长，确定异常恢复预估时刻；以及输出模块，用于输出异常恢复预估时刻。

在本发明的再一个实施例中，上述异常恢复预估时刻确定模块包括：预估结束时刻获取子模块，用于获取待恢复任务流所依赖的任务流的预估结束时刻；计算子模块，用于根据以下公式计算异常恢复预估时刻：异常恢复预估时刻＝待恢复任务流所依赖的任务流的预估结束时刻+待恢复任务流的平均等待时长+待恢复任务流的平均执行时长。

在本发明的再一个实施例中，该装置还包括：判断模块，用于判断异常恢复预估时刻是否大于时间阈值；以及报警模块，用于在异常恢复预估时刻大于时间阈值的情况下，生成报警信息。

在本发明的再一个实施例中，该异常事件包括以下事件中的一种或多种：任务流的执行过程中出现错误；以及任务流的运行结果不符合预定要求。

在本发明实施方式的第三方面中，提供了一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行上述异常检测的方法。

在本发明实施方式的第四方面中，提供了一种计算设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行上述异常检测的方法。

根据本发明的实施例，通过确定血缘关系和与异常事件直接相关的第一任务节点，然后根据血缘关系和第一任务节点，确定造成异常事件的根源任务流，相比于根据直接层级的关系查找根源任务的方案，所需运算资源更少，检测效率更高，从而为用户带来了更好的体验。

附图说明

通过参考附图阅读下文的详细描述，本发明示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本发明的若干实施方式，其中：

图1示意性地示出了根据本发明实施例的异常检测的方法可以应用的系统架构；

图2A示意性地示出了根据本发明实施例的异常检测的方法的流程图；

图2B示意性地示出了根据本发明实施例的数据产品应用的方框图；

图2C示意性地示出了根据本发明另一实施例的根据第一任务节点和血缘关系，从多个任务流中确定造成异常事件的根源任务流的方法流程图；

图2D示意性地示出了根据本发明另一实施例的各任务节点的血缘关系的示意图；

图3A示意性地示出了根据本发明另一实施例的异常检测的方法的流程图；

图3B示意性地示出了根据本发明另一实施例的各任务流的血缘关系的示意图；

图4A示意性地示出了根据本发明又一实施例的异常检测的装置的框图；

图4B示意性地示出了根据本发明另一实施例的血缘确定模块的框图；

图4C示意性地示出了根据本发明另一实施例的根源任务流确定模块的框图；

图5A示意性地示出了根据本发明又一实施例的异常检测的装置的框图；

图5B示意性地示出了根据本发明又一实施例的异常恢复预估时刻确定模块的框图；

图6示意性地示出了根据本发明又一实施例的异常检测的装置的框图；

图7示意性地示出了根据本发明实施例的计算机可读存储介质的示意图；以及

图8示意性地示出了根据本发明实施例的计算设备的示意图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参考若干示例性实施方式来描述本发明的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本发明的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本发明的实施方式，提出了一种异常检测的的方法、装置、介质和计算设备。

在本文中，需要理解的是，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

下面参考本发明的若干代表性实施方式，详细阐释本发明的原理和精神。

发明概述

数据仓库任务(例如离线任务)的最小运行单元为任务节点(job)，一个数据仓库任务即为一个任务流(flow)，一个数据仓库任务流通常由多个节点组成，任务流内不同的任务节点之间具有一定的运行依赖关系。当任务流内所有的任务节点按照依赖关系全部运行完成，即表示该任务流运行完成。此外，若一个任务流的触发条件是另一个任务流中的某一个任务节点，例如任务流A的执行依赖任务B流中的任务节点b的执行结果，则这两个任务流之间存在依赖关系。

本发明人发现，如果能够构建完整的针对数据仓库任务全局的血缘关系，那么根据该血缘关系就能够实现对数据仓库任务的定位，通过将这种定位方式应用于异常检测中，可以较快地定位作为异常根源的数据仓库任务，从而提高检测效率。

在介绍了本发明的基本原理之后，下面具体介绍本发明的各种非限制性实施方式。

应用场景总览

首先参考图1，图1示意性示出了根据本发明实施例的异常检测的方法可以应用的系统架构100。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，根据该实施例的系统架构100可以包括终端设备101、102、103，网络104和数据仓库105。网络104用以在终端设备101、102、103和数据仓库105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与数据仓库105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

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

数据仓库105可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。

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

示例性方法

下面结合图1的应用场景，参考图2A-2C来描述根据本发明示例性实施方式的异常检测的方法。需要注意的是，上述应用场景仅是为了便于理解本发明的精神和原理而示出，本发明的实施方式在此方面不受任何限制。相反，本发明的实施方式可以应用于适用的任何场景。

如图2A所示，本发明示例性实施方式的异常检测的方法包括以下操作S210～S240。

具体地，在操作S210，获取针对应用程序的多个任务流。

根据本发明的实施例，上述应用程序例如可以为数据产品应用。图2B示意性示出了数据产品应用的方框图，如图2B所示，数据产品应用20包括多个页面，例如页面21和页面22。每个页面又包括多个模块，例如模块23、模块24、模块25和模块26。另外，每个模块又包括多个数据模型，每个数据模型由多个数据仓库任务构成。一个数据仓库任务对应一个任务流，每一任务流又可以细分为多个任务节点。

在操作S220，确定血缘关系。

根据本发明的实施例，血缘关系指示了所述多个任务流之间的依赖关系以及所述多个任务流中各任务节点之间的依赖关系。

根据本发明的实施例，操作S220例如可以包括执行上述数据产品应用，通过监测多个任务流中各任务节点的执行进程，确定多个任务流之间的依赖关系以及多个任务流中各任务节点之间的依赖关系。

具体地，可以设置全局唯一的追踪标识(traceId)，然后在每一次发生任务节点的调用时，传递该traceId，这样通过追踪traceId的传递过程即可得到各任务节点之间的调用关系，从而也得到了各任务节点以及各任务流之间的依赖关系(若任务节点A的调用需要先执行任务节点B，则A依赖于B，也即B被A依赖)。

接下来，在操作S230，响应于检测到异常事件，确定与异常事件直接相关的第一任务节点。

根据本发明的实施例，异常事件包括任务流执行失败或任务流的运行结果不符合预定要求。若任务流执行失败，则将该任务流中执行失败的任务节点作为第一任务节点。若任务流的运行结果不符合预定要求，则将生成该运行结果的任务节点作为第一任务节点。可以理解的是，第一任务节点可以为一个也可以为多个。

根据本发明的实施例，例如可以通过以下方法检测上述异常事件：判断数据产品应用展示的指标是否异常，若指标异常，则通过查询“任务流-数据模型-模块-页面-数据产品应用”的链路关系，获取发生异常事件的任务流。

在本发明的另一实施例中，也可以通过以下方法检测上述异常事件：对各个任务流的运行进行监控，判断各任务流是否命中预设的监控规则，若某个任务流命中了监控规则，则表示其发生了异常事件。

在操作S240，根据第一任务节点和血缘关系，从多个任务流中确定造成异常事件的根源任务流。

根据本发明的实施例，操作S240例如可以包括以第一任务节点作为起点，沿着血缘关系向上游寻找造成异常事件的根源任务流。

下面结合图2C对S240作进一步说明。

图2C示意性示出了根据第一任务节点和血缘关系，从多个任务流中确定造成异常事件的根源任务流的示例方法。

如图2C所示，操作S240例如可以包括以下操作S241～S244。

具体地，在操作S241，根据血缘关系，确定第一任务节点所依赖的任务节点作为第二任务节点。可以理解的是，第一任务节点所依赖的第二任务节点至少有一个。

在操作S242，检测每一个第二任务节点是否异常，若检测到至少一个存在异常的第二任务节点，则执行操作S243，若检测不到存在异常的第二任务节点，即每一个第二任务节点均不存在异常，则执行操作S244。

在操作S243，将存在异常的第二任务节点确定为新的第一任务节点，并跳转执行操作S241。

在操作S244，将第一任务节点所属的任务流确定为根源任务流。

根据本发明的实施例，通过确定血缘关系和与异常事件直接相关的第一任务节点，然后根据血缘关系和第一任务节点，确定造成异常事件的根源任务流。相比于根据直接层级的关系查找根源任务的方案，所需运算资源更少，检测效率更高，从而为用户带来了更好的体验。

为了便于理解本发明实施例的技术方案，下面结合图2D和具体实施例对图2C所示的方法做进一步说明。本领域技术人员可以理解，以下描述仅为示例，本公开实施例并不局限于此。

本示例中，任务节点包括a1、a2、a3、b1、b2、b3和c1，各任务节点血缘关系如图2D所示，其中，符号“→”用于表示两个任务节点之间的依赖关系，该符号后的任务节点依赖于该符号前的任务节点。

假设c1为第一任务节点，那么首先确定c1所依赖的任务节点有a3和b3，a3和b3即为第二任务节点。接着分别检测a3和b3是否异常，得到的结果是a3异常，b3不异常。由于检测到了存在异常的第二任务节点a3，那么将存在异常的a3作为新的第一任务节点。再确定a3所依赖的任务节点有a1和a2，a1和a2即作为新的第二任务节点。然后分别检测a1和a2是否异常，得到的结果是a1和a2均不异常，即检测不到存在异常的第二任务节点，那么便可以确定a3就是造成异常发生的根源任务节点，而a3所属的任务流即为根源任务流。

根据本发明的实施例，在上述确定根源任务流的基础上，还可以进一步根据“任务流-数据模型-模块-页面-数据产品应用”的链路关系，确定该异常涉及的数据模型、模块、页面或数据产品应用，从而可以让用户了解受该此异常影响的各数据模型、模块、页面或数据产品应用。

图3A示意性示出了根据本发明的另一实施例的异常检测的方法。

如图3A所示，该方法除了上述操作S210～S240之外还包括以下操作S310～S350。

具体地，在操作S310，从多个任务流中确定待恢复任务流。

根据本发明的实施例，操作S310例如可以包括，从应用程序的所有任务流中确定受到异常事件影响导致需要重新运行的任务流，即待恢复任务流。

在操作S320，获取待恢复任务流的历史运行数据。

根据本发明的实施例，可以收集一定时间区间内各个任务流和各个任务节点在每次执行前等待的时长以及每次执行时消耗的时长，将其汇总作为历史运行数据。

在操作S330，根据历史运行数据，确定待恢复任务流的平均等待时长和平均执行时长。

根据本发明的实施例，根据历史运行数据，运用平均值算法计算各个任务流和各个任务节点的平均等待时长和平均执行时长。

在操作S340，基于待恢复任务流的平均等待时长和平均执行时长，确定异常恢复预估时刻。

根据本发明的实施例，操作S340例如可以包括获取待恢复任务流所依赖的任务流的预估结束时刻，然后根据异常恢复预估时刻计算公式计算异常恢复预估时刻。

根据本发明的实施例，异常恢复预估时刻计算公式例如可以为：

F1的异常恢复预估时刻＝F2的预估结束时刻+F1的平均等待时长+F1的平均执行时长。

其中，F1为待恢复任务流，F2为F1所依赖的任务流。可以理解的是，F1所依赖的任务流可以有一个也可以有多个。在F1所依赖的任务流只有一个的情况下，F2即代指该任务流。而在F1所依赖的任务流有多个的情况下，F2则代指F1所依赖的多个任务流中预估结束时刻最晚的任务流。

F2的预估结束时刻可以通过计算F2的异常恢复预估时刻来得到，计算方法可以参考上述F1的异常恢复预估时刻的计算方法，在此不再赘述。

如果F2为造成异常事件的根源任务流，则F2的预估结束时刻＝F2开始执行的时刻+F2的平均执行时长，其中，F2开始执行的时间可以为开发人员重启F2的时刻。如果F2不是造成异常事件的根源任务流，也即F2也具有至少一个所依赖的任务流，则F2的预估结束时刻即为F2的异常恢复预估时刻，具体计算方法可以参考上述F1的异常恢复预估时刻的计算方法，在此不再赘述。

在操作S350，输出异常恢复预估时刻。

根据本发明的实施例，对于负责修复的开发人员来说，异常恢复预估时刻能够预估任务流的数据产出时间，有利于协助开发人员进行修复工作。对于使用应用程序的用户来说，应用程序的底层逻辑对用户是不透明的，因此用户往往不清楚异常恢复的进程，从而导致集中客诉。而异常恢复预估时刻能让用户提前了解此次异常恢复大概需要多长时间，使用户有一定心理预期，从而提高了用户体验。

根据本发明的实施例，还可以预先设置时间阈值，该时间阈值表示开发人员预期的异常恢复时刻。在上述得到异常恢复预估时刻之后，进一步判断异常恢复预估时刻是否大于时间阈值，并在异常恢复预估时刻大于时间阈值，则生成报警信息，以提示开发人员任务流的数据产出时间可能晚于预期。开发人员可以根据报警信息及时采取相关行动，从而更高质量地保证了应用程序的可靠性。

为了便于理解本发明实施例的技术方案，下面结合图3B和具体实施例对图3A所示的方法做进一步说明。本领域技术人员可以理解，以下描述仅为示例，本公开实施例并不局限于此。

本示例中，商品模块需要展示不同商品的“访问-支付-转化率”这一核心数据指标。根据公式：访问-支付-转化率＝支付人数/访问UV，为了计算这一核心数据指标，需要两部分基础数据：一个是商品的UV(Unique visitor，访客数)，一个是商品的支付人数。其中，商品的UV来源于日志数据，商品的支付人数来源于业务DB(Data Base，数据库)。

根据本发明的实施例，首先执行数据产品应用，通过监测多个任务流中各任务节点的执行进程可以发现：对于访问UV的获得，需要通过日志采集任务流A1获取原始日志记录，再通过任务流A2对原始日志记录进行数据清洗(例如包括检查数据一致性，处理无效值和缺失值等)，获取每个商品的访问明细记录，然后通过任务流A3对访问明细记录进行计算，从而得到访问UV。

另一方面，对于支付人数的获得，需要通过数据同步任务流B1将支付数据从业务DB同步至HDFS(Hadoop Distributed File System，Hadoop分布式文件系统)中，再通过任务流B2将支付数据按每个商品分组，然后分别计算每组所对应的支付人数。

因此，对于计算″访问-支付-转化率″这一统计指标的任务流C，需要任务流A1→A2→A3以及B1→B2依次执行完毕才能执行，即任务流C依赖于A3和B2，A3和B2又分别依赖于A2和B1，A2又依赖于A1。据此可以得到如图3B所示的各任务流的血缘关系(此处略去了各任务节点之间的血缘关系)。

任务流C在实际执行过程中，如果出现运行异常(任务执行失败或者数据质量原因导致的异常)，造成任务流C产出的″访问-支付-转化率″统计指标异常，则根据血缘关系可以快速的溯源发现DB同步任务流B1是异常的根源，从而导致了B1→B2→C1的异常。接下来根据“任务流-数据模型-模块-页面-数据产品应用”的链路关系，可以确定B1→B2→C1异常会导致数据大屏(数据产品应用)、活动页面(数据页面)、热销商品模块(模块)的异常，并及时将这些异常的相关信息告知数据产品应用的使用方。

同时，运行异常恢复预估时刻算法，首先根据公式：B1的预估结束时刻＝B1的开始执行的时刻+B1的平均执行时长，确定B1的预估结束时刻，接下来根据公式：B2的预估结束时刻＝B1的预估结束时刻+B2的平均等待时长+B2的平均执行时长，计算B2的预估结束时刻，然后根据公式：C1的异常恢复预估时刻＝B2的预估结束时刻+C1的平均等待时长+C1的平均执行时长，计算C1的异常恢复预估时刻。

另外，若计算得到的C1的异常恢复预估时刻晚于时间阈值，即表示C1的数据产出时间超出预期，则进行报警处理，从而更高质量的保障了数据产品应用的可靠性。

示例性装置

在介绍了本发明示例性实施方式的异常检测的方法之后，接下来，参考图4A对本发明示例性实施方式的异常检测的装置作进一步说明。

如图4A所示，该异常检测的装置400包括任务流获取模块410、血缘关系确定模块420、第一确定模块430以及根源任务流确定模块440。

其中，任务流获取模块410，用于获取针对应用程序的多个任务流，所述多个任务流中的每一任务流包括多个任务节点。

血缘关系确定模块420，用于确定血缘关系，所述血缘关系指示了多个任务流之间的依赖关系以及多个任务流中各任务节点之间的依赖关系。

第一确定模块430，用于响应于检测到异常事件，确定与异常事件直接相关的第一任务节点。

根源任务流确定模块440，用于根据第一任务节点和血缘关系，从多个任务流中确定造成异常事件的根源任务流。

图4B示意性地示出了根据本发明另一实施例的血缘确定模块的框图。

如图4B所示，在本发明的另一个实施例中，血缘确定模块420包括：执行子模块421和血缘确定子模块422。

其中，执行子模块421，用于执行应用程序。

血缘确定子模块422，用于通过监测多个任务流中各任务节点的执行进程，确定血缘关系。

图4C示意性地示出了根据本发明另一实施例的根源任务流确定模块的框图。

如图4C所示，在本发明的另一个实施例中，根源任务流确定模块440包括：第二确定子模块441、检测子模块442、第三确定子模块443和第四确定子模块444。

其中，第二确定子模块441，用于根据血缘关系，确定第一任务节点所依赖的至少一个第二任务节点。

检测子模块442，用于针对至少一个第二任务节点中的每一个第二任务节点，检测每一个第二任务节点是否异常。

第三确定子模块443，用于在检测到存在异常的第二任务节点的情况下，将存在异常的第二任务节点确定为新的第一任务节点。

第四确定子模块444，用于在检测不到存在异常的第二任务节点的情况下，将第一任务节点所属的任务流确定为根源任务流。

根据本发明的实施例，通过确定血缘关系和与异常事件直接相关的第一任务节点，然后根据血缘关系和第一任务节点，确定造成异常事件的根源任务流，相比于根据直接层级的关系查找根源任务的方案，所需运算资源更少，检测效率更高，从而为用户带来了更好的体验。

图5A示意性地示出了根据本发明又一实施例的异常检测的装置的框图。

如图5A所示，在本发明的又一个实施例中，除了任务流获取模块410、血缘关系确定模块420、第一确定模块430以及根源任务流确定模块440之外，装置500还包括：待恢复任务流确定模块510、历史运行数据获取模块520、第五确定模块530和异常恢复预估时刻确定模块540。

其中，待恢复任务流确定模块510，用于从多个任务流中确定待恢复任务流。

历史运行数据获取模块520，用于获取待恢复任务流的历史运行数据，所述历史运行数据包括每次执行所述待恢复任务流前的等待时长以及待恢复任务流每次执行时长。

第五确定模块530，用于根据历史运行数据，确定待恢复任务流的平均等待时长和平均执行时长。

异常恢复预估时刻确定模块540，用于基于待恢复任务流的平均等待时长和平均执行时长，确定异常恢复预估时刻；以及输出模块，用于输出异常恢复预估时刻。

图5B示意性地示出了根据本发明又一实施例的异常恢复预估时刻确定模块的框图。

如图5B所示，在本发明的又一个实施例中，异常恢复预估时刻确定模块540包括：预估结束时刻获取子模块541和计算子模块542。

其中，预估结束时刻获取子模块541，用于获取待恢复任务流所依赖的任务流的预估结束时刻。

计算子模块542，用于根据以下公式计算异常恢复预估时刻：异常恢复预估时刻＝待恢复任务流所依赖的任务流的预估结束时刻+待恢复任务流的平均等待时长+待恢复任务流的平均执行时长。

图6示意性地示出了根据本发明又一实施例的异常检测的装置的框图。

如图6所示，在本发明的又一个实施例中，装置600还包括：判断模块610和报警模块620

其中，判断模块610，用于判断异常恢复预估时刻是否大于时间阈值。

报警模块620，用于在异常恢复预估时刻大于时间阈值的情况下，生成报警信息。

示例性介质

在介绍了本发明示例性实施方式的异常检测的装置之后，接下来，参考图7对本发明示例性实施方式的一种计算机可读存储介质进行说明。本发明示例性实施方式提供了一种计算机可读存储介质，其上存储有可执行指令，所述指令被处理单元执行时使所述处理单元执行上文所述的方法。

在一些可能的实施方式中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算设备上运行时，所述程序代码用于使所述计算设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的异常检测的方法中的步骤，例如，所述计算设备可以执行如图2中所示的操作S210，获取针对应用程序的多个任务流；操作S220，确定血缘关系；操作S230，响应于检测到异常事件，确定与异常事件直接相关的第一任务节点；以及操作S240，根据第一任务节点和血缘关系，从多个任务流中确定造成异常事件的根源任务流。

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

如图7所示，描述了根据本发明的实施方式的用于异常检测的程序产品70，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在计算设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

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

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

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

示例性计算设备

在介绍了本发明示例性实施方式的方法、介质和装置之后，接下来，参考图对本发明示例性实施方式的计算设备进行说明。

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

在一些可能的实施方式中，根据本发明的计算设备可以至少包括至少一个处理单元、以及至少一个存储单元。其中，所述存储单元存储有程序代码，当所述程序代码被所述处理单元执行时，使得所述处理单元执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的异常检测的方法中的步骤。例如，所述处理单元可以执行如图2中所示的操作S210，获取针对应用程序的多个任务流；操作S220，确定血缘关系；操作S230，响应于检测到异常事件，确定与异常事件直接相关的第一任务节点；以及操作S240，根据第一任务节点和血缘关系，从多个任务流中确定造成异常事件的根源任务流。

下面参照图8来描述根据本发明的这种实施方式的计算设备80。如图8所示的计算设备80仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图8所示，计算设备80以通用计算设备的形式表现。计算设备80的组件可以包括但不限于：上述至少一个处理单元801、上述至少一个存储单元802、连接不同系统组件(包括存储单元802和处理单元801)的总线803。

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

存储单元802可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)8021和/或高速缓存存储器8022，还可以进一步包括只读存储器(ROM)8023。

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

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

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

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

虽然已经参考若干具体实施方式描述了本发明的精神和原理，但是应该理解，本发明并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本发明旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (10)

1.一种异常检测的方法，包括：

获取针对应用程序的多个任务流，所述多个任务流中的每一任务流包括多个任务节点；

确定血缘关系，所述血缘关系指示了所述多个任务流之间的依赖关系以及所述多个任务流中各任务节点之间的依赖关系；

响应于检测到异常事件，确定与所述异常事件直接相关的第一任务节点；以及

根据所述第一任务节点和所述血缘关系，从所述多个任务流中确定造成所述异常事件的根源任务流。

2.根据权利要求1所述方法，其中，所述确定血缘关系，包括：

执行所述应用程序；

通过监测所述多个任务流中各任务节点的执行进程，确定所述血缘关系。

3.根据权利要求1所述方法，其中，所述根据所述第一任务节点和所述血缘关系，从所述多个任务流中确定造成所述异常事件的根源任务流，包括以下步骤：

步骤1，根据所述血缘关系，确定所述第一任务节点所依赖的至少一个第二任务节点；

步骤2，针对所述至少一个第二任务节点中的每一个第二任务节点，检测所述每一个第二任务节点是否异常，若检测到存在异常的第二任务节点，则执行步骤3，若检测不到存在异常的第二任务节点，则执行步骤4；

步骤3，将所述存在异常的第二任务节点确定为新的第一任务节点，并跳转执行步骤1；以及

步骤4，将所述第一任务节点所属的任务流确定为所述根源任务流。

4.根据权利要求1至3任一项所述方法，还包括：

从所述多个任务流中确定待恢复任务流；

获取待恢复任务流的历史运行数据，所述历史运行数据包括每次执行所述待恢复任务流前的等待时长以及待恢复任务流每次执行时长；

根据所述历史运行数据，确定所述待恢复任务流的平均等待时长和平均执行时长；

基于所述待恢复任务流的平均等待时长和平均执行时长，确定异常恢复预估时刻；以及

输出所述异常恢复预估时刻。

5.根据权利要求4所述方法，其中，所述基于所述待恢复任务流的平均等待时长和平均执行时长，确定异常恢复预估时刻包括：

获取所述待恢复任务流所依赖的任务流的预估结束时刻；以及

根据以下公式计算所述异常恢复预估时刻：

所述异常恢复预估时刻＝所述待恢复任务流所依赖的任务流的预估结束时刻+所述待恢复任务流的平均等待时长+所述待恢复任务流的平均执行时长。

6.根据权利要求4所述方法，还包括：

判断所述异常恢复预估时刻是否大于时间阈值；以及

若所述异常恢复预估时刻大于所述时间阈值，则生成报警信息。

7.根据权利要求1所述方法，其中，所述异常事件包括以下事件中的一种或多种：

任务流的执行过程中出现错误；以及

任务流的运行结果不符合预定要求。

8.一种异常检测装置，包括：

任务流获取模块，用于获取针对应用程序的多个任务流，所述多个任务流中的每一任务流包括多个任务节点；

血缘关系确定模块，用于确定血缘关系，所述血缘关系指示了所述多个任务流之间的依赖关系以及所述多个任务流中各任务节点之间的依赖关系；

第一确定模块，用于响应于检测到异常事件，确定与所述异常事件直接相关的第一任务节点；以及

根源任务流确定模块，用于根据所述第一任务节点和所述血缘关系，从所述多个任务流中确定造成所述异常事件的根源任务流。

9.一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行权利要求1至7中任一项所述的方法。

10.一种计算设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行权利要求1至7中任一项所述的方法。