CN116737491A - 异常监控方法、装置、设备、介质及产品 - Google Patents

Abstract

本申请公开了一种异常监控方法、装置、设备、介质及产品。该异常方法包括：获取各个待测对象的运行状态以及规则引擎，规则引擎用于存储异常判定规则和各个待测对象之间的依赖关系；基于异常判定规则对各个待测对象的运行状态进行异常识别，得到第一异常对象；基于依赖关系，从第一异常对象所在服务调用链对应的N个待测对象中识别出异常源头，得到第二异常对象；向第二异常对象推送告警信息，并向依赖于第二异常对象的所有待测对象推送预警信息。根据本申请实施例，可以对异常源头进行及时排查，快速定位异常源头，提升异常监控效果。

Description

异常监控方法、装置、设备、介质及产品

技术领域

本申请属于监控技术领域，尤其涉及一种异常监控方法、装置、设备、介质及产品。

背景技术

目前，为了保证应用系统的业务服务质量，需要在其系统架构中设置监控系统以实现业务服务质量的监控，保证应用系统的安全稳定运行。

相关技术中，传统的应用系统的监控系统，对于网络应用各组件或系统的监控环节相互独立，当某个系统异常时，仅该系统的相关人员会收到告警信息，其它系统无法得知。因此，其它系统基于信息孤岛问题无法主动避免调用该系统，最终导致依赖该系统的其它系统的案例执行失败，此时其它系统的相关人员才发现异常并逐一排查判定异常原因，排查不及时，导致异常监控效果较差。

发明内容

本申请实施例提供一种异常监控方法、装置、设备、介质及产品，能够对异常源头进行及时排查，快速定位异常源头，提升异常监控效果。

第一方面，本申请实施例提供一种异常监控方法，该方法包括：

获取各个待测对象的运行状态以及规则引擎，其中，规则引擎用于存储异常判定规则和各个待测对象之间的依赖关系；

基于异常判定规则对各个待测对象的运行状态进行异常识别，得到各个待测对象中的第一异常对象；

基于各个待测对象之间的依赖关系，从第一异常对象所在服务调用链对应的N个待测对象中识别出异常源头，得到第二异常对象，N为正整数；

向第二异常对象推送告警信息，并向依赖于第二异常对象的所有待测对象推送预警信息；

其中，告警信息用于提示用户对第二异常对象的异常情况进行处理，预警信息用于提示第二异常对象为异常源头，且待测对象的运行状态会受到异常源头的影响。

第二方面，本申请实施例提供了一种异常监控装置，该装置包括：

获取模块，用于获取各个待测对象的运行状态以及规则引擎，其中，规则引擎用于存储异常判定规则和各个待测对象之间的依赖关系；

识别模块，用于基于异常判定规则对各个待测对象的运行状态进行异常识别，得到各个待测对象中的第一异常对象；

识别模块，还用于基于各个待测对象之间的依赖关系，从第一异常对象所在服务调用链对应的N个待测对象中识别出异常源头，得到第二异常对象，N为正整数；

预警模块，用于向第二异常对象推送告警信息，并向依赖于第二异常对象的所有待测对象推送预警信息；

其中，告警信息用于提示用户对第二异常对象的异常情况进行处理，预警信息用于提示第二异常对象为异常源头，且待测对象的运行状态会受到异常源头的影响。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括：处理器以及存储有计算机程序指令的存储器；

处理器执行所述计算机程序指令时实现如第一方面的任一项实施例中所述的异常监控方法的步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序指令，计算机程序指令被处理器执行时实现如第一方面的任一项实施例中所述的异常监控方法的步骤。

第五方面，本申请实施例提供了一种计算机程序产品，计算机程序产品中的指令由电子设备的处理器执行时，使得所述电子设备执行如第一方面的任一项实施例中所述的异常监控方法的步骤。

第六方面，本申请实施例提供一种芯片，该芯片包括处理器和通信接口，通信接口和处理器耦合，处理器用于运行程序或指令，实现如第一方面的任一项实施例中所述的异常监控方法的步骤。

本申请实施例中的异常监控方法、装置、设备、介质及产品，各个待测对象可以包括各系统及各组件，因此通过获取各个待测对象的运行状态，实现各系统及各组件运行情况的一体化监控。并且，各系统及各组件细化服务间的依赖关系可积累为可使用的规则，该规则即为各个待测对象之间依赖关系，因此在基于异常判定规则对各个待测对象的运行状态进行异常识别，得到异常的第一异常对象后，基于各个待测对象之间的依赖关系，能够从第一异常对象所在服务调用链对应的N个待测对象中识别出异常源头，找到致使第一异常对象出现异常的问题源头，实现异常源头的准确定位。基于此，向第二异常对象推送告警信息，并向依赖于第二异常对象的所有待测对象推送预警信息。如此，本申请可对异常源头进行及时排查，快速定位异常源头，并及时将预警信息推送至异常源头的影响范围内的待测对象，及时提醒将会受影响的待测对象主动避免调用异常源头，进而能够避免后续案例执行失败，保证业务顺利执行，提升异常监控效果。

附图说明

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

图1是本申请实施例提供的服务调用链的示例性示意图；

图2是本申请实施例提供的异常监控方法的应用场景的示例性示意图；

图3是本申请一实施例提供的异常监控方法的流程示意图；

图4是本申请另一实施例提供的异常监控方法的流程示意图；

图5是本申请再一实施例提供的异常监控方法的流程示意图；

图6是本申请再一实施例提供的异常监控方法的流程示意图；

图7是本申请一实施例提供的异常监控装置的结构示意图；

图8是本申请一实施例提供的电子设备的结构示意图。

具体实施方式

下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅意在解释本申请，而不是限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

目前，为了保证应用系统的业务服务质量，需要在其系统架构中设置监控系统以实现业务服务质量的监控，保证应用系统的安全稳定运行。

相关技术中，传统的应用系统的监控系统，对于网络应用各组件或系统的监控环节相互独立，当某个系统异常时，仅该系统的相关人员会收到告警信息，其它系统无法得知。因此，其它系统基于信息孤岛问题无法主动避免调用该系统，最终导致依赖该系统的其它系统的案例执行失败，此时其它系统的相关人员才发现异常并逐一排查判定异常原因，排查不及时，导致异常监控效果较差。

具体地，应用系统的监控一般相互独立，分为多层次，例如资源层可用性监控模块：关注机器输入/输出IO、中央处理器(Central Processing Unit，CPU)、内存等资源情况；服务层可用性监控模块：关注系统或模块的启停状态，可通过定时发送请求来探测基础服务或进程是否存在，或系统模块通过定时上报心跳方式来周知自身状态；服务层正确性监控模块：关注系统业务处理正确性；开源组件一般同时开放独立配套监控工具，监控资源层及服务可用性情况，可配置报警通知功能，一般对外开放接口。

由此可见，不同监控模块用于监控不同层级的系统或组件的运行状态，但不同监控模块之间相互独立，互为孤岛，忽略了系统及组件间可用性的依赖关系，缺少一体化多层级的监控框架。但实际上，各业务系统相互关联，很大一部分情况，某项服务异常是由于其依赖的服务或组件异常。例如，交易系统完成交易后查询不到开源组件大数据平台CDH集群数据，可能是CDH集群的HBASE组件在某段时间内出现异常导致数据未写入，即HBASE组件的异常导致了关联系统，即交易系统的异常，但CDH监控平台并不会自动通知到关联系统人员，因此需关联系统人员发现异常并经过排查后方能定位异常源头。

示例性地，如图1所示，在某条服务调用链中，联机系统产生的交易数据会在交易流转后，通过多个系统(例如转接系统、全渠道系统)被数据分发到大数据写入服务，再由大数据写入服务将数据写入CDH集群的HBASE组件中，以供后续联机系统向大数据查询服务发起查询请求并调用大数据查询服务时查询使用，在该查询过程中联机系统会同步收到应答，但写入过程为异步。

举例来讲，当图1的HBASE组件出现异常时，联机系统可正常交易流转，最终在写入环节失败，此时大数据写入服务会产生报错，但联机系统无感知。联机系统后续正常发起查询请求，但由于数据未成功写入，大数据查询服务无法查询到对应数据，导致交易查询失败，联机系统人员此时介入排查，排查范围是包括自身在内的数据写入流向上的多个系统，需要逐个确认以框定数据丢失环节。由此可见，现有监控体系中各系统或组件相互独立，某个环节异常往往也会影响上下游系统使用，但仅该环节的相关人员会收到告警，其它系统基于信息孤岛问题，仅能在案例执行失败后才发现异常，并开始逐一排查判定异常原因，导致排查行为滞后。并且，相关技术中未将各系统及组件间的依赖关系积累为可用规则，因此对于上述HBASE组件出现异常的情况，即使数据写入环节和数据查询环节的案例失败原因并非联机系统、数据查询服务和数据写入服务，也要对联机系统、数据查询服务和数据写入服务进行排查，此类非必要的排查过程，导致消耗不必要的排查时间，降低排查效率，若在测试环境中则浪费了上游构造数据的精力。

为了解决现有技术问题，本申请实施例提供了一种异常监控方法、装置、设备、介质及产品，能够对异常源头进行及时排查，快速定位异常源头，提升异常监控效果。该异常监控方法可以应用于对系统和组件进行多层次一体化监控的场景。

示例性地，图2是本申请实施例提供的异常监控方法的应用场景的示例性示意图，如图2所示，该应用场景可以为对外提供的联调测试环境，该联调测试环境可以涉及多个待测对象，多个待测对象可以包括各个系统及组件，具体可以包括图2所示的服务A、服务B、服务C等系统，以及关系型数据库管理系统MYSQL、关系型数据库平台DB2、CDH等组件。

下面首先对本申请实施例所提供的异常监控方法进行介绍。

图3是本申请一实施例提供的异常监控方法的流程示意图。如图3所示，该异常监控方法具体可以包括如下步骤：

步骤310，获取各个待测对象的运行状态以及规则引擎，其中，规则引擎用于存储异常判定规则和各个待测对象之间的依赖关系；

步骤320，基于异常判定规则对各个待测对象的运行状态进行异常识别，得到各个待测对象中的第一异常对象；

步骤330，基于各个待测对象之间的依赖关系，从第一异常对象所在服务调用链对应的N个待测对象中识别出异常源头，得到第二异常对象，N为正整数；

步骤340，向第二异常对象推送告警信息，并向依赖于第二异常对象的所有待测对象推送预警信息；

其中，告警信息用于提示用户对第二异常对象的异常情况进行处理，预警信息用于提示第二异常对象为异常源头，且待测对象的运行状态会受到异常源头的影响。

由此，在基于异常判定规则对各个待测对象的运行状态进行异常识别，得到异常的第一异常对象后，基于各个待测对象之间的依赖关系，能够从第一异常对象所在服务调用链对应的N个待测对象中识别出异常源头，找到致使第一异常对象出现异常的问题源头，实现异常源头的准确定位。基于此，向第二异常对象推送告警信息，并向依赖于第二异常对象的所有待测对象推送预警信息。如此，本申请可对异常源头进行及时排查，快速定位异常源头，并及时将预警信息推送至异常源头的影响范围内的待测对象，及时提醒将会受影响的待测对象主动避免调用异常源头，进而能够避免后续案例执行失败，保证业务顺利执行，提升异常监控效果。

下面介绍上述各个步骤的具体实现方式。

涉及步骤310，获取各个待测对象的运行状态以及规则引擎。

在步骤310中，各个待测对象可以包括多个系统以及多个组件，该系统可以是业务系统或者应用系统，例如为联机系统、大数据写入系统、大数据查询系统、转接系统、全渠道系统等，组件可以是基础组件，例如为数据库、中间件、开源组件等。

在一些实施方式中，可以通过将各个待测对象接入监控模块，获取各个待测对象的运行状态，其中，接入监控模块的待测对象可以根据实际需求进行灵活配置和扩展，例如上游的待测对象P1也可以有更上游的待测对象，每个待测对象都可以有上游待测对象和/或下游待测对象，本申请的多层级一体化监控架构可支持无限扩张。

在一些实施方式中，可以基于预设周期获取各个待测对象的运行状态，该预设周期可以根据具体需求进行设置，本申请对此不做具体限定。

相关技术中，基于服务调用链上的部分待测对象涉及改动联调，其它待测对象一旦在保证联通性后，一般无人力全程支持。从这些待测对象的负责人员角度，当这些待测对象出现异常时，虽然能够得知当前异常情况，但是无法得知目前涉及使用的人员范围，当这些待测对象进行各自的异常测试或版本安装时，也是如此。而从外部调用方角度，外部调用方并不关注服务调用链上某一待测对象的运行状态，而是关注整个服务调用链包括链上各种系统及组件的健康，因此需要的是一体化多层级的监控展示页面。

在一些实施方式中，基于待测对象涉及各系统及组件，且不同系统、不同组件之间的运行状态涉及不同层级，步骤310可以具体包括：通过多层级监控，获取各个待测对象的不同层级的运行状态。

具体地，多层级监控可以包括但不限于：资源层可用性监控，用于探测机器资源使用情况，例如CPU使用率；服务层可用性监控，用于提供基础监控，探测服务进程是否存在；服务层正确性监控，可针对服务系统，用于通过执行冒烟测试案例探测服务状态；组件监控，可针对开源组件，用于通过解析所提供的开放接口，获取组件的运行状态。

如此，本申请可构建出一套串联各系统及组件的多层次一体化监控框架，多层次同时收集各系统及组件的运行状态，实现一体化监控展示，解决相关技术中各系统及组件的监控相互独立，互为孤岛的问题。

在一些实施方式中，对于多层级监控中不同层级的监控，可以基于不同时间周期获取待测对象的运行状态。例如资源层可用性监控对应的时间周期可以为每隔60s获取一次，组件监控对应的时间周期可以为每隔3min获取一次。

在一些实施方式中，规则引擎中的异常判定规则可以是预先配置的，若待测对象的运行状态满足对应的异常判定规则，则确定待测对象的识别结果为异常。

示例性地，异常判定规则可以为CPU使用率超过95％、服务进程不存在、组件状态不可用、冒烟测试执行失败等。

在一些实施方式中，各个待测对象构成多条服务调用链，各个待测对象之间的依赖关系为各个待测对象在多条服务调用链上的依赖关系。

具体地，该依赖关系可以反映待测对象之间的异常影响关系，各个待测对象之间的依赖关系可以是预先配置的，也可以是基于待测对象相关的服务调用链上的服务调用顺序确定的。

在一个示例中，以图2所示的应用场景为例，若服务A的服务调用链上的服务调用顺序为CDH组件→服务A→服务B→服务C，则可确定服务A的运行状态依赖于CDH组件，若CDH组件异常，则服务A在使用CDH组件时也会异常；服务B和服务C的运行状态依赖于服务A和CDH组件，因此服务A同时是服务B和服务C的依赖对象，若服务A异常，服务B和服务C也会异常。

在另一个示例中，大数据查询某交易的案例依赖大数据写入案例的成功，而大数据写入案例的成功又依赖联机系统流转交易成功且HBASE组件健康。基于此，利用该服务调用顺序，可以形成大数据查询系统依赖于大数据写入系统、联机系统、HBASE组件，大数据写入系统依赖于联机系统和HBASE组件的依赖关系，也即，不同层级的待测对象形成了依赖关系。

在本申请实施例中，服务调用链能够反映链上待测对象的服务调用顺序以及调用关系，因此通过整理各个待测对象在其对应服务调用链上的依赖关系，可以得到各个待测对象之间的依赖关系，为后续在服务调用链上寻找异常源头提供可靠依据。

在一些实施方式中，依赖关系可以以树形结构表示。

涉及步骤320，基于异常判定规则对各个待测对象的运行状态进行异常识别，得到各个待测对象中的第一异常对象。

在步骤320中，第一异常对象的数量可以为至少一个，本申请可以通过判断待测对象的运行状态是否满足异常判定规则，得到待测对象的识别结果，若满足，则其识别结果为异常，若不满足，则其识别结果为正常。

在一些实施方式中，第一异常对象为识别结果为异常的待测对象，步骤320可以具体包括下述步骤：

基于异常判定规则，对各个待测对象的运行状态进行异常识别，得到各个待测对象的识别结果；

确定识别结果为异常的待测对象为第一异常对象。

具体地，在待测对象满足异常判定规则的情况下，确定待测对象的识别结果为异常；在待测对象不满足异常判定规则的情况下，确定待测对象的识别结果为正常。

在本申请实施例中，所有识别结果为异常的待测对象均为第一异常对象，因此针对每个第一异常对象，均可以在其服务调用链上进行异常源头的识别，得到每个第一异常对象的异常源头，后续可以再对相同的异常源头进行去重处理，避免排查遗漏。

在一些实施方式中，在得到各个待测对象的识别结果之后，方法还包括：

基于识别结果为正常或者异常，将各个待测对象的运行状态及其识别结果进行分类展示。

在本申请实施例中，对于涉及不同层级的待测对象，可以集中展示其运行状态及其识别结果，且可将识别结果正常和异常的待测对象分类展示，方便相关人员查看，实现一站式多层级系统及组件监控，解决信息孤岛问题。并且，在使用全流程联调环境时，也可一站式查看细化服务可用性，提升服务状态查看效果。

在另一些实施方式中，为了简化排查步骤，节省排查时间，图4是本申请另一实施例提供的异常监控方法的流程示意图，上述步骤320可以具体包括图4所示的步骤410和步骤420。

步骤410，基于异常判定规则，分别对每个待测对象的运行状态进行异常识别，得到每个待测对象的识别结果；

步骤420，确定每条服务调用链上，最先得到识别结果为异常的待测对象为第一异常对象。

在这里，第一异常对象可以为每条服务调用链上最先得到异常的识别结果的待测对象。

示例性地，对于服务调用链CDH组件→服务A→服务B→服务C，若最先识别到服务A的识别结果为异常，则可以确定该服务A为第一异常对象，并在该服务调用链上查找异常源头，在同一周期内，若后续识别到CDH组件或者服务B的识别结果为异常，则不再在该服务调用链上查找异常源头。

在本申请实施例中，待测对象的运行状态可以为先后获取或者被先后识别，对于同一条服务调用链，仅第一个得到识别结果为异常的待测对象为第一异常对象。基于此，在该服务调用链上定位异常源头后，若后续再从该服务调用链上得到识别结果为异常的待测对象，则无需在该服务调用链上再次执行异常源头的定位排查，简化排查步骤，避免非必要排查步骤所带来的耗时，节省排查时间。

涉及步骤330，基于各个待测对象之间的依赖关系，从第一异常对象所在服务调用链对应的N个待测对象中识别出异常源头，得到第二异常对象。

在步骤330中，N个待测对象为服务调用链上的所有待测对象，N个待测对象中可以包括第一异常对象；第一异常对象所在服务调用链可以为至少一条，针对每条服务调用链，均可以对链上的N个待测对象进行识别，得到每条服务调用链上的异常源头。

需要说明的是，对于同一第一异常对象所在的不同服务调用链，识别到的异常源头可以相同，也可以不同，本申请不对此进行限定。

在一些实施方式中，步骤330可以具体包括：基于各个待测对象之间的依赖关系中，N个待测对象在服务调用链上的依赖关系，从N个待测对象中识别出异常源头。

具体地，可以从各个待测对象之间的依赖关系中，提取出N个待测对象在服务调用链上的依赖关系，从而利用更具体化的N个待测对象之间的依赖关系，从N个待测对象中识别出异常源头。

在一些实施方式中，为了对异常源头进行精准识别，图5是本申请再一实施例提供的异常监控方法的流程示意图，上述步骤330可以具体包括图5所示的步骤510和步骤520。

步骤510，基于N个待测对象在服务调用链上的依赖关系，确定N个待测对象中的M1个第一待测对象和M2个第二待测对象；

步骤520，从M1个第一待测对象中识别出异常源头；

其中，第一待测对象为第一异常对象依赖的待测对象，第二待测对象为依赖于第一异常对象的待测对象，N＝M1+M2+1。

在这里，服务调用链上的N个待测对象中，除了第一异常对象自身，其余待测对象均可根据与第一异常对象的依赖关系，分为第一异常对象所依赖的第一待测对象，以及依赖于第一异常对象的第二待测对象。第一异常对象的运行状态受到第一待测对象的运行状态影响，若第一待测对象为异常，则第一异常对象也会异常；第二待测对象的运行状态受到第一异常对象的运行状态影响，若第一异常对象为异常，则第二待测对象也会异常。

示例性地，对于服务调用链CDH组件→服务A→服务B→服务C，若服务A为第一异常对象，则第一待测对象可以包括CDH组件，第二待测对象可以包括服务B和服务C。

在本申请实施例中，由于系统或者组件的异常，追溯源头，均源于该系统或者组件所依赖的待测对象，因此本申请在识别第一异常对象后，首先从其所在服务调用链上，获取第一异常对象所依赖的第一待测对象，从而能够从第一异常对象所依赖的第一待测对象中，精准识别出异常源头，缩小异常源头的排查范围，提升排查速度和效率。

在一些实施方式中，图6是本申请再一实施例提供的异常监控方法的流程示意图，上述步骤520可以具体包括图6所示的步骤610-步骤630：

步骤610，基于M1个第一待测对象在服务调用链中的位置，确定每个第一待测对象与第一异常对象之间的服务调用距离；

步骤620，按照服务调用距离由近到远的顺序，逐个获取对第一待测对象的运行状态进行异常识别后得到的识别结果，直至得到识别结果为正常的目标待测对象；

步骤630，确定所有在服务调用链上依赖目标待测对象的第一待测对象中，与目标待测对象的服务调用距离最近的第一待测对象为异常源头，得到第二异常对象。

示例性地，对于服务调用链CDH组件→服务A→服务B→服务C，若服务C为第一异常对象，则第一待测对象可以包括CDH组件、服务A和服务B，与第一异常对象之间的服务调用距离分别为3、2、1，则可以按照服务B、服务A、CDH组件的顺序逐一进行排查，若服务B和服务A的识别结果均为异常，CDH组件的识别结果为正常，则可以确定与目标待测对象CDH组件的服务调用距离最近，且识别结果为异常的服务A为异常源头。

在本申请实施例中，在获取到第一异常对象所依赖的所有第一待测对象后，可以按照服务调用链中与第一异常对象之间的服务调用距离，自近向远逐一排查，直至探测出识别结果为正常的目标待测对象，确认目标待测对象的上一个排查对象为异常源头。如此，可以尽可能地减少所排查的待测对象的数量，提升排查效率，因此能够快速确认异常源头。

在一些实施方式中，在步骤510之后，该方法还可以包括下述步骤：

在M1为零的情况下，确定第一异常对象为服务调用链上的底层系统或者底层组件；

确定底层系统或者底层组件为异常源头。

在这里，在M1为零的情况下，说明第一异常对象不存在所依赖的第一待测对象，该服务调用链上除自身以外的待测对象全部为第二待测对象，也即，该服务调用链上除自身以外的待测对象全部依赖于第一异常对象，第一异常对象为位于服务调用链最下游的底层系统或者底层组件。基于底层系统或底层组件不依赖于任何对象，可直接确认其为异常源头。

在本申请实施例中，当确定第一异常对象为底层系统或者底层组件时，可以直接确认该第一异常对象即为异常源头，排查简单快速，也避免了一些冗余排查步骤。

在一些实施方式中，可以通过调用规则引擎，执行步骤320和步骤330，该规则引擎中所存储的依赖关系可以由用户在前端页面录入。

涉及步骤340，向第二异常对象推送告警信息，并向依赖于第二异常对象的所有待测对象推送预警信息。

继续参见上述示例，对于服务调用链CDH组件→服务A→服务B→服务C，若服务A为第二异常对象，则可以向服务A推送告警信息，向服务B和服务C推送预警信息，使服务B和服务C能够暂时主动避免调用服务A。

在步骤340中，产生的告警信息相当于日志中的ERROR级别，预警信息相当于WARN级别，两者分别通知给直接异常对象和被影响对象。

在本申请实施例中，依赖于第二异常对象的所有待测对象即为第二异常对象在第一服务调用链中的影响范围，因此本申请可以在第一异常对象的基础上，下推确认异常源头，上推确认异常源头引发的连锁影响面，周知被影响方异常情况及当前问题处理方，提醒影响范围内的待测对象将会受到异常影响，提示其主动避用异常源头，待恢复后继续调用，提前发现问题的同时，避免了人为信息沟通同步及逐层排查过程。

在一些实施方式中，在向第二异常对象推送告警信息之后，方法还包括：

间隔预设时长后获取第二异常对象的运行状态；

基于异常判定规则对第二异常对象的运行状态进行异常识别；

在第二异常对象的识别结果为正常的情况下，向依赖于第二异常对象的所有待测对象推送预警解除信息。

其中，预设时长可以根据具体需求进行设置，该预设时长例如可以为5min、10min等，本申请对此不做具体限定。

在本申请实施例中，在异常源头的问题被处理后，可以及时获取到第二异常对象的最新运行状态，如监测到异常解除，则可以再次向之前发送过预警信息的待测对象推送预警解除信息，通知相同人员预警解除，可正常调用第二异常对象，保证业务可继续顺利执行。

在一些实施方式中，各个待测对象是否接收告警信息和/或预警信息可按照实际需求进行配置。

需要说明的是，上述本申请实施例描述的应用场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着新应用场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

基于相同的发明构思，本申请还提供了一种异常监控装置。具体结合图7进行详细说明。

图7是本申请一个实施例提供的异常监控装置的结构示意图。

如图7所示，该异常监控装置700可以包括：

获取模块710，用于获取各个待测对象的运行状态以及规则引擎，其中，规则引擎用于存储异常判定规则和各个待测对象之间的依赖关系；

识别模块720，用于基于异常判定规则对各个待测对象的运行状态进行异常识别，得到各个待测对象中的第一异常对象；

识别模块720，还用于基于各个待测对象之间的依赖关系，从第一异常对象所在服务调用链对应的N个待测对象中识别出异常源头，得到第二异常对象，N为正整数；

预警模块730，用于向第二异常对象推送告警信息，并向依赖于第二异常对象的所有待测对象推送预警信息；

其中，告警信息用于提示用户对第二异常对象的异常情况进行处理，预警信息用于提示第二异常对象为异常源头，且待测对象的运行状态会受到异常源头的影响。

由此，在基于异常判定规则对各个待测对象的运行状态进行异常识别，得到异常的第一异常对象后，基于各个待测对象之间的依赖关系，能够从第一异常对象所在服务调用链对应的N个待测对象中识别出异常源头，找到致使第一异常对象出现异常的问题源头，实现异常源头的准确定位。基于此，向第二异常对象推送告警信息，并向依赖于第二异常对象的所有待测对象推送预警信息。如此，本申请可对异常源头进行及时排查，快速定位异常源头，并及时将预警信息推送至异常源头的影响范围内的待测对象，及时提醒将会受影响的待测对象主动避免调用异常源头，进而能够避免后续案例执行失败，保证业务顺利执行，提升异常监控效果。

在本申请的一些实施方式中，识别模块包括：

确定单元，用于基于N个待测对象在服务调用链上的依赖关系，确定N个待测对象中的M1个第一待测对象和M2个第二待测对象；

识别单元，用于从M1个第一待测对象中识别出异常源头；

其中，第一待测对象为第一异常对象依赖的待测对象，第二待测对象为依赖于第一异常对象的待测对象。

在本申请的一些实施方式中，识别单元具体用于：

基于M1个第一待测对象在服务调用链中的位置，确定每个第一待测对象与第一异常对象之间的服务调用距离；

按照服务调用距离由近到远的顺序，逐个获取对第一待测对象的运行状态进行异常识别后得到的识别结果，直至得到识别结果为正常的目标待测对象；

确定所有在服务调用链上依赖目标待测对象的第一待测对象中，与目标待测对象的服务调用距离最近的第一待测对象为异常源头，得到第二异常对象。

在本申请的一些实施方式中，装置还包括：

确定模块，用于在M1为零的情况下，确定第一异常对象为服务调用链上的底层系统或者底层组件；

确定模块，还用于确定底层系统或者底层组件为异常源头。

在本申请的一些实施方式中，识别模块包括：

识别单元，用于基于异常判定规则，对各个待测对象的运行状态进行异常识别，得到各个待测对象的识别结果；

确定单元，用于确定识别结果为异常的待测对象为第一异常对象。

在本申请的一些实施方式中，装置还包括：

展示模块，用于在得到各个待测对象的识别结果之后，基于识别结果为正常或者异常，将各个待测对象的运行状态及其识别结果进行分类展示。

在本申请的一些实施方式中，各个待测对象构成多条服务调用链，各个待测对象之间的依赖关系为各个待测对象在多条服务调用链上的依赖关系。

在本申请的一些实施方式中，识别模块包括：

识别单元，用于基于异常判定规则，分别对每个待测对象的运行状态进行异常识别，得到每个待测对象的识别结果；

确定单元，用于确定每条服务调用链上，最先得到识别结果为异常的待测对象为第一异常对象。

在本申请的一些实施方式中，装置还包括：

获取模块，用于在向第二异常对象推送告警信息之后，间隔预设时长后获取第二异常对象的运行状态；

识别模块，还用于基于异常判定规则对第二异常对象的运行状态进行异常识别；

预警模块，还用于在第二异常对象的识别结果为正常的情况下，向依赖于第二异常对象的所有待测对象推送预警解除信息。

图8是本申请一个实施例提供的电子设备的结构示意图。

在电子设备800可以包括处理器801以及存储有计算机程序指令的存储器802。

具体地，上述处理器801可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器802可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器802可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器802可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器802可在综合网关容灾设备的内部或外部。在特定实施例中，存储器802是非易失性固态存储器。

在特定实施例中，存储器可包括只读存储器(ROM)，随机存取存储器(RAM)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本申请的一方面的方法所描述的操作。

处理器801通过读取并执行存储器802中存储的计算机程序指令，以实现上述实施例中的任意一种异常监控方法。

在一些示例中，电子设备800还可包括通信接口803和总线810。其中，如图8所示，处理器801、存储器802、通信接口803通过总线810连接并完成相互间的通信。

通信接口803主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。

总线810包括硬件、软件或两者，将在线数据流量计费设备的部件彼此耦接在一起。举例来说而非限制，总线810可包括加速图形端口(AGP)或其他图形总线、增强工业标准架构(EISA)总线、前端总线(FSB)、超传输(HT)互连、工业标准架构(ISA)总线、无限带宽互连、低引脚数(LPC)总线、存储器总线、微信道架构(MCA)总线、外围组件互连(PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线810可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

示例性的，电子设备800可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本或者个人数字助理(personal digital assistant，PDA)等。

该电子设备800可以执行本申请实施例中的异常监控方法，从而实现结合图1至图7描述的异常监控方法和装置。

另外，结合上述实施例中的异常监控方法，本申请实施例可提供一种计算机可读存储介质来实现。该计算机可读存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种异常监控方法。计算机可读存储介质的示例包括非暂态计算机可读存储介质，如便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件等。

本申请实施例可提供一种计算机程序产品来实现，该计算机程序产品中的指令由电子设备的处理器执行时，使得所述电子设备执行如第一方面的任一项实施例中所述的异常监控方法的步骤，异常监控方法的具体内容可参见上述实施例中的相关说明，在此不再赘述。

本申请实施例可提供一种芯片，芯片包括处理器和通信接口，通信接口和处理器耦合，处理器用于运行程序或指令，实现如第一方面所示的异常监控方法的实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

应理解，本申请实施例提到的芯片还可以称为系统级芯片、系统芯片、芯片系统或片上系统芯片等。

需要明确的是，本申请并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本申请的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本申请的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。

以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本申请的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本申请中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本申请不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

上面参考根据本申请的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本申请的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。

以上所述，仅为本申请的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。

Claims (13)

1.一种异常监控方法，其特征在于，包括：

获取各个待测对象的运行状态以及规则引擎，其中，所述规则引擎用于存储异常判定规则和所述各个待测对象之间的依赖关系；

基于所述异常判定规则对所述各个待测对象的运行状态进行异常识别，得到所述各个待测对象中的第一异常对象；

基于所述各个待测对象之间的依赖关系，从所述第一异常对象所在服务调用链对应的N个待测对象中识别出异常源头，得到第二异常对象，N为正整数；

向所述第二异常对象推送告警信息，并向依赖于所述第二异常对象的所有待测对象推送预警信息；

其中，所述告警信息用于提示用户对所述第二异常对象的异常情况进行处理，所述预警信息用于提示所述第二异常对象为异常源头，且所述待测对象的运行状态会受到所述异常源头的影响。

2.根据权利要求1所述的方法，其特征在于，所述基于所述各个待测对象之间的依赖关系，从所述第一异常对象所在服务调用链对应的N个待测对象中识别出异常源头，包括：

基于所述N个待测对象在所述服务调用链上的依赖关系，确定所述N个待测对象中的M1个第一待测对象和M2个第二待测对象；

从所述M1个第一待测对象中识别出异常源头；

其中，所述第一待测对象为所述第一异常对象依赖的待测对象，所述第二待测对象为依赖于所述第一异常对象的待测对象。

3.根据权利要求2所述的方法，其特征在于，所述从所述M1个第一待测对象中识别出异常源头，包括：

基于所述M1个第一待测对象在所述服务调用链中的位置，确定每个第一待测对象与所述第一异常对象之间的服务调用距离；

按照所述服务调用距离由近到远的顺序，逐个获取对所述第一待测对象的运行状态进行异常识别后得到的识别结果，直至得到识别结果为正常的目标待测对象；

确定所有在所述服务调用链上依赖所述目标待测对象的第一待测对象中，与所述目标待测对象的服务调用距离最近的第一待测对象为所述异常源头，得到所述第二异常对象。

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

在M1为零的情况下，确定所述第一异常对象为所述服务调用链上的底层系统或者底层组件；

确定所述底层系统或者底层组件为所述异常源头。

5.根据权利要求1所述的方法，其特征在于，所述基于所述异常判定规则对所述各个待测对象的运行状态进行异常识别，得到所述各个待测对象中的第一异常对象，包括：

基于所述异常判定规则，对所述各个待测对象的运行状态进行异常识别，得到各个待测对象的识别结果；

确定所述识别结果为异常的待测对象为所述第一异常对象。

6.根据权利要求5所述的方法，其特征在于，在所述得到各个待测对象的识别结果之后，所述方法还包括：

基于所述识别结果为正常或者异常，将所述各个待测对象的运行状态及其识别结果进行分类展示。

7.根据权利要求1所述的方法，其特征在于，所述各个待测对象构成多条服务调用链，所述各个待测对象之间的依赖关系为所述各个待测对象在所述多条服务调用链上的依赖关系。

8.根据权利要求7所述的方法，其特征在于，所述基于所述异常判定规则对所述各个待测对象的运行状态进行异常识别，得到所述各个待测对象中的第一异常对象，包括：

基于所述异常判定规则，分别对每个待测对象的运行状态进行异常识别，得到每个待测对象的识别结果；

确定每条所述服务调用链上，最先得到识别结果为异常的待测对象为所述第一异常对象。

9.根据权利要求1所述的方法，其特征在于，在所述向所述第二异常对象推送告警信息之后，所述方法还包括：

间隔预设时长后获取所述第二异常对象的运行状态；

基于所述异常判定规则对所述第二异常对象的运行状态进行异常识别；

在所述第二异常对象的识别结果为正常的情况下，向所述依赖于所述第二异常对象的所有待测对象推送预警解除信息。

10.一种异常监控装置，其特征在于，包括：

获取模块，用于获取各个待测对象的运行状态以及规则引擎，其中，所述规则引擎用于存储异常判定规则和所述各个待测对象之间的依赖关系；

识别模块，用于基于所述异常判定规则对所述各个待测对象的运行状态进行异常识别，得到所述各个待测对象中的第一异常对象；

所述识别模块，还用于基于所述各个待测对象之间的依赖关系，从所述第一异常对象所在服务调用链对应的N个待测对象中识别出异常源头，得到第二异常对象，N为正整数；

预警模块，用于向所述第二异常对象推送告警信息，并向依赖于所述第二异常对象的所有待测对象推送预警信息；

其中，所述告警信息用于提示用户对所述第二异常对象的异常情况进行处理，所述预警信息用于提示所述第二异常对象为异常源头，且所述待测对象的运行状态会受到所述异常源头的影响。

11.一种电子设备，其特征在于，所述设备包括：处理器以及存储有计算机程序指令的存储器；

所述处理器执行所述计算机程序指令时实现如权利要求1-9任意一项所述的异常监控方法的步骤。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现如权利要求1-9任意一项所述的异常监控方法的步骤。

13.一种计算机程序产品，其特征在于，所述计算机程序产品中的指令由电子设备的处理器执行时，使得所述电子设备执行如权利要求1-9任意一项所述的异常监控方法的步骤。