CN109408302B

CN109408302B - 一种故障检测方法、装置及电子设备

Info

Publication number: CN109408302B
Application number: CN201710703012.4A
Authority: CN
Inventors: 田英鹤
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Cloud Computing Ltd
Priority date: 2017-08-16
Filing date: 2017-08-16
Publication date: 2022-07-05
Anticipated expiration: 2037-08-16
Also published as: CN109408302A

Abstract

本申请提供一种故障检测方法、装置及电子设备；所述故障检测方法包括：对于待检测故障的用户实例，获取所述用户实例的资源使用量及资源量上限；比较所述用户实例的资源使用量及资源量上限，根据比较结果确定所述用户实例是否存在故障。本申请至少一个实施例可以更加准确的对故障进行排查。

Description

一种故障检测方法、装置及电子设备

技术领域

本发明涉及云计算领域，尤其涉及一种故障检测方法、装置及电子设备。

背景技术

在云计算系统中，用户购买的云端的各种云服务称为用户实例，可以包括主机实例，数据库实例，对象存储实例，日志实例等；一个用户实例在用户看来就是一个完整的设备，但在云端是多个用户实例共享同一个或多个物理主机。

对于一个用户实例，当用户部分请求变慢，发现服务器无法及时响应时，需要进行故障判断。由于云计算系统涉及的软硬件层次和技术众多，比如应用系统，操作系统，驱动程序，硬件等等各个模块都有可能是故障的来源，因此如果进行故障判断时对全部相关模块都检查一遍，耗时将会较多，通常短时间内无法准确判断是由于主机(本文所提及的主机均是指物理主机)本身软硬件故障，还是由于主机的资源使用瓶颈而导致响应时间变长。

现有的故障判断方案通常是采集主机的操作系统日志来做过滤故障关键字，抓取到关键字后，判断出该主机是否有故障发生。一般系统结构如图1所示，包括：

在用于向用户实例提供资源的主机上部署一个日志采集程序，负责采集该主机的日志，比如linux下的dmesg或/var/log等。然后通过日志过滤、分析程序将采集的日志和故障关键字进行文本匹配，将匹配出的故障信息(如果有)通过网络存储到数据存储(比如数据库等)设备中。然后对外提供故障数据访问接口，供查询该部分数据。

当发现主机的响应变慢时，外部系统访问故障数据访问接口来查询该主机是否有采集到故障信息，根据查询结果来判断是否为主机本身故障导致。

现有的故障判断方案存在以下缺点：

当外部系统查询该接口获取不到数据存储设备中的故障数据时，即认为该主机无故障发生，但没有故障数据有可能是因为日志收集不全或故障关键字设置不合理造成的，所以判断结果并不一定准确。

发明内容

本申请提供一种故障检测方法、装置及电子设备，可以更加准确的对故障进行排查。

本申请采用如下技术方案。

一种故障检测方法，包括：

对于待检测故障的用户实例，获取所述用户实例的资源使用量及资源量上限；

比较所述用户实例的资源使用量及资源量上限，根据比较结果确定所述用户实例是否存在故障。

其中，所述资源可以包括以下一或多种：

中央处理器CPU、内存、磁盘、网络；

所述资源使用量可以包括以下一种或多种：

CPU核数、内存大小、磁盘每秒输入输出量iops、磁盘带宽、网络带宽。

相应地，所述资源量上限可以包括以下一种或多种：

CPU核数上限、内存上限、iops上限、磁盘带宽上限、网络带宽上限。

其中，所述对于待检测故障的用户实例，获取所述用户实例的资源使用量及资源量上限前还可以包括：

周期性获取各用户实例的请求统计数据；

分别根据各用户实例的请求统计数据，判断各用户实例是否为待检测故障的用户实例。

其中，所述请求统计数据可以包括：每秒查询率QPS、每秒事务处理量TPS和响应时间RT；

所述分别根据各用户实例的请求统计数据，判断各用户实例是否为待检测故障的用户实例可以包括：

对于各用户实例分别进行以下操作：当该用户实例本周期的TPS和QPS与上一周期相比，增长率均低于第一预定阈值，且本周期的RT与上一周期相比，增长率高于第二预定阈值时，将该用户实例作为待检测故障的用户实例。

其中，所述获取用户实例的资源使用量可以包括：

在预定长度的时间段中的T个时间点分别采集所述用户实例对各种资源的资源使用量，T是预定正整数；

所述比较用户实例的资源使用量及资源量上限，根据比较结果确定所述用户实例是否存在故障可以包括：

对于各种资源分别进行以下操作：将所采集的该种资源的T个资源使用量分别和所述用户实例该种资源的资源量上限进行比较，得到该种资源的T个比较结果；

根据各种资源的T个比较结果确定所述用户实例是否存在故障。

其中，所述根据各种资源的T个比较结果确定所述用户实例是否存在故障可以包括：

如果一种资源的T个比较结果中有N个比较结果满足预定条件，则确定该种资源的使用达到极限；其中，N是小于T的正整数；

如果存在至少一种资源的使用达到极限，则确定所述用户实例不存在故障；

如果各种资源的使用都没有达到极限，则确定所述用户实例存在故障。

其中，所述根据比较结果确定所述用户实例是否存在故障后还可以包括：

如果确定所述用户实例存在故障，且所述用户实例所在主机中，仅所述用户实例被确定为存在故障，则判断是所述用户实例本身出现故障；

如果确定所述用户实例存在故障，且所述用户实例所在主机中，各用户实例都被确定为存在故障，则判断是所述用户实例所在主机出现故障。

一种故障检测装置，包括：

检测模块，用于对于待检测故障的用户实例，获取所述用户实例的资源使用量及资源量上限；

故障判断模块，用于比较所述用户实例的资源使用量及资源量上限，根据比较结果确定所述用户实例是否存在故障。

其中，所述资源可以包括以下一或多种：

中央处理器CPU、内存、磁盘、网络；

所述资源使用量可以包括以下一种或多种：

CPU核数、内存大小、磁盘每秒输入输出量iops、磁盘带宽、网络带宽；

相应地，所述资源量上限可以包括以下一种或多种：

其中，所述的故障检测装置还可以包括：

选择模块，用于周期性获取各用户实例的请求统计数据；分别根据各用户实例的请求统计数据，判断各用户实例是否为待检测故障的用户实例。

所述选择模块分别根据各用户实例的请求统计数据，判断各用户实例是否为待检测故障的用户实例可以包括：

所述选择模块对于各用户实例分别进行以下操作：当该用户实例本周期的TPS和QPS与上一周期相比，增长率均低于第一预定阈值，且本周期的RT与上一周期相比，增长率高于第二预定阈值时，将该用户实例作为待检测故障的用户实例。

其中，所述检测模块获取用户实例的资源使用量可以包括：

所述检测模块在预定长度的时间段中的T个时间点分别采集所述用户实例对各种资源的资源使用量，T是预定正整数；

所述故障判断模块比较所述用户实例的资源使用量及资源量上限，根据比较结果确定所述用户实例是否存在故障可以包括：

所述故障判断模块对于各种资源分别进行以下操作：将所采集的该种资源的T个资源使用量分别和所述用户实例该种资源的资源量上限进行比较，得到该种资源的T个比较结果；根据各种资源的T个比较结果确定所述用户实例是否存在故障。

其中，所述故障判断模块根据各种资源的T个比较结果确定所述用户实例是否存在故障可以包括：

所述故障判断模块当一种资源的T个比较结果中有N个比较结果满足预定条件时，确定该种资源的使用达到极限；其中，N是小于T的正整数；如果存在至少一种资源的使用达到极限，则确定所述用户实例不存在故障；如果各种资源的使用都没有达到极限，则确定所述用户实例存在故障。

其中，所述故障判断模块还可以用于在确定所述用户实例存在故障后，如果该用户实例所在主机中仅该用户实例被确定为存在故障，则判断是该用户实例本身出现故障；如果该用户实例所在主机中，各用户实例都被确定为存在故障，则判断是该用户实例所在主机出现故障。

一种用于进行故障检测的电子设备，包括：存储器和处理器；

所述存储器用于保存用于进行故障检测的程序；所述用于进行故障检测的程序在被所述处理器读取执行时，执行如下操作：

本申请包括以下优点：

本申请至少一个实施例从资源使用角度出发进行故障检测，通过比较实际使用的资源量和所分配的资源量，能够从性能角度将故障和正常使用非故障导致的响应变慢区分开来，而不需要依赖日志或故障关键字来判断是否有故障，从而能够更准确的排查故障。

本申请实施例的至少一种实现方式中，能够先根据用户实例的请求统计数据筛选出待检测故障的用户实例，可以缩小检测故障的用户实例的范围，并可以及时发现可能存在故障的用户实例。

本申请实施例的至少一种实现方式中，给出了资源使用达到极限的具体判断方式，能够较为精确的检测出各种资源的使用是否达到极限。

本申请实施例的至少一种实现方式中，在确定一个用户实例存在故障后，可以结合同一个主机上各用户实例的故障确定情况，区分出是用户实例本身的故障，还是主机故障导致的用户实例故障。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

图1是现有技术中的故障检测系统的示意图；

图2是实施例一的故障检测方法的流程图；

图3是实施例一的例子中故障检测系统的示意图；

图4是实施例二的故障检测装置的示意图。

具体实施方式

下面将结合附图及实施例对本申请的技术方案进行更详细的说明。

需要说明的是，如果不冲突，本申请实施例以及实施例中的各个特征可以相互结合，均在本申请的保护范围之内。另外，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

在一种配置中，进行故障判断的计算设备可包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存(memory)。

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

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

实施例一、一种故障检测方法，如图2所示，包括步骤S110～S120。

S110、对于待检测故障的用户实例，获取所述用户实例的资源使用量及资源量上限；

S120、比较所述用户实例的资源使用量及资源量上限，根据比较结果确定所述用户实例是否存在故障。

本实施例中，可以将响应时间无故拉长(即：响应变慢)的用户实例作为待检测的用户实例；这里的“无故”只表示从表面上看没有明显的原因(比如用户实例的请求量并无显著增长)能使响应时间拉长；而实际上响应时间拉长必然是某个缘故导致的，比如故障(包含主机故障、用户实例本身故障等情况)，或正常使用非故障导致的拉长等。

本实施例从资源使用角度出发进行故障检测，通过比较实际使用的资源量和所分配的资源量(即资源量上限)，能够从性能角度将故障和正常使用非故障(比如资源使用量达到分配资源量的极限)导致的响应变慢区分开来。

本实施例中，导致用户实例存在故障的原因可以包括：用户实例本身出现了故障、和/或，用户实例所在主机出现故障。

本实施例可以适用于资源隔离的场景。在云计算系统下，多个用户实例可能分配在一台物理主机上，那么多个用户实例将共享主机的资源，包括：中央处理器(CentralProcessing Unit，CPU)、内存、磁盘、网络带宽等。为了避免用户实例间互相影响，通常使用虚拟化，cgroup软件等软件方法对用户实例进行资源隔离，通过对阈值或资源分配比例的限定和配置，可以使得单个用户实例对资源的使用量不会超过分配给它的资源量。

在资源隔离的场景下，可以获取到分配给用户实例的资源量(即资源量上限)，和用户实例实际使用的资源量(即资源使用量)进行比较，就可以得知待检测故障的用户实例是因为资源使用量达到极限，还是因为故障而导致响应变慢。

本实施例中，用户实例的资源量上限可以但不限于通过用户实例的规格获知。通常用户购买了云计算服务后，会指定购买的用户实例的规格，规格中通常包含了购买的资源量，包括CPU、内存、磁盘每秒输入输出量(Input Output per second，iops)等资源；云计算系统在给用户做资源隔离时，就按照用户购买的实例规格分配相应的资源量。

本实施例中，可以由主机上运行的程序进行步骤S110～S120，也可以只由主机上运行的程序进行步骤S110，由另外的设备来执行步骤S120。当然，也不排除其它实现方式，比如由主机之外的旁路系统检测用户实例的资源使用量及资源量上限，但主机本身进行步骤S110更加及时和可靠。

一种实现方式中，可以分别获取用户实例的资源使用量和资源量上限，然后进行比较，得到比较结果。

一种实现方式中，可以在获取用户实例的资源使用量和资源量上限时就得到比较结果，比如直接采集所使用资源在资源量上限中所占的比例，假设用户实例的上限是100M内存，如果该用户实例使用了70M，则采集结果为70％；该情况下，采集结果就是比较结果，可以直接根据采集结果确定是否存在故障。

一种实现方式中，资源可以但不限于包括以下一或多种：

CPU、内存(Mem)、磁盘、网络。

相应地，资源使用量可以包括以下一种或多种：

CPU核数、内存大小、磁盘iops、磁盘带宽(单位MB/s)、网络带宽(单位MB/s)。

相应地，资源量上限可以包括以下一种或多种：

CPU核数上限、内存上限、iops上限、磁盘带宽上限(单位MB/s)、网络带宽上限(单位MB/s)。

本实现方式中，比较结果包含多种资源的比较结果；某种资源的比较结果是用户实例对该种资源的资源使用量和用户实例该种资源的资源量上限之间的比较结果。

本实现方式中，所述获取用户实例的资源使用量可以包括：

当资源是CPU或内存时，获取瞬时使用量作为资源使用量；

当资源是iops、磁盘带宽、网络带宽时，获取一个周期中的累计使用量，除以周期的长度后作为资源使用量。

其它实现方式中，还可以根据实际情况包含其它种类的资源。

一种实现方式中，所述步骤S110前还可以包括：

周期性获取各用户实例的请求统计数据；

本实现方式中，请求统计数据可以包括每秒查询率(Queries Per Second，QPS)、每秒事务处理量(Transaction Per Second，TPS)和响应时间(Reaction Time，RT)。

本实现方式中，所述分别根据各用户实例的请求统计数据，判断各用户实例是否为待检测故障的用户实例可以包括：

也就是说，如果某个用户实例在TPS和QPS没有明显增加的情况下，RT却明显增加，则可以将该用户实例作为待检测故障的用户实例。

其中，增长率可以等于本周期的值减去上一周期的值，然后除以上一周期的值；以TPS为例，增长率为：

(TPS_Pi－TPS_Pi－1)/TPS_Pi－1；其中，TPS_Pi是指本周期的TPS，TPS_Pi－1是指上一周期的TPS。

QPS、RT的情况可以类推。

本实现方式中，上文所说的“响应时间无故拉长”可以是指当用户实例的每秒查询率(Queries Per Second，QPS)、每秒事务处理量(Transaction Per Second，TPS)没有明显增长(包括下降)的情况下，每次请求的响应时间明显变长。

其它实现方式中，也可以不通过上述请求统计数据来确定待检测故障的用户实例，比如通过对主机的负载量、网络流量、用户实例的数量等指标来确定主机上的用户实例是否为待检测故障的用户实例，或者根据用户的故障检测请求将相应的用户实例作为待检测故障的用户实例；还可以不加以区分，将所有用户实例都作为待检测故障的用户实例。

一种实现方式中，所述获取用户实例的资源使用量可以包括：

其中，上述的各种资源可以是指用户实例所具有的、在步骤S110中获取了使用量和上限的一种或多种资源。

本实现方式中，在T个时间点所采集的资源使用量可以但不限于用序列的方式标识，各种资源各对应一个序列。

本实现方式中，采集资源使用量时，对于CPU和内存，采集的可以是瞬时值；对于iops、磁盘带宽和网络带宽，采集的可以是一段时间内的累计使用量，除以该段时间的长度后得到资源使用量。

其它实现方式中，可以不将各种资源分开同时进行比较，可以先比较一种最可能影响响应时间的资源，当该种资源的使用量没有接近资源量上限时，再比较下一可能影响响应时间的资源。

本实现方式中，所述根据各种资源的T个比较结果确定是否存在故障可以包括：

本实现方式中，比较的方式可以但不限于是用所采集的资源使用量除以资源量上限，相应地，预定条件可以是资源使用量除以资源量上限得到的商大于预定比例阈值；其中，预定比例阈值的取值范围可以是0～1。

本实现方式中，比较结果满足预定条件的情况可以是资源使用量已经逼近资源量上限的情况，如果在所述预定长度的时间段中，对于某种资源超过N次出现资源使用量接近资源量上限的情况，则表示该用户实例对该种资源的使用已经达到极限，并很可能是因此而导致的响应时间拉长；当有一种或一种以上的资源使用达到极限时，可以暂时确定不存在故障，还可以及时通知用户升级用户实例的规格。

本实现方式中，N的值可以根据经验或实验自行设置。T的值可以根据系统可以承受的采集频率及时间段的长度来确定，比如一秒采集一次，如果时间段的长度为10秒，则T＝10。

通常，由于底层硬件故障，比如驱动或者磁盘阵列(Redundant Arrays ofIndependent Disks，Raid)卡等出产厂商不同，技术标准不完全一致，特别是当硬件已经发生故障时，操作系统对这些故障的日志打印无法做到全面，及时和准确，因此日志采集程序无法做到全面收集故障；而且日志过滤、分析程序对故障关键字的设置也是影响故障检测效果的重要因素，由于不同厂商的产品千差万别，软件人员一般无法覆盖日志中可能出现的所有故障信息，只能等待真实故障出现时，再补充新的故障关键字，存在滞后性。

而本实现方式中，则可以从资源使用量的角度及时、全面发现故障。

其它实现方式中，可以不采集T个资源使用量，而是只采集一次进行比较，一旦发现接近资源量上限，就认为使用达到极限。

一种实现方式中，所述根据比较结果确定所述用户实例是否存在故障后还可以包括：

本实现方式中，如果发现是主机故障，可以及时进行故障主机切换，并通知运维人员及时下线该主机。

其它实现方式中，还可以结合图1中的日志分析、过滤结果一起进行判断；如果数据存储设备中包含主机的故障数据，且用户实例对各种资源的使用都没有达到极限，则可以判断出有较大概率是该用户实例所在主机出现故障；如果无故障信息，且用户实例有至少一种资源的使用达到极限，则可以认为用户实例响应变慢是由于使用量达到瓶颈导致，主机是可以正常使用的。

下面通过一个例子说明本实施例。

本例子中进行故障检测的系统如图3所示，主机上包括多个隔离单元，用于对该主机上的不同用户实例进行资源隔离，避免使用时互相争抢资源；资源隔离是指：分别给每个用户实例按照该用户实例的规格分配定量的主机资源。对用户实例进行资源隔离后，用户实例内的进程使用的资源都不会超过分配给其资源量的最大上限。

在主机上部署性能数据采集程序，可以对每个用户实例分别采集两种类型的性能数据：一种是资源使用量，另一种是请求统计数据。

在采集资源使用量时，可以对每个用户实例实际使用的资源量分别在多个时间点进行采集，得到资源使用量；本例中，根据资源的不同，采集方式包括以下两种：

(1)CPU、内存是采集瞬时值，即在某个时刻，采集用户实例的CPU及内存使用量作为资源使用量，资源使用量会随着时间不断上下变化。

(2)磁盘iops、磁盘带宽、网络带宽是采集一段时间内的累计使用量，该累计使用量会随着时间而不断上涨，一般使用平均到每秒的累计使用量作为资源使用量，以衡量一段时间内实际使用的资源量的高低。通过所采集的累计使用量，除以两次采集之间的时间间隔长度，可以计算出资源使用量；每次采集后将累计使用量清零。

比如：iops(单位：次数每秒)＝一段时间内累计产生的磁盘io数量(单位：次)/该段时间的长度(单位：秒)。

所采集的请求统计数据可以包括QPS、TPS(对于数据库而言)，以及平均每次请求的RT；根据请求统计数据可以发现可能有故障的用户实例，可以只针对这部分用户实例进行下文的故障检测计算，即：将可能有故障的用户实例作为待检测故障的用户实例。

通过分析待检测故障的用户实例的资源使用量和分配的资源量，即可检测出该用户实例的故障情况，过程包括如下步骤201～203：

201、分别获取主机上每个待检测故障的用户实例的资源隔离数据，即分配给用户实例的资源量，包括：CPU核数，内存上限，iops上限，磁盘带宽，网络带宽，分别保存为参数Cpu_top、Mem_top、iops_top、DBPS_top、NBPS_top。

202、分别获取T1到T2这个时间段内上述用户实例的资源使用量，用户实例所使用的各种资源量分别是一个与采集时间点对应的序列，以CPU为例，假设T1到T2这个时间段内有10个采集时间点为t1、t2、t3……t10，则CPU的使用量为如下序列：Cpu_t1，Cpu_t2，Cpu_t3，……，Cpu_t10。

其中，Cpu_ti(1≤i≤10)是在ti这个时间点采集的CPU使用量。

内存的使用量以此类推。

对于磁盘iops、磁盘带宽、网络带宽，则序列中的每个数值表示在该时间点所计算出的使用量。

以磁盘iops为例，使用量为如下序列：

iops_t1，iops_t2，iops_t3，……，iops_t10。

其中，iops_t1是在t1这个时间点计算出的使用量，等于从T1到t1这段时间内累计产生的磁盘io数量除以T1到t1的时间间隔长度。

磁盘带宽、网络带宽以此类推。

故障持续时间的长度转化为时间点个数N，含义为T1到T2时间段内，如果时间点ti对应使用量的超过资源隔离分配值的指标累计超过N次，即判定为该用户实例的该指标使用达到极限。

以资源是CPU为例，时间点ti的使用量Cpu_ti与资源隔离的指标Cpu_top的比例如果超过阀值threshold(取值区间可以为[0,1])的次数如果大于N，以数学方式表达即：下式如果成立，则认为CPU的使用达到极限。

203、当一个用户实例的CPU、Mem、iops、DBPS、NBPS都没有达到极限，而此时该用户实例所在主机中，只有该用户实例的所有请求的响应时间无故拉长且各种资源的使用都未达到极限，那么即可判定为该用户实例存在故障。

如果一个用户实例的至少一种资源达到极限，则说明是用户实例规格不够导致的响应时间拉长，可以告知用户升级用户实例的规格。

当主机中各用户实例的请求响应时间都无故拉长(可以排除掉没有请求的用户实例)且各用户实例的各种资源的使用都未达到极限，那么即可判断为该主机故障。

本例中的上述方案可以和现有解决方案中基于日志过滤故障数据的方案并存，如图3所示，可以将上述判断结果作为故障数据，和日志过滤、分析程序得到的故障数据都放入数据存储设备，对外提供故障数据访问接口。

实施例二、一种故障检测装置，如图4所示，包括：

检测模块21，用于对于待检测故障的用户实例，获取所述用户实例的资源使用量及资源量上限；

故障判断模块22，用于比较所述用户实例的资源使用量及资源量上限，根据比较结果确定所述用户实例是否存在故障。

本实施例中，检测模块21是上述装置中负责获取用户实例资源量上限及使用量的部分，可以是软件、硬件或两者的结合。

本实施例中，故障判断模块22是上述装置中负责判断用户实例是否存在故障的部分，可以是软件、硬件或两者的结合。

一种实现方式中，所述资源可以包括以下一或多种：

中央处理器CPU、内存、磁盘、网络；

所述资源使用量可以包括以下一种或多种：

相应地，所述资源量上限可以包括以下一种或多种：

一种实现方式中，所述故障检测装置还可以包括：

本实现方式中，所述请求统计数据可以包括：每秒查询率QPS、每秒事务处理量TPS和响应时间RT；

一种实现方式中，所述检测模块获取用户实例的资源使用量可以包括：

本实现方式中，所述故障判断模块根据各种资源的T个比较结果确定所述用户实例是否存在故障可以包括：

一种实现方式中，所述故障判断模块还用于在确定所述用户实例存在故障后，如果该用户实例所在主机中仅该用户实例被确定为存在故障，则判断是该用户实例本身出现故障；如果该用户实例所在主机中，各用户实例都被确定为存在故障，则判断是该用户实例所在主机出现故障。

本实施例的故障检测装置的各模块的操作分别对应于实施例一中的步骤S110～S120，各模块操作的其它实现细节可参见实施例一。

实施例三、一种用于进行故障检测的电子设备，包括：存储器和处理器；

本实施例中，用于进行故障检测的程序在被处理器读取执行时，所执行的操作对应于实施例一中的步骤S110～S120；该程序所执行的操作的其它细节可参见实施例一。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本申请不限制于任何特定形式的硬件和软件的结合。

当然，本申请还可有其他多种实施例，在不背离本申请精神及其实质的情况下，熟悉本领域的技术人员当可根据本申请作出各种相应的改变和变形，但这些相应的改变和变形都应属于本申请的权利要求的保护范围。

Claims

1.一种故障检测方法，包括：

对于云计算系统中的待检测故障的用户实例，获取所述用户实例的资源使用量及资源量上限；

比较所述用户实例的资源使用量及资源量上限，根据比较结果确定所述用户实例是否存在故障；

如果各种资源的使用都没有达到极限，则确定所述用户实例存在故障；如果存在至少一种资源的使用达到极限，则确定所述用户实例不存在故障。

2.如权利要求1所述的故障检测方法，其特征在于，所述资源包括以下一或多种：

中央处理器CPU、内存、磁盘、网络；

所述资源使用量包括以下一种或多种：

相应地，所述资源量上限包括以下一种或多种：

3.如权利要求1所述的故障检测方法，其特征在于，所述对于待检测故障的用户实例，获取所述用户实例的资源使用量及资源量上限前还包括：

周期性获取各用户实例的请求统计数据；

4.如权利要求3所述的故障检测方法，其特征在于，所述请求统计数据包括：每秒查询率QPS、每秒事务处理量TPS和响应时间RT；

所述分别根据各用户实例的请求统计数据，判断各用户实例是否为待检测故障的用户实例包括：

5.如权利要求1所述的故障检测方法，其特征在于，所述获取用户实例的资源使用量包括：

所述比较用户实例的资源使用量及资源量上限，根据比较结果确定所述用户实例是否存在故障包括：

6.如权利要求5所述的故障检测方法，其特征在于，所述根据各种资源的T个比较结果确定所述用户实例是否存在故障包括：

如果一种资源的T个比较结果中有N个比较结果满足预定条件，则确定该种资源的使用达到极限；其中，N是小于T的正整数。

7.如权利要求1所述的故障检测方法，其特征在于，所述根据比较结果确定所述用户实例是否存在故障后还包括：

8.一种故障检测装置，其特征在于，包括：

检测模块，用于对于云计算系统中的待检测故障的用户实例，获取所述用户实例的资源使用量及资源量上限；

故障判断模块，用于比较所述用户实例的资源使用量及资源量上限，根据比较结果确定所述用户实例是否存在故障；如果各种资源的使用都没有达到极限，则确定所述用户实例存在故障；如果存在至少一种资源的使用达到极限，则确定所述用户实例不存在故障。

9.如权利要求8所述的故障检测装置，其特征在于，所述资源包括以下一或多种：

中央处理器CPU、内存、磁盘、网络；

所述资源使用量包括以下一种或多种：

相应地，所述资源量上限包括以下一种或多种：

10.如权利要求8所述的故障检测装置，其特征在于，还包括：

11.如权利要求10所述的故障检测装置，其特征在于，所述请求统计数据包括：每秒查询率QPS、每秒事务处理量TPS和响应时间RT；

所述选择模块分别根据各用户实例的请求统计数据，判断各用户实例是否为待检测故障的用户实例包括：

12.如权利要求8所述的故障检测装置，其特征在于，所述检测模块获取用户实例的资源使用量包括：

所述故障判断模块比较所述用户实例的资源使用量及资源量上限，根据比较结果确定所述用户实例是否存在故障包括：

13.如权利要求12所述的故障检测装置，其特征在于，所述故障判断模块根据各种资源的T个比较结果确定所述用户实例是否存在故障包括：

所述故障判断模块当一种资源的T个比较结果中有N个比较结果满足预定条件时，确定该种资源的使用达到极限；其中，N是小于T的正整数。

14.如权利要求8所述的故障检测装置，其特征在于：

所述故障判断模块还用于在确定所述用户实例存在故障后，如果该用户实例所在主机中仅该用户实例被确定为存在故障，则判断是该用户实例本身出现故障；如果该用户实例所在主机中，各用户实例都被确定为存在故障，则判断是该用户实例所在主机出现故障。

15.一种用于进行故障检测的电子设备，包括：存储器和处理器；

其特征在于：

比较所述用户实例的资源使用量及资源量上限，根据比较结果确定所述用户实例是否存在故障；如果各种资源的使用都没有达到极限，则确定所述用户实例存在故障；如果存在至少一种资源的使用达到极限，则确定所述用户实例不存在故障。