CN112084055A - 应用系统的故障定位方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明实施例公开了一种应用系统的故障定位方法、装置、计算机设备及存储介质。该方法用于通过多个监控项分别监控应用系统中的多个监控对象的运行状态，该方法包括：当任一个监控项的监控结果为异常状态时，将处于异常状态的监控项作为第一监控项；获取与第一监控项存在预设关联关系的至少一个关联监控项；获取关联监控项的监控结果，关联监控项的监控结果包括正常状态以及异常状态；以及根据监控结果确定应用系统的故障源，并输出包括故障源的信息。通过本发明的实施，能够更加精确地对应用系统中的故障源进行定位，有效减少运维工程师排查故障时间。

Description

应用系统的故障定位方法、装置、电子设备及存储介质

技术领域

本发明涉及运维技术领域，尤其涉及一种应用系统的故障定位方法、装置、计算机设备及存储介质。

背景技术

近些年来，随着计算机技术的不断进度，计算机应用水平的不断提高，同时为应对客户越来越多的需求，通常需要在服务器建立复杂庞大的软件系统，也正因为此，在对软件系统进行运营和维护过程中，运维工程师对出现的故障进行排查变得愈加困难。目前，为降低运维工程师的排查难度，通常会对服务器的CPU(中央处理器，central processingunit)使用率、内存使用率、磁盘空间、网络流量等进行长期监控，为各个监控项设置阈值，当超过阈值时便会发出告警信息，提示运维工程师进行处理。

虽然上述现有的故障排查方案能够在一定程度上为运维工程师提供定位作用，但是由于向运维工程师提供的信息覆盖面较大，仍然需要运维工程师再深度排查，故障排查过程需要花费较多的时间和精力。

发明内容

本鉴于上述问题，本发明实施例提供一种应用系统的故障定位方法、装置、计算机设备及存储介质，以解决上述问题。

第一方面，本发明实施例提供一种应用系统的故障定位方法，该方法用于通过多个监控项分别监控应用系统中的多个监控对象的运行状态，该方法包括：当任一个监控项的监控结果为异常状态时，将处于异常状态的监控项作为第一监控项；获取与第一监控项存在预设关联关系的至少一个关联监控项；获取关联监控项的监控结果，关联监控项的监控结果包括正常状态以及异常状态；以及根据监控结果确定应用系统的故障源，并输出包括故障源的信息。

第二方面，本发明实施例提供一种应用系统的故障定位装置，该装置用于通过多个监控项分别监控应用系统中的多个监控对象的运行状态，该装置包括：第一监控项获取模块、关联监控项获取模块、监控结果获取模块以及故障源确定模块。第一监控项获取模块用于当任一个监控项的监控结果为异常状态时，将处于异常状态的监控项作为第一监控项。关联监控项获取模块用于获取与第一监控项存在预设关联关系的至少一个关联监控项。监控结果获取模块用于获取关联监控项的监控结果，关联监控项的监控结果包括正常状态以及异常状态。故障源确定模块用于根据监控结果确定应用系统的故障源，并输出包括故障源的信息。

第三方面，本发明实施例提供一种控制单元，包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述的应用系统的故障定位方法的步骤。

第四方面，本发明实施例提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时实现上述的应用系统的故障定位方法的步骤。

本发明提供一种应用系统的故障定位方法、装置、计算机设备及存储介质，该应用系统的故障定位方法用于通过多个监控项分别监控应用系统中的多个监控对象的运行状态，该应用系统的故障定位方法能够通过监控项分别监控应用系统中的各个监控对象，当某一监控项的监控结果为异常状态时，将该监控项作为第一监控项，并进一步获取与第一监控项存在预设关联关系的关联监控项，并根据关联监控项的监控结果得到应用系统中的故障源，并输出包括故障源的信息，从而实现将应用系统中的各个监控对象相互关联，将各个监控项相关联，使得在其中一个监控对象发生异常时，能够进而获得与监控对象存在关联的监控对象的状态，大大提高了故障源定位的精准度，可以协助运维工程师在复杂的监控项中快速定位出生产环境故障的故障源，为快速恢复生产服务和保证业务的可用性方面起到了极大的促进作用。

附图说明

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

图1示出了一种适用于本发明实施例的应用环境示意图。

图2示出了根据本发明一个实施例的应用系统的故障定位方法的流程示意图。

图3示出了图2所示的方法中获取关联监控项的步骤的流程示意图。

图4示出了图1所示的方法中确定故障源的步骤的流程示意图。

图5示出了根据本发明一个实施例的应用系统的故障定位方法中为监控项配置权重值的步骤的流程示意图。

图6示出了根据本发明一个实施例的应用系统的故障定位方法中为获得监控结果的步骤的流程示意图。

图7示出了图6所示的方法中确定与监控类型为静态类型的监控对象对应的监控项的监控结果的步骤的流程示意图。

图8示出了图6所示的方法中确定与监控类型为动态类型的监控对象对应的监控项的监控结果的步骤的流程示意图。

图9示出了本发明实施例提出的一种应用系统的故障定位装置的功能模块框图。

图10示出了本发明实施例提出的一种电子设备的功能模块框图。

具体实施方式

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

为了清楚阐释本发明的方案，下面先对一些术语进行解释。

应用系统：软件和硬件配合形成的系统；

监控对象：应用系统中实现各功能的硬件单元或/及软件单元；

监控项：用于监控监控对象的状态的监控单元；

监控工具：对应用系统中的各个监控对象进行监控的工具；

运维：对应用系统的生命周期各个阶段的运营与维护；

故障定位：排查应用系统中存在故障的单元；

故障源：应用系统中发生故障的源头，如发生故障的监控对象。

目前，为满足业务需求，通常需要开发新的应用系统，或者对原有的应用系统中各种生产环境的版本变更、业务变化、代码逻辑或网络波动等更新时，很可能会产生各种各样的异常情况。尤其是生产环境系统较为庞大、复杂时，应用程序有几十上百个，服务器规模甚至几千上万台，运维工程师对于故障根本原因的跟踪分析就显得尤为困难。故障根本原因跟踪定位主要的难点在于，经过长时间历史的发展，业务服务的架构越来越复杂，功能模块众多、监控系统多、告警量大等等，跟踪难度较大。同时，由于业务模块众多的缘故，运维工程师在全局监控数据中，体现的监控组合维度成千上万(如省份、运营商、客户端版本、服务端版本等)，准确定位到相关故障的根因的难度较高。

在现有技术中，通常采用传统的监控工具，如Nagios、Zabbix等，监控工具可以对服务器维度的基本监控项如CPU使用率、内存使用率、磁盘空间、网络流量等进行长期监控，运维工程师需要为监控项设置告警阈值，如良好、警告、错误等几种状态，一旦超过阈值则发出告警信息。然而，一旦出现某种故障，与故障来源关联的业务指标、应用程序指标和操作系统指标等都会同时随之发出告警信息，运维工程定位故障根本原因的难度仍然较高。

基于此，本发明发明人进行大量的研究发现，在对应用系统进行监控过程中，可以采用神经网络模型对应用系统中的故障源进行定位，具体地，将应用系统的历史数据作为样本，通过神经网络模型进行训练，当神经网络模型的识别精准度达到预设值时，使用经过训练的神经网络模型获取应用系统中的告警信息，并依据该告警信息进行预测，从而得到应用系统的故障源。发明人发现，通过神经网络模型预测故障源的方式虽然在理论上能够得到较好的故障源定位结果，但是，由于神经网络模型对训练样本的要求较高，训练样本的数据量较大，应用系统出现的很多故障的重复程度较低，导致采用神经网络模型识别的效果较差，同时需要使用的计算资源较大，成本较高，不利于实际商业使用。

为了能够从根本性上解决上述描述的问题，本发明发明人继续投入研发，致力于研究如何能够提高应用系统中故障源定位的精准度。进一步地，发明人提出了本发明的应用系统的故障定位方法，在该应用系统的故障定位方法用于通过多个监控项分别监控应用系统中的多个监控对象的运行状态，在该应用系统的故障定位方法中，当任一个监控项的监控结果为异常状态时，将处于异常状态的监控项作为第一监控项；获取与第一监控项存在预设关联关系的至少一个关联监控项；获取关联监控项的监控结果，关联监控项的监控结果包括正常状态以及异常状态；以及根据监控结果确定应用系统的故障源，并输出包括故障源的信息。通过监控项分别监控应用系统中的各个监控对象，当某一监控项的监控结果为异常状态时，将该监控项作为第一监控项，并进一步获取与第一监控项存在预设关联关系的关联监控项，并根据关联监控项的监控结果得到应用系统中的故障源，从而实现将应用系统中的各个监控对象相互关联，将各个监控项相关联，使得在其中一个监控对象发生异常时，能够进而获得与监控对象存在关联的监控对象的状态，大大提高了故障源定位的精准度，可以协助运维工程师在复杂的监控项中快速定位出生产环境故障的故障源，为快速恢复生产服务和保证业务的可用性方面起到了极大的促进作用。

本发明实施的提供的应用系统的故障定位方法可以应用如图1所示的系统环境中，该系统环境可以包括服务端10、客户端20，服务端10可以与客户端20通过网络50进行通信。其中，客户端20可以包括但不限于包括个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备等智能携带装置，还可以是安装于电子设备的应用程序等软件，此处不做具体限制。服务端10可以用独立的服务器或者是多个服务器组成的服务器集群来实现。另外，服务器可以是云端服务器，还可以是传统机房服务器。进一步地，应用系统可以在服务端10运行，基于本应用系统的系统定位方法形成的系统可以作为监控中心，该监控中心可以部署于该服务端，以用于监控应用系统的状态。

请参阅图2，本发明实施例提供的一种应用系统的故障定位方法，应用于服务端10，其一旦被触发，则实施例中方法的流程可以通过控制设备自动运行，其中，各个步骤在运行的时候可以按照如流程图中的顺序先后进行，也可以根据实际情况多个步骤同时进行，在此并不作限定。需要注意的是，当应用系统中的部分功能由客户端实现时，该应用系统的故障定位方法也可以对客户端负责实现该部分功能的功能模块的故障进行定位。

该应用系统的故障定位方法用于通过多个监控项分别监控应用系统中的多个监控对象的运行状态。

在本发明实施例中，应用系统通常包含计算机硬件系统、系统软件、应用软件组成。其中，计算机硬件系统可以包括运算器和控制器、存储器、外围接口、外围设备等；系统软件可以包括操作系统、编译程序、数据库管理系统、各种高级语言等；应用软件可以包含通用支援软件和各种应用软件包。监控对象可以是应用系统中实现各个功能的单元。监控项可以用于监控对应的监控对象的状态。

需要注意的是，在本发明实施例中，可以将应用系统划分为多个监控层级，每个监控层级包含一个或多个监控对象。其中，可以将应用系统中的各个监控对象按照功能类别进行划分，监控层级可以是应用系统中属于某一种功能类别的监控对象的总称。例如，监控层级可以是业务层、应用服务层、系统服务层、操作系统层、基础设施层等。

为了能够更加清楚地理解本发明实施例中监控对象的具体含义以及监控对象之间的关系，下面对应用系统的各个监控层级进行说明：

具体地，业务层可以包含反映业务运营质量的各项指标。例如，业务层中的监控对象可以是页面浏览量(Page View，PV)、独立访客量(Unique Visitor,UV)、每天注册用户数量、每天登录用户数量、日活跃用户数量、月活跃用户数量等。应用服务层可以包含反映应用程序的运行质量。例如，应用服务层中的监控对象可以是每秒查询率(Queries-per-second，QPS)、应用接口响应成功率、应用接口响应速度、HTTP(超文本传输协议)响应码、HTTP响应速度等。系统服务层可以包含系统中各中间件的性能指标。例如，中间件可以是数据库、缓存、消息队列等，系统服务层中的监控对象可以是MySQL(关系型数据库管理系统)的QPS、中间件的负载、空间使用率等。操作系统层可以包含操作系统的各项应用指标。例如，操作系统层中的监控对象可以是CPU(中央处理器，central processing unit)使用率、内存使用率、磁盘使用率等。基础设施层可以包含服务器的基础指标。例如，当服务器IDC(互联网数据中心，Internet Data Center)机房时，基础设施层中的监控对象可以是机房、机架、路由器、交换机、专线质量等一系列指标；当服务器为云端服务器时，基础设施层中的监控对象可以是带宽总流量、负载均衡流量、实例运行状态等。

在本发明实施例中，应用系统中的各个监控层级应当是相关关联，各层级中的监控对象之间需要相互支持，进而实现各项功能。也就是说，在应用系统处于工作状态时，当业务层中的某一监控对象出现异常时，与该监控对象相关联的应用服务层中的其他监控对象可能出现异常。具体以下表(1)为例。

表(1)

如表(1)所示，应用系统被划分为五个监控层级，分别为业务层、应用服务层、系统服务层、操作系统层和基础设施层。其中，业务层中的监控对象为PV，当需要PV统计时，需要使用应用服务层中的监控对象：站点健康探测，还需要使用系统服务层中的监控对象：Tomcat(汤姆猫，Apache Tomcat)、REDIS(远程字典服务，Remote Dictionary Server)和MYSQL，还需要使用系统服务层中的监控对象：CPU、Memory(内存)、Disk(磁盘)和Network(网络)，还需要使用基础设施层中的监控对象：负载均衡、防火墙和交换机。也就是说，由于完成PV统计需要调用如表(1)所示中各个监控对象，因此，当监控对象PV出现异常时，如表(1)所示中各个监控对象均有可能处于异常状态。

需要注意的是，当监控层级包含业务层、应用服务层、系统服务层、操作系统层、基础设施层时，各监控层级之间为上下支持关系，业务层需要实现某项功能时，需要应用服务层支持；应用服务层需要实现另一项功能时，需要系统服务层和/或业务层的支持，以此类推。

本实施例中的应用系统采用分层结构，将应用系统的中的每个监控对象进行划分，从而得到多个监控层层级，由于各监控层级之间为上下支持关系，当其中一个监控层级中的某一个监控对象出现异常时，能够通过各个监控层级之间的关系能够快速获取到上下监控层级中各监控对象之间，使得各监控对象之间的关系较为明晰，在实际故障定位过程中，有助于提高故障定位的精准度和效率。

进一步地，该应用系统的故障定位方法可以包括以下步骤S11至步骤S14。

步骤S11：当任一个监控项的监控结果为异常状态时，将处于异常状态的监控项作为第一监控项。

其中，多个监控项分别用于监控多个监控对象的状态，从而得到与监控对象对应的监控结果。另外，每个监控对象可以对应有一个与监控项对应的监控项。

步骤S12：获取与第一监控项存在预设关联关系的至少一个关联监控项。

在本发明实施例中，预设关联关系可以包括监控项之间存在的功能实现关系。具体而言，当与监控项对应的监控对象实现某一功能时，若实现该功能需要调用其他监控对象，则判断与其他监控对象的监控项为关联监控项。例如，以上表(1)所示，与监控PV的监控项存在预设关联关系的关联监控项包括分别与站点健康探测、Tomcat、REDIS、MYSQL、CPU、Memory、Disk、Network、负载均衡、防火墙、交换机对应的各个监控项。

步骤S13：获取关联监控项的监控结果，关联监控项的监控结果包括正常状态以及异常状态。

在本发明实施例中，可以获取每个关联监控项的监控结果。具体地，以上表(1)为例，当与PV对应的监控项的结果为异常状态时，可以分别获取与其关联的与站点健康探测、Tomcat、REDIS、MYSQL、CPU、Memory、Disk、Network、负载均衡、防火墙、交换机对应的各个监控项的监控结果。

步骤S14：根据监控结果确定应用系统的故障源，并输出包括故障源的信息。

在本发明实施例中，故障源可以是与第一监控项对应的监控对象，还可以是与关联监控项对应的监控对象。另外，具体可以根据监控结果或/及监控对象的运行参数进行分析计算以获得应用系统的故障源。

需要注意的是，当确定监控结果的故障源后，可以输出包括故障源的信息，该信息可以是故障提示信息，用于提示运维工程师获知应用系统中的故障原因。例如，当得到应用系统的故障源为Memory时，反馈信息“应用系统中的Memory为故障源，请尽快排除故障”，以提醒运维工程师，其中，反馈信息的方式可以是多种，比如机房告警、短信发送、邮件发送、语音播报等，此处对反馈信息的方式不做具体限制。

在本实施例中，通过上述步骤S11至步骤S14的实施，能够通过监控项分别监控应用系统中的各个监控对象，当某一监控项的监控结果为异常状态时，将该监控项作为第一监控项，并进一步获取与第一监控项存在预设关联关系的关联监控项，并根据关联监控项的监控结果得到应用系统中的故障源，并输出包括故障源的信息，从而实现将应用系统中的各个监控对象相互关联，将各个监控项相关联，使得在其中一个监控对象发生异常时，能够进而获得与监控对象存在关联的监控对象的状态，大大提高了故障源定位的精准度，可以协助运维工程师在复杂的监控项中快速定位出生产环境故障的故障源，为快速恢复生产服务和保证业务的可用性方面起到了极大的促进作用。

进一步地，作为本实施例的一种实施方式，如图3所示，上述步骤S12还可以包括以下步骤S121至步骤S122。

步骤S121：确定第一监控项所属的监控组，其中，监控组包括第一监控项以及一个或多个各不相同的第二监控项，第一监控项以及每个第二监控项分别用于监控一个对应的监控对象。

在本发明实施例中，监控组可以包括应用系统完成某一功能所需要调用的监控对象的集合。在监控应用系统中监控对象的监控组的数量可以是一个或者多个，监控组中的多个监控对象可以分布于一个或者多个监控层级。另外，确定第一监控项所属的监控组的方式可以是在预先设定的数据库中查询，该预先设定的数据库中应当预存有各个监控项与各个监控组之间的映射关系。

需要注意的是，一个监控项可以属于一个监控组，还可以属于不同的监控组。也就是说，确定第一监控项所属的监控组的数量可以是一个或者多个。

步骤S122：根据监控组，在一个或多个第二监控项中确定与第一监控项存在预设关联关系的第二监控项，将与第一监控项存在预设关联关系的第二监控项确定为关联监控项。

在本发明实施例中，当第一监控项对应的监控对象处于工作状态时，需要调用第一监控项所属的监控组中所有第二监控项监控的监控对象时，此时第一监控项所属的监控组中所有第二监控项均为关联监控项。例如，以上表(1)为例，与PV、站点健康探测、Tomcat、REDIS、MYSQL、CPU、Memory、Disk、Network、负载均衡、防火墙、交换机对应的各个监控项形成监控组，当与PV对应的监控项的监控结果为异常时，将与PV对应的监控项作为第一监控项，将与站点健康探测、Tomcat、REDIS、MYSQL、CPU、Memory、Disk、Network、负载均衡、防火墙、交换机对应的各个监控项分别作为第二监控项，由于在实现PV统计时，需要调用站点健康探测、Tomcat、REDIS、MYSQL、CPU、Memory、Disk、Network、负载均衡、防火墙、交换机等监控项，因此将各个第二监控项视为关联监控项。当第一监控项对应的监控对象处于工作状态时，需要调用第一监控项所属的监控组中部分第二监控项监控的监控对象时，此时第一监控项所属的监控组中该部分第二监控项均为关联监控项。

在实施例中，通过上述步骤S121至步骤S122的实施，能够先获取第一监控项所属的监控组，再基于所属的监控组确定与第一监控项存在预设关联关系的关联监控项，由于监控组与监控项之间的关系为预先设定，而无需在数据库中遍历查询，再一一判断其他监控项与第一监控项之间的关系，有效减少了查询时间，提高故障源定位效率。

进一步地，作为本实施例的一种实施方式，如图4所示，上述步骤S14可以包括以下步骤S141至步骤S142。

步骤S141：若关联监控项中的至少一个的监控结果为异常状态，则获取第一监控项的第一权重值以及处于异常状态的关联监控项的第二权重值。

在本发明实施例中，可以预先为每个监控项设置一个对应的权重值，在故障定位时，则可以根据第一监控项的第一权重值以及处于异常状态的关联监控项的第二权重值来确定与监控项对应的监控对象是否为故障源。

另外，每个监控项的权重值可以保存于预先构建的数据库中，从预先构建的数据库中获取第一监控项的第一权重值以及处于异常状态的关联监控项的第二权重值。需要注意的是，针对一个监控项，该监控项的权重值应当配置于该监控项所属的监控组。

步骤S142：根据第一权重值以及第二权重值，以及关联监控项、第一监控项与监控对象之间的对应关系，从多个监控对象中确定故障源，并输出包括故障源的信息。

在本发明实施例中，可以根据第一权重值和第二权重值的大小确定值障源。进一步地，可以将与第一权重值和第二权重值中数值最大的权重值对应的监控对象确定为故障源，还可以将与第一权重值和第二权重值中数值排名靠前的权重值对应的监控对象确定为故障源。例如，可以将在第一权重值和第二权重值中数值排名前三的权重值对应的监控对象确定为故障源，还可以将在第一权重值和第二权重值中数值排名前百分之二十的权重值对应的监控对象确定为故障源，此处不做具体限制。也就是说，故障源可以是一个或者多个。以下表(2)为例：

表(2)

如表(2)所示，将与PV对应的监控项作为第一监控项，获取第一监控项的第一权重值为“1”；将与站点健康探测、Tomcat、REDIS、MYSQL、CPU、Memory、Disk、Network、负载均衡、防火墙、交换机对应的各个监控项分别作为关联监控项，获取与监控结果为异常状态的关联监控项对应的监控对象：站点健康探测、Tomcat、REDIS、MYSQL、CPU、Memory，并获取分别与站点健康探测、Tomcat、REDIS、MYSQL、CPU、Memory对应的关联监控项的第二权重值分别为“2”、“3”、“3”、“3”、“4”、“4”，根据第一权重值以及各个第二权重值的大小，将权重值为“4”的两个关键监控项对应的监控对象(CPU和Memory)确定为故障源。

在本实施例中，通过上述步骤S141至步骤S142的实施，能够依据各个关联监控项的监控结果、第一监控项的第一权重值和关联监控项的第二权重值来确定故障源，而不必将所有监控结果为异常状态的监控对象作为故障源，从而有效提高了故障源定位的精准度，减少运维工程师排查时间。

进一步地，作为本实施例的一种实施方式，如图5所示，在上述步骤S11之前，可以预先配置各个监控项的权重值，配置各个监控项的权重值可以包括以下步骤S21至步骤S22。

步骤S21：对多个监控项进行分组处理，得到至少一个监控组。

在本发明实施例中，一个监控组可以包含一个或多个监控项，一个监控项可以属于一个或多个监控组。

另外，在对多个监控项进行分组时，可以将完成某一功能所需要调用的应用系统中的监控对象划分为同一个监控组。例如，以上表(1)为例，在进行PV统计时，需要调用站点健康探测、Tomcat、REDIS、MYSQL、CPU、Memory、Disk、Network、负载均衡、防火墙、交换机，因此，可以将PV、站点健康探测、Tomcat、REDIS、MYSQL、CPU、Memory、Disk、Network、负载均衡、防火墙、交换机划分为同一监控组。

步骤S22：根据监控对象的应用属性，以及监控对象和监控对象之间的对应关系，配置每个监控项的权重值。

在本发明实施例中，应用属性可以包括监控对象功能应用情况。例如，应用属性可以是监控对象实现功能时的逻辑、监控对象的调用时间、与其他监控对象之间的调用关系等。具体而言，当监控对象在某一监控组中处理的数据部分重要程度越高，在该监控组中与该监控对象对应的监控项配置的权重值可以越大；当监控对象在某一监控组中被调用的次数越多，在该监控组中与该监控对象对应的监控项配置的权重值也可以越大。也就是说，运维工程师自身根据业务的特性进行归类、汇总，从而调整监控项在监控组中的权重大小。

需要注意的是，在本发明实施例中，对于同一监控项，可以同时属于多个监控组，该监控项在不同的监控组中的权重可以是不相同，可以依据业务情况确定。例如，存在一个监控项A，监控项A分别属于监控组X和监控组Y，监控项A在监控组X中的权重值为a，监控项A在监控组Y中的权重值为b，a和b的大小可以相同，也可以不相同。

在本实施例中，通过上述步骤S21至步骤S22的实施，能够基于监控对象的应用属性，配置与监控对象对应的监控项在监控项中的权重值，使得本实施例在实际应用时运维工程师能够依据各种业务特性对配置各个监控项在所属监控组中的权重值。

进一步地，作为本实施例的一种实施方式，上述步骤S14在确定故障源时，可以包括：若每个关联监控项的监控结果均为正常状态，则确定与第一监控项对应的监控对象为故障源，并输出包括故障源的信息。

在本发明实施例中，若每个关联监控项的监控结果均为正常状态时，故障源即为与第一监控项对应的监控对象。例如，该监控组包括第一监控项B、关联监控项C、关联监控项D、关联监控项E，当关联监控项C、关联监控项D、关联监控项E的监控结果均为正常状态时，将与第一监控项B对应的监控对象确定为故障源。

在本实施例中，通过若每个关联监控项的监控结果均为正常状态，则确定与第一监控项对应的监控对象为故障源的步骤的实施，能够对关联监控项进行排查，将其排除在故障源之外，从而避免运维工程师排查未故障的监控对象而耗费过多时间。

进一步地，作为本实施例的一种实施方式，如图6所示，在上述步骤S11之前，可以进行基于监控对象的监控类型选择不同的处理方式得到监控结果的步骤以用于针对不同的监控对象采用不同的处理标准，因此在步骤S11之前，本实施例的应用系统的故障定位方法还可以包括以下步骤S31至步骤S32。

步骤S31：获取每个监控对象的监控类型，监控类型包括静态类型和动态类型。

在本发明实施例中，监控对象的监控类型可以根据其运行状态的判断基准来分类，该判断基准可以理解为判断监控对象的运行状态正常或异常的依据，其中，判断基准的参数不随时间变化的监控对象属于静态类型，判断基准的参数随时间发生改变的监控对象属于动态类型。例如，属于静态类型的监控对象可以是磁盘空间、CPU、Tomcat、REDIS、MYSQL等；属于动态类型的监控对象可以是PV、UV、每天注册用户数量、每天登录用户数量、日活跃用户数量等。

步骤S32：根据监控类型对每个监控对象的运行参数进行分析，以获得每个监控对象所对应的监控项的监控结果。

在本发明实施例中，可以针对不同监控类型的监控对象采用不同的判断标准，从而获得每个监控对象所对应的监控项的监控结果。运行参数可以是用于表示监控对象运行情况的参数。例如，当监控对象为登录页面时，运行参数可以是PV、UV、每天注册用户数量等。当监控对象的监控类型为静态类型时，选择与静态类型对应的处理方式获得与监控对象对应的监控项的监控结果；当监控对象的监控类型为动态类型时，选择与动态类型对应的处理方式获得与监控对象对应的监控项的监控结果。

在本实施例中，通过上述步骤S31至步骤S32的实施，能够基于监控对象的不同监控类型，选择不同的处理方法得到监控项的监控结果，实现多样化处理，以适应于不同的应用场景。

进一步地，作为本实施例的一种实施方式，如图7所示，可以针对监控类型为静态类型的监控对象选择对应的处理方式得到监控结果以用于获得与监控类型为静态类型的监控对象对应的监控项的监控结果，因此，上述步骤S32还可以包括以下步骤S321至步骤S322。

步骤S321：若监控对象的监控类型为静态类型，则获取该监控对象的第一运行参数。

在本发明实施例中，第一运行参数可以是用于表示属于静态类型的监控对象的运行信息。例如，第一运行参数可以是磁盘空间使用率、CPU使用率、内存占有率等。

步骤S322：根据第一运行参数与预设的静态阈值之间的大小关系，确定监控类型为静态类型的监控对象所对应的监控项的监控结果。

在本发明实施例中，静态阈值可以根据经验确定。例如，当第一运行参数为磁盘空间使用率时，静态阈值可以是90％；当第一运行参数为CPU使用率时，静态阈值可以是80％。

在本发明实施例中，当第一运行参数大于静态阈值时，则确定与监控对象对应的监控项的监控结果为异常状态；当第一运行参数小于或等于静态阈值时，则确定与监控对象对应的监控项的监控结果为正常状态。例如，当监控对象的第一运行参数为CPU使用率95％，静态阈值为90％时，第一运行参数大于静态阈值，表明此时CPU处于超负荷运行状态，与CPU对应的监控项的监控结果为异常状态，当CPU被确定为故障源时，可以输出信息“CPU使用率95％，处于超负荷状态”，以提示运维工程师。

在本实施例中，通过上述步骤S321至步骤S322的实施，能够判断属于静态类型的监控对象是否异常，从而得到监控结果，并且采用静态阈值判断的方式。

进一步地，作为本实施例的一种实施方式，如图8所示，可以针对监控类型为动态类型的监控对象选择对应的处理方式得到监控结果以用于获得与监控类型为动态类型的监控对象对应的监控项的监控结果，因此，上述步骤S32还可以包括以下步骤S323至步骤S325。

步骤S323：若监控对象的监控类型为动态类型，则获取该监控对象的第二运行参数。

在本发明实施例中，第二运行参数可以是用于表示属于动态类型的监控对象的运行信息。例如，第二运行参数可以是PV、UV、某段时间的注册用户数量等。

步骤S324：获取监控类型为动态类型的监控对象在预设时间内的第三运行参数，根据第三运行参数确定动态阈值。

在本发明实施例中，第三运行参数可以是用于表示属于动态类型的监控对象在过往的预设时间内的运行信息。其中，预设时间可以是过往一周、一月、一年等，具体可以根据经验确定。列举示例：假设预设时间为过往一个月，监控对象的第三运行参数为每日注册量，根据过往一个月内的第三运行参数可以发现：每周周六的每日注册量均在一万以上，每周其他时间的每日注册量均在一千以上，则可以将后续每周周六的动态阈值设置为一万，将后续每周除周六以外的时间段的动态阈值设置为一千。

进一步地，作为本实施例的一种实施方式，在步骤S324中，根据第三运行参数确定动态阈值的步骤可以包括：根据预先设定的概率阈值和第三运行参数在预设时间内的分布情况确定动态阈值。

在本发明实施例中，概率阈值可以通过经验确定。对第三运行参数在预设时间内的分布情况的表现形式不做具体限制，例如可以第三运行参数在预设时间内的分布情况用图表、曲线、概率图进行表示。其中，可以获取第三运行参数在预设时间内的分布情况，采用预先设定的概率阈值对该分布情况进行分割，获取在概率阈值范围内的第三运行参数，再根据在概率阈值范围内的第三运行参数确定动态阈值。

进一步地，在根据第三运行参数确定动态阈值时，可以先获取监控对象的第三运行参数；通过拉依达准则对该数据的分布进行处理，得到第三运行参数在预设时间段内的正态分布数据；基于预先设定的概率阈值和正态分布数据确定动态阈值。为了能够更加清楚地理解确定动态阈值的内容，列举以下示例：

监控对象为PV，获取过往一个月内的PV，采用拉依达准则对过往一个月内的PV进行处理，获得第三运行参数在过往一个月内的正态分布数据，根据该正态分布数据发现：数值分布在(μ-σ,μ+σ)中的概率为0.6827，数值分布在(μ-2σ,μ+2σ)中的概率为0.9545，数值分布在(μ-3σ,μ+3σ)中的概率为0.9973，其中，μ代表过往一个月内第三运行参数的标准差，μ代表过往一个月内第三运行参数的平均值，根据该正态分布数据可知，过往一个月内的第三运行参数主要集中在(μ-3σ,μ+3σ)区间内，超出这个范围的可能性仅占不到0.3％，因此，可以将0.9973作为概率阈值，动态阈值为处于(μ-3σ,μ+3σ)区间的第三运行参数经过拉依达准则处理的最大值和最小值。也就是说，当第二运行参数经过拉依达准则处理后的数值若在(μ-3σ,μ+3σ)区间内，则与该第二运行参数对应的监控项的监控结果为正常状态；当第二运行参数经过拉依达准则处理后的数值若在(μ-3σ,μ+3σ)区间外，则与该第二运行参数对应的监控项的监控结果为异常状态。

通过上述示例可知，可以根据第三运行参数得到动态阈值。需要注意的是，上述示例仅作为说明本实施例内容的一种示例，基于拉依达准则采用过往的经验数据来生成动态阈值的一种方式，该种方式适用于第三运行参数的数据量较大时的情况，当第三运行参数的数据量较少时，可以根据经验使用其他概率阈值分割的方式得到动态阈值，此处不做具体限制。

在本实施例中，通过上述根据预先设定的概率阈值和第三运行参数在预设时间内的分布情况确定动态阈值的实施，能够基于第三运行参数灵活得到动态阈值，而无需人工重复设置阈值，有效减少人力的同时，还可以充分利用过往数据进行预测，提高了判断与监控对象对应的监控项是否异常的精准度。

步骤S325：根据第二运行参数与动态阈值之间的大小关系，确定监控类型为动态类型的监控对象所对应的监控项的监控结果。

在本发明实施例中，可以是当第二运行参数大于动态阈值时，则确定与监控对象对应的监控项的监控结果为异常状态；可以是当第二运行参数小于或等于动态阈值时，则确定与监控对象对应的监控项的监控结果为正常状态。需要注意的是，本实施例对第二运行参数与动态阈值之间的大小比对方法不做具体限制。

以上述步骤S234中列举的示例进行说明：在后续监控过程中，若在周六的第二运行参数为六千，其小于对应的动态阈值，则确定与该监控对象对应的监控项的监控结果为异常状态；若在周一的第二运行参数为三千，其大于对应的动态阈值，则确定与该监控对象对应的监控项的监控结果为正常状态。

在本实施例中，通过上述步骤S323至步骤S325的实施，能够判断属于动态类型的监控对象是否异常，从而得到监控结果，其中的动态阈值可以是随时间生成，能够针对属于动态类型的监控对象采用相应的判断标准，提高监控结果判断的精准度。

通过上述应用系统的故障定位方法的实施，能够通过监控项分别监控应用系统中的各个监控对象，当某一监控项的监控结果为异常状态时，将该监控项作为第一监控项，并进一步获取与第一监控项存在预设关联关系的关联监控项，并根据关联监控项的监控结果得到应用系统中的故障源，从而实现将应用系统中的各个监控对象相互关联，将各个监控项相关联，使得在其中一个监控对象发生异常时，能够进而获得与监控对象存在关联的监控对象的状态，大大提高了故障源定位的精准度，可以协助运维工程师在复杂的监控项中快速定位出生产环境故障的故障源；还能够先获取第一监控项所属的监控组，再基于所属的监控组确定与第一监控项存在预设关联关系的关联监控项，由于监控组与监控项之间的关系为预先设定，而无需在数据库中遍历查询，再一一判断其他监控项与第一监控项之间的关系；还能够基于监控对象的应用属性，配置与监控对象对应的监控项在监控项中的权重值，使得本实施例在实际应用时运维工程师能够依据各种业务特性对配置各个监控项在所属监控组中的权重值；并且能够判断属于动态类型的监控对象是否异常，从而得到监控结果，其中的动态阈值可以是随时间生成，能够针对属于动态类型的监控对象采用相应的判断标准，提高监控结果判断的精准度。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

本发明实施例提供一种应用系统的故障定位装置，该应用系统的故障定位装置与上述提供的应用系统的故障定位方法大致一一对应。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

请参阅图9，其示出了本发明实施例提供的一种应用系统的故障定位装置，该应用系统的故障定位装置用于通过多个监控项分别监控应用系统中的多个监控对象的运行状态，该应用系统的故障定位装置包括第一监控项获取模块410、关联监控项获取模块420、监控结果获取模块430和故障源确定模块440。各功能模块详细说明如下：

第一监控项获取模块410，用于当任一个监控项的监控结果为异常状态时，将处于异常状态的监控项作为第一监控项；关联监控项获取模块420，用于获取与第一监控项存在预设关联关系的至少一个关联监控项；监控结果获取模块430，用于获取关联监控项的监控结果，关联监控项的监控结果包括正常状态以及异常状态；以及故障源确定模块440，用于根据监控结果确定应用系统的故障源，并输出包括故障源的信息。

进一步地，作为一种实施方式，该应用系统的故障定位装置中的关联监控项获取模块420可以包括监控组确定单元和关联监控项确定单元。各功能单元详细说明如下：监控组确定单元，用于确定第一监控项所属的监控组，其中，监控组包括第一监控项以及一个或多个各不相同的第二监控项，第一监控项以及每个第二监控项分别用于监控一个对应的监控对象；以及关联监控项确定单元，用于根据监控组，在一个或多个第二监控项中确定与第一监控项存在预设关联关系的第二监控项，将与第一监控项存在预设关联关系的第二监控项确定为关联监控项。

进一步地，作为一种实施方式，该应用系统的故障定位装置中的故障源确定模块440可以包括权重值确定单元和故障源确定单元。各功能单元详细说明如下：权重值确定单元，用于若关联监控项中的至少一个的监控结果为异常状态，则获取第一监控项的第一权重值以及处于异常状态的关联监控项的第二权重值；以及故障源确定单元，用于根据第一权重值以及第二权重值，以及关联监控项、第一监控项与监控对象之间的对应关系，从多个监控对象中确定故障源，并输出包括故障源的信息。

进一步地，作为一种实施方式，该应用系统的故障定位装置还可以包括监控组获取模块和权重值配置模块。各功能模块详细说明如下：监控组获取模块，用于对各个监控项进行分组处理，得到至少一个监控组；权重值配置模块，用于根据监控对象的应用属性，配置与监控对象对应的监控项在监控项中的权重值。

进一步地，作为一种实施方式，该应用系统的故障定位装置中的故障源确定模块440可以包括第一故障源确定单元。第一故障源确定单元详细说明如下：第一故障源确定单元，用于若每个关联监控项的监控结果均为正常状态，则确定与第一监控项对应的监控对象为故障源，并输出包括故障源的信息。

进一步地，作为一种实施方式，该应用系统的故障定位装置还可以包括监控类型获取模块和监控结果确定模块。各功能模块详细说明如下：类型获取模块，用于获取每个监控对象的类型，类型包括静态类型和动态类型；监控结果确定模块，用于根据监控类型对每个监控对象的运行参数进行分析，以获得每个监控对象所对应的监控项的监控结果。

进一步地，作为一种实施方式，该应用系统的故障定位装置中的监控结果确定模块可以包括第一运行参数获取单元和监控结果确定单元。各功能单元详细说明如下：第一运行参数获取单元，用于若监控对象的监控类型为监控类型为静态类型，则获取该监控对象的第一运行参数；监控结果确定单元，用于根据第一运行参数与预设的静态阈值之间的大小关系，确定监控类型为静态类型的监控对象所对应的监控项的监控结果。

进一步地，作为一种实施方式，该应用系统的故障定位装置中的监控结果确定模块还可以包括第二运行参数获取单元、动态阈值确定单元和监控结果确认单元。各功能单元详细说明如下：第二运行参数获取单元，用于若监控对象的监控类型为动态类型，则获取该监控对象的第二运行参数；动态阈值确定单元，用于获取监控类型为动态类型的监控对象在预设时间内的第三运行参数，根据第三运行参数确定动态阈值；监控结果确认单元，用于根据第二运行参数与动态阈值之间的大小关系，确定监控类型为动态类型的监控对象所对应的监控项的监控结果。

进一步地，作为一种实施方式，上述动态阈值确定单元可以包括第三运行参数获取子单元和动态阈值确定子单元。各功能子单元详细说明如下：第三运行参数获取子单元，用于获取监控类型为动态类型的监控对象在预设时间内的第三运行参数。动态阈值确定子单元，用于根据预先设定的概率阈值和第三运行参数在预设时间内的分布情况确定动态阈值。

另外，在本发明各个实施例中的各功能模块和功能单元可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的应用系统的故障定位装置中的各个模块和单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

请参阅图10，其示出了本发明实施例提供的一种电子设备800，包括：处理器810、通信模块820、存储器830和总线。处理器810、通信模块820和存储器830通过总线相互连接并完成相互间的通信。总线可以是ISA总线、PCI总线或EISA总线等。总线可以分为地址总线、数据总线、控制总线等。其中：

存储器830，用于存放程序。具体地，存储器830可用于存储软件程序以及各种数据。存储器830可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作至少一个功能所需的应用程序程序可以包括程序代码，程序代码包括计算机操作指令。除了存放程序之外，存储器830还可以暂存通信模块820需要发送的消息等。存储器830可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

处理器810用于执行存储器830存放的程序。程序被处理器执行时实现上述各实施例的基于权限的智能设备控制方法的步骤。

本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述基于权限的智能设备控制方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，的计算机可读存储介质，如只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random AccessMemory，简称RAM)、磁碟或者光盘等。

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

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本发明的保护之内。

Claims (12)

1.一种应用系统的故障定位方法，其特征在于，所述方法用于通过多个监控项分别监控应用系统中的多个监控对象的运行状态，所述方法包括：

当任一个监控项的监控结果为异常状态时，将处于异常状态的监控项作为第一监控项；

获取与所述第一监控项存在预设关联关系的至少一个关联监控项；

获取所述关联监控项的监控结果，所述关联监控项的监控结果包括正常状态以及异常状态；以及

根据所述监控结果确定所述应用系统的故障源，并输出包括所述故障源的信息。

2.根据权利要求1所述的应用系统的故障定位方法，其特征在于，所述获取与所述第一监控项存在预设关联关系的至少一个关联监控项的步骤，包括：

确定所述第一监控项所属的监控组，其中，所述监控组包括所述第一监控项以及一个或多个各不相同的第二监控项，所述第一监控项以及每个所述第二监控项分别用于监控一个对应的监控对象；以及

根据所述监控组，在一个或多个所述第二监控项中确定与所述第一监控项存在所述预设关联关系的第二监控项，将与所述第一监控项存在预设关联关系的第二监控项确定为所述关联监控项。

3.根据权利要求1所述的应用系统的故障定位方法，其特征在于，所述根据所述监控结果确定所述应用系统的故障源，并输出包括所述故障源的信息的步骤，包括：

若所述关联监控项中的至少一个的监控结果为异常状态，则获取所述第一监控项的第一权重值以及处于异常状态的所述关联监控项的第二权重值；以及

根据所述第一权重值以及所述第二权重值，以及所述关联监控项、所述第一监控项与所述监控对象之间的对应关系，从多个所述监控对象中确定故障源，并输出包括所述故障源的信息。

4.根据权利要求3所述的应用系统的故障定位方法，其特征在于，所述当任一个监控项的监控结果为异常状态时，将处于异常状态的监控项作为第一监控项的步骤之前，所述方法包括：

对多个所述监控项进行分组处理，得到至少一个监控组；以及

根据所述监控对象的应用属性，以及所述监控对象和所述监控项之间的对应关系，配置每个所述监控项的权重值。

5.根据权利要求1所述的应用系统的故障定位方法，其特征在于，所述根据所述监控结果确定所述应用系统的故障源，并输出包括所述故障源的信息的步骤，包括：

若每个所述关联监控项的监控结果均为正常状态，则确定与所述第一监控项对应的监控对象为故障源。

6.根据权利要求1所述的应用系统的故障定位方法，其特征在于，所述当任一个监控项的监控结果为异常状态时，将处于异常状态的监控项作为第一监控项的步骤之前，所述方法包括：

获取每个所述监控对象的监控类型，所述监控类型包括静态类型和动态类型；以及

根据所述监控类型对每个所述监控对象的运行参数进行分析，以获得每个所述监控对象所对应的监控项的监控结果。

7.根据权利要求6所述的应用系统的故障定位方法，其特征在于，所述根据所述监控类型对每个所述监控对象的运行参数进行分析，以获得每个所述监控对象所对应的监控项的监控结果的步骤，包括：

若所述监控对象的监控类型为静态类型，则获取该监控对象的第一运行参数；以及

根据所述第一运行参数与预设的静态阈值之间的大小关系，确定监控类型为静态类型的所述监控对象所对应的监控项的监控结果。

8.根据权利要求6所述的应用系统的故障定位方法，其特征在于，所述根据所述监控类型对每个所述监控对象的运行参数进行分析，以获得每个所述监控对象所对应的监控项的监控结果的步骤，包括：

若所述监控对象的监控类型为所述动态类型，则获取该监控对象的第二运行参数；

获取监控类型为动态类型的所述监控对象在预设时间内的第三运行参数，根据所述第三运行参数确定动态阈值；以及

根据所述第二运行参数与所述动态阈值之间的大小关系，确定监控类型为动态类型的所述监控对象所对应的监控项的所述监控结果。

9.根据权利要求8所述的应用系统的故障定位方法，其特征在于，所述获取监控类型为静态类型的所述监控对象在预设时间内的第三运行参数，根据所述第三运行参数得到动态阈值的步骤，包括：

获取监控类型为动态类型的所述监控对象在预设时间内的第三运行参数；以及

根据预先设定的概率阈值和所述第三运行参数在所述预设时间内的分布情况确定所述动态阈值。

10.一种应用系统的故障定位装置，其特征在于，所述装置用于通过多个监控项分别监控应用系统中的多个监控对象的运行状态，所述装置包括：

第一监控项获取模块，用于当任一个监控项的监控结果为异常状态时，将处于异常状态的监控项作为第一监控项；

关联监控项获取模块，用于获取与所述第一监控项存在预设关联关系的至少一个关联监控项；

监控结果获取模块，用于获取所述关联监控项的监控结果，所述关联监控项的监控结果包括正常状态以及异常状态；以及

故障源确定模块，用于根据所述监控结果确定所述应用系统的故障源，并输出包括所述故障源的信息。

11.一种电子设备，其特征在于，包括：

存储器；

一个或多个处理器，与所述存储器耦接；

一个或多个程序，其中，所述一个或多个应用程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序配置用于执行如权利要求1-9中任一项所述的方法。

12.一种计算机可读取存储介质，其特征在于，所述计算机可读取存储介质中存储有程序代码，所述程序代码可被处理器调用执行如权利要求1-9中任一项所述的方法。

Images