具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
为解决现有方式无法确定出系统耗时出现异常的原因的问题,本说明书实施例提供一种确定系统耗时异常的方法。本说明书实施例提供的确定系统耗时异常的方法的执行主体包括但不限于服务器、个人电脑等能够被配置为执行本发明实施例提供的该方法的终端中的至少一种。
图1是本说明书的一个实施例提供的确定系统耗时异常的方法的流程图。
如图1所示,在步骤102处,确定目标时段内目标场景对应的系统耗时是否存在异常;如果存在异常,则执行下述步骤104,否则,结束本流程或者对另一个目标时段执行步骤102。
目标时段可以是任意连续的时段,且目标时段的长度可以根据实际需要进行设置。在一个例子中,目标时段的长度可以等于确定系统耗时异常的检测周期,例如,假如当前时间是5:00,确定系统耗时异常的检测周期为1分钟,那么目标时段可以是5:00至5:01这一时间段。
系统耗时是从系统接收到业务处理请求开始到对该请求作出完整响应的时长。
由于系统处理业务请求的过程也是系统调用系统内部的功能模块(或称为节点)的过程,因此系统耗时也可以称为是系统调用耗时。相应的,接收并完整响应一次业务处理请求,对应一次完整的调用,也即,调用可以理解为是系统为了完整响应一次业务处理请求而调用系统中的节点的过程。
场景是预先基于业务类型确定的,不同的业务类型对应不同的场景,例如,假设本说明书中所说的系统为第三方支付平台,付款和收款可以视为两种不同的业务类型,对应两种不同的场景。
由于一种类型的关键输入参数组合通常代表一种业务类型,因此,场景也可以是预先基于输入参数组合的类型确定的,且不同的关键输入参数组合对应不同的场景。在实际应用中,不同的调用的关键输入参数可能相同,因此,一个场景也可以理解为是对关键输入参数相同的一组调用(或请求)的描写。例如,关键输入参数为A和B的调用可以代表一种场景,关键输入参数为C和D的调用可以代表另一种场景。
目标场景可以是预先确定出的场景中的一个或多个,本说明书对此不做限定。
确定目标时段内目标场景对应的系统耗时是否存在异常的方式可以有多种,例如,在一个例子中,可以通过判断目标时段内目标场景的对应的预设系统耗时参数是否满足预设条件来确定,其中,预设系统耗时参数可以是调用的平均耗时和最长耗时等等。具体如,假如目标时段为2018年5月17日下午5:00至5:01,那么可以通过判断这1分钟内目标场景对应的调用的平均耗时是否超过预设阈值,和/或通过判断这1分钟内目标场景对应的调用的最长耗时是否超过预设阈值,来确定这1分钟内目标场景对应的系统耗时是否存在异常。下文中会通过一个具体的实施例说明确定目标时段内目标场景对应的系统耗时是否存在异常的另一种方式,详见下文,此处暂不赘述。
在步骤104处,确定所述目标时段内所述目标场景对应的参考调用实例。
调用实例(可以简称为实例),用于描写具有相同或相似实例结构的一类调用或一组调用,其中,实例结构可以用输入参数、输出参数和内部调用结构表征,且在一个例子中,对于实例结构相同的调用,他们具有相同的输入参数、相同的输出参数和相同的内部调用结构。以及,一个调用可以对应转化成对应的一个调用实例。
由于所述目标场景在目标时段内可能存在多个调用实例,因此,在一个例子中,可以从这多个调用实例中任选一个调用实例作为上述参考调用实例;在另一个例子中,为了快速地确定出所述目标时段内所述系统的内部节点中系统耗时存在异常的节点,可以将所述目标时段内所述目标场景对应的调用实例中系统耗时最长的调用实例确定为所述参考调用实例。
在步骤106处、基于所述参考调用实例在所述目标时段内调用系统的内部节点的系统耗时,以及历史调用实例在历史上调用所述系统的内部节点的系统耗时,在所述系统的内部节点中确定所述目标时段内的系统耗时异常节点。
其中,所述历史调用实例与所述参考调用实例的实例结构相同或相似。关于实例结构的解释说明请参见步骤104,此处不再重复描述。
可选地,在所述系统的内部节点中确定所述目标时段内的系统耗时异常节点之前,也即在步骤106之前,图1所示的方法还可以包括:基于所述目标时段内所述目标场景对应的系统耗时信息,确定所述参考调用实例对应的调用的标识;基于所述标识,从第一预设数据库中查询获得所述参考调用实例对应的调用的详情;基于所述详情,确定所述参考调用实例的实例结构;基于所述参考调用实例的实例结构,从所述第一预设数据库中查询获得所述历史调用实例。
作为一个例子,步骤106中的历史调用实例可以是,与所述参考调用实例的实例结构相同或相似的历史调用实例中,发生时刻与所述目标时段最接近的历史调用实例。当然,步骤106中的历史调用实例还可以是与参考调用实例的实例结构相同或相似的其他历史调用实例,本说明书对此不做限定。
由于在SOA中,Hbase数据库常被用于存储调用的详情,因此,在一个例子中,上述第一预设数据库可以是Hbase数据库。
在此基础上,如果步骤102中确定出目标时段内目标场景对应的系统耗时存在异常,则可以在确定出参考调用实例之后,进一步地通过查询Hbase数据库确定出该参考调用实例对应的调用(为了方便描述,称为参考调用)的标识(ID),再依据查询到的参考调用的ID从Hbase数据库中查询获得参考调用的详情,该详情包括参考调用的内部调用结构和调用系统内部节点的系统耗时情况,根据该详情可以确定出参考调用实例的实例结构,具体如确定出参考调用的实例结构消息摘要算法第五版(Message Digest Algorithm,MD5),一个实例结构MD5可以确定一个调用实例;依据参考调用实例的实例结构MD5从Hbase数据库中查询获得与参考调用实例的实例结构相同或相似的历史调用实例,且在一个例子中,该历史调用实例的发生时刻与目标时段最接近。基于上述过程,便得到了来自目标时段的和来自历史时段的两个实例结构相同或相似的调用实例。
作为一个例子,步骤106具体可以包括:确定所述参考调用实例在所述目标时段内调用系统的内部节点的系统耗时,相对于历史调用实例在历史上调用所述系统的内部节点的系统耗时的增长幅度;基于所述增长幅度,确定所述系统的内部节点在所述目标时段内的异常级别;基于所述异常级别,在所述系统的内部节点中确定所述目标时段内的系统耗时异常节点。
例如,可以按照一一对比的方式,对比确定出参考调用实例中调用的系统内部节点,与历史调用实例中调用的相应系统内部节点的系统耗时增长值。然后,按照增长值的增长幅度,对被参考调用实例调用的系统内部节点进行异常级别的评级,例如可以按照增长幅度由低到高的顺序,对应确定出INFO、WARN、CRITICAL三个级别;最后依据确定出的异常级别,在所述系统的内部节点中确定所述目标时段内的系统耗时异常节点,例如将所述系统的内部节点中异常级别为CRITICAL的节点确定为异常节点。不难理解,确定出目标时段内所述系统内部节点中的异常节点,相当于找到了系统耗时出现异常的原因。
可选地,在确定出所述系统的内部节点在所述目标时段内的异常级别之后,本说明书提供的一种确定系统耗时异常的方法,还可以包括:基于预先确定的异常级别与展示方式的对应关系,展示所述参考调用实例内部节点的异常级别。
例如,可以基于预先确定的异常级别与展示颜色的对应关系,使用不同的颜色展示不同异常级别的节点。具体如图2所示,假如参考调用实例调用了系统内部节点1、节点2、节点3和节点4,且调用节点1至节点5的系统耗时以此为:50.00ms、1036.00ms、1016.00ms和1016.00ms,其中,调用节点2至节点4的系统耗时较长,且调用节点2的系统耗时大于节点3和节点4,则可以将节点1的异常级别确定为初级、将节点3和节点4的异常级别确定为中级,将节点2的异常级别确定为高级,然后按照异常级别的高低对节点1至节点4的耗时进行显示。由于无法显示彩色,在图2中通过颜色的深浅程度示例性显示异常级别,例如节点1的异常级别最低,对应的显示颜色最浅;节点2的异常级别最高,对应的显示颜色最深,节点3和节点4的异常级别介于最低和最高之间,对应的显示颜色的深浅程度介于最浅和最深之间。在图2中,还显示了调用不同节点的延迟和成功率。
这样,可以让系统维护人员直观地看到目标时段内系统耗时的增长具体是由哪些系统内部节点的耗时增长引起的,例如是调用中间件或下由系统的节点引起的,进而快速、直观地发现出现耗时异常的原因。
本说明书图1所示的实施例提供的一种确定系统耗时异常的方法,由于在确定出目标时段内目标场景对应的系统耗时存在异常的基础上,能够进一步地,基于目标时段内目标场景对应的参考调用实例在所述目标时段内调用系统的内部节点的系统耗时,以及历史调用实例在历史上调用所述系统的内部节点的系统耗时,确定出目标时段内所述系统内的系统耗时异常节点,因此,可以确定出目标时段内系统耗时出现异常的原因,能够帮助系统维护人员快速定位出故障,提高了系统维护效率。
可选地,在图1所示的实施例的基础上,本说明书提供的一种确定系统耗时异常的方法,还可以包括:保存目标时段内所述系统耗时异常节点的信息,以供系统维护人员在后期的维护过程中进行查阅。
可选地,在另一实施例中,如图3所示,上述步骤102具体可以包括:基于所述目标时段内所述目标场景对应的预设系统耗时参数,以及预设历史时段内所述目标场景对应的预设系统耗时参数,确定所述目标时段内所述目标场景对应的系统耗时是否存在异常。
其中,预设系统耗时参数可以包括:调用的平均耗时和调用的最长耗时。
可以理解,为了获得目标时段内和预设历史时段内目标场景对应的系统耗时参数,可能需要事先将这些时段内的与目标场景对应的系统耗时信息存储下来,例如按检测周期将各检测周期内的调用的次数、各检测周期内调用的总耗时、各检测周期内调用的最长耗时以及最长耗时对应的调用的标识,等等信息存储下来。
由于在实际应用中,一个系统的访问量可能非常大,导致产生的调用(或业务处理请求)的数量也非常大,相应的产生的与这些调用相关的系统耗时信息量也很大,将与这些调用相关的系统耗时信息存储在同一存储空间的不太现实,因此,可以将与这些调用相关的系统耗时信息按一定的规则存储在不同的分区,例如,在SOA中,与这些调用相关的系统耗时信息可能存储在Hbase数据库的不同分区。
下面结合图4对从Hbase数据库中统计获得各检测周期内不同场景对应的系统耗时信息的过程进行说明,且检测周期为1分钟。
如图4所示,可以按照时间自然推移的顺序,由一中间件按检测周期采集获得该检测周期内的调用的系统耗时详情日志,并按行键(rowkey)随机写入第一数据库305(可以是Hbase数据库)的不同分区,系统耗时详情日志可以包括调用的根节点和各个内部子结点的耗时情况。定时任务1分钟发送一次信号到主服务器301(Master),主服务器301接收到信号后,将第一数据库305的分区查询任务分发到分区映射服务器(Mapper),例如,假设第一数据库305存在3个分区,且分别映射至第一分区映射服务器302、第二分区映射服务器303和第三分区映射服务器304,保证第一数据库305的各个分区都会有Mapper去查询,且一个分区对应一台Mapper。
Mapper接收到分区查询任务后,查询第一数据库305对应分区的数据,并将单次的调用转换成调用实例,并对实例结构相同的调用实例进行第一层聚合,得出第一数据库305的各分区中不同实例结构的调用实例的系统总耗时、调用次数、单次调用的最长耗时以及最长耗时的单次调用的ID。
Mapper聚合完成后,使用上文中所述的实例结构的MD5作为哈希主键,将Mapper聚合得到的第一层聚合结果(中间结果)分别发送到对应的下一层聚合服务器(Reducer),例如第一聚合服务器306和第二聚合服务器307,一种MD5对应一个Reducer,这样,可以将具有相同实例结构的第一层聚合结果聚合到一台Reducer服务器上,得到第一数据库305中不同实例结构的调用实例的系统总耗时、调用的次数、单次调用的最长耗时以及最长耗时的单次调用的ID,我们可以将Reducer聚合得到的结果称为第二层聚合结果。
Reducer聚合完成后,将第二层聚合结果汇总到第三聚合服务器308(Detector)中。根据上文中的描述可知,具有相同或相似实例结构的一类调用或一组调用可以称为一种调用实例,具有相同关键输入参数的一类调用或一组调用可以称为一个场景。因此,在Reducer中可以将具有相同关键输入参数的调用实例划分到同一场景中,或者说,一个调用实例可以对应划分至一个场景中。进而,在Detector中可以进行第三层聚合,得到第一数据库305中不同场景对应的调用实例的系统总耗时、调用的次数、单次调用的最长耗时以及最长耗时的单次调用的ID等信息。
并且可以将该检测周期内不同场景对应的调用实例的系统总耗时、调用的次数、单次调用的最长耗时以及最长耗时的单次调用的ID等信息存储在第二数据库中(例如分布式缓存),以便于查询获得目标时段内所述目标场景对应的预设系统耗时参数和预设历史时段内目标场景对应的预设系统耗时参数。
并且按照时间自然推移的顺序将各检测周期内的不同场景对应的预设系统耗时参数保存至第二数据库,可以保证第二数据库中存储的历史时段对应的预设系统耗时参数随时处于动态更新状态。
并且可以理解,预设系统耗时参数中的调用的平均耗时,可以通过第二数据库中存储的是调用实例的系统总耗时、调用的次数计算得到。
在此基础上,可选地,如图3所示,本说明书提供的一种确定系统耗时异常的方法,在步骤102之前,也即在确定目标时段内目标场景对应的系统耗时是否存在异常之前,还可以包括:
步骤108、基于拉依达准则,过滤所述预设历史时段内所述目标场景对应的预设系统耗时参数中的异常参数。
也就是说,在从第二数据库中查询获得预设历史时段内目标场景对应的预设系统耗时参数后,可以基于拉依达准则,过滤所述预设历史时段内所述目标场景对应的预设系统耗时参数中的异常参数,将预设历史时段内目标场景对应的正常预设系统好事参数,与目标时段内目标场景对应的预设系统耗时参数进行比较,以提高确定出的所述目标时段内所述目标场景对应的系统耗时是否存在异常的准确性。
拉依达准则也称3sigma准则,该准则的基本原理是:假设一组检测数据只含有随机误差,对其进行计算处理得到标准差,按一定概率确定一个区间,认为凡超过这个区间的误差不属于正常的随机误差。
具体来说,可以计算得到预设历史时段内各检测周期内所述目标场景对应的预设系统耗时参数的标准差,然后按一定的概率确定一个区间,判断预设历史时段内所述目标场景对应的各预设系统耗时参数的误差是否在该区间内,如果不在,则过滤该预设系统耗时参数。例如,假设预设历史时段为4:30至5:00这30分钟,检测周期为1分钟,则可以计算这30分钟对应的30个预设系统耗时参数的标准差,然后按一定的概率确定一个区间,计算这30分钟内每一分钟对应的预设系统耗时参数的误差,并判断是否在该区间内,如不在,则过滤。
作为一个例子,如图5所示,图3中的步骤102具体可以包括如下子步骤:
子步骤501、基于所述目标时段内所述目标场景对应的预设系统耗时参数,以及所述预设历史时段内所述目标场景对应的预设系统耗时参数,确定所述目标时段内所述目标场景对应的预设系统耗时参数的波动值。
在一个例子中,子步骤501具体可以包括:确定所述预设历史时段内所述目标场景对应的所述预设系统耗时参数的平均值和标准差;基于所述平均值和所述标准差,确定所述目标时段内所述目标场景对应的所述预设系统耗时参数的标准分数;将所述标准分数确定为所述波动值。
例如,假设预设历史时段为4:30至5:00这30分钟,检测周期为1分钟,则可以计算这30分钟对应的30个预设系统耗时参数的平均值μ和标准差σ;然后利用下式计算所述目标时段内所述目标场景对应的所述预设系统耗时参数的标准分数(Zsore):
z=(x-μ)/σ
其中,z为标准分数(Zsore),x为所述目标时段内所述目标场景对应的所述预设系统耗时参数。
并且,在预设系统耗时参数为单次调用的平均耗时,x即为目标时段内单次调用的平均耗时;在预设系统耗时参数为单次调用的最长耗时,x即为目标时段内单次调用的最长耗时。
子步骤503、基于拉依达准则和所述预设历史时段内所述目标场景对应的预设系统耗时参数,确定所述波动值的阈值区间。
子步骤505、基于所述波动值和所述阈值区间,确定所述目标时段内所述目标场景对应的系统耗时是否存在异常。
更为具体的,如果所述波动值落在所述阈值区间内,则确定所述目标时段内所述目标场景对应的系统耗时不存在异常,否则确定所述目标时段内所述目标场景对应的系统耗时存在异常。
在图2所示的实施例中,除了能够确定出目标时段内系统耗时出现异常的原因外,由于是基于历史时段的预设系统耗时参数,动态地确定系统耗时的异常情况,因此,能够提高系统耗时异常检测结果的准确性。
此外,在图1和图3所示的实施例提供的一种确定系统耗时异常的方法中,是从场景这一更加精细化的角度出发,确定目标时段内系统耗时是否存在异常,以及确定系统耗时存在异常的系统内部节点,因此,可以进一步地提高系统耗时异常检测结果的准确性,以及提高确定系统耗时存在异常的系统内部节点的准确性。
总的来说,图3所示的实施例,提供了一套完整系统耗时异常监测和系统耗时异常节点定位方法。相比于现有的采用固定阈值判断系统耗时是否存在异常的方法,本说明书提供的一种确定系统耗时异常的方法,一方面可以利用历史时段的系统耗时信息和拉依达准则确定出随时间的变化的动态阈值,解决了现有的方式在固定阈值过低时,系统耗时异常报警过于频繁,以及在固定阈值过高时,系统耗时异常报警不够敏感的问题。另一方面,还可以在确定出系统耗时存在异常之后,对比所述参考调用实例在所述目标时段内调用系统的内部节点的系统耗时,与历史调用实例在历史上调用所述系统的内部节点的系统耗时,在所述系统的内部节点中确定所述目标时段内的系统耗时异常节点,因此能够定位出目标时段内系统耗时存在异常的原因。
图6是本说明书的一个实施例提供的电子设备的结构示意图。请参考图6,在硬件层面,该电子设备包括处理器,可选地还包括内部总线、网络接口、存储器。其中,存储器可能包含内存,例如高速随机存取存储器(Random-Access Memory,RAM),也可能还包括非易失性存储器(non-volatile memory),例如至少1个磁盘存储器等。当然,该电子设备还可能包括其他业务所需要的硬件。
处理器、网络接口和存储器可以通过内部总线相互连接,该内部总线可以是ISA(Industry Standard Architecture,工业标准体系结构)总线、PCI(PeripheralComponent Interconnect,外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture,扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图6中仅用一个双向箭头表示,但并不表示仅有一根总线或一种类型的总线。
存储器,用于存放程序。具体地,程序可以包括程序代码,所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器,并向处理器提供指令和数据。
处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行,在逻辑层面上形成确定系统耗时异常的装置。处理器,执行存储器所存放的程序,并具体用于执行以下操作:
确定目标时段内目标场景对应的系统耗时是否存在异常;
如果存在异常,确定所述目标时段内所述目标场景对应的参考调用实例;
基于所述参考调用实例在所述目标时段内调用系统的内部节点的系统耗时,以及历史调用实例在历史上调用所述系统的内部节点的系统耗时,在所述系统的内部节点中确定所述目标时段内的系统耗时异常节点,其中,所述历史调用实例与所述参考调用实例的实例结构相同或相似。
上述如本说明书图1所示实施例揭示的确定系统耗时异常的方法可以应用于处理器中,或者由处理器实现。处理器可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(Digital SignalProcessor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本说明书一个或多个实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本说明书一个或多个实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。
该电子设备还可执行图1的确定系统耗时异常的方法,本说明书在此不再赘述。
当然,除了软件实现方式之外,本说明书的电子设备并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
本说明书实施例还提出了一种计算机可读存储介质,该计算机可读存储介质存储一个或多个程序,该一个或多个程序包括指令,该指令当被包括多个应用程序的便携式电子设备执行时,能够使该便携式电子设备执行图1所示实施例的方法,并具体用于执行以下操作:
确定目标时段内目标场景对应的系统耗时是否存在异常;
如果存在异常,确定所述目标时段内所述目标场景对应的参考调用实例;
基于所述参考调用实例在所述目标时段内调用系统的内部节点的系统耗时,以及历史调用实例在历史上调用所述系统的内部节点的系统耗时,在所述系统的内部节点中确定所述目标时段内的系统耗时异常节点,其中,所述历史调用实例与所述参考调用实例的实例结构相同或相似。
图7是本说明书提供的确定系统耗时异常的装置700的结构示意图。请参考图7,在一种软件实施方式中,确定系统耗时异常的装置700可包括:
耗时异常确定模块701,用于确定目标时段内目标场景对应的系统耗时是否存在异常;
参考实例确定模块702,用于如果存在异常,确定所述目标时段内所述目标场景对应的参考调用实例;
异常节点确定模块703,用于基于所述参考调用实例在所述目标时段内调用系统的内部节点的系统耗时,以及历史调用实例在历史上调用所述系统的内部节点的系统耗时,在所述系统的内部节点中确定所述目标时段内的系统耗时异常节点,其中,所述历史调用实例与所述参考调用实例的实例结构相同或相似。
可选地,所述异常节点确定模块703,具体可用于:
确定所述参考调用实例在所述目标时段内调用系统的内部节点的系统耗时,相对于历史调用实例在历史上调用所述系统的内部节点的系统耗时的增长幅度;
基于所述增长幅度,确定所述系统的内部节点在所述目标时段内的异常级别;
基于所述异常级别,在所述系统的内部节点中确定所述目标时段内的系统耗时异常节点。
在此基础上,可选地,所述装置700还可以包括:
展示模块,用于基于预先确定的异常级别与展示方式的对应关系,展示所述参考调用实例内部节点的异常级别。
本说明书图7所示的实施例提供的一种确定系统耗时异常的装置700,由于在确定出目标时段内目标场景对应的系统耗时存在异常的基础上,能够进一步地,基于目标时段内目标场景对应的参考调用实例在所述目标时段内调用系统的内部节点的系统耗时,以及历史调用实例在历史上调用所述系统的内部节点的系统耗时,确定出目标时段内所述系统内的系统耗时异常节点,因此,可以确定出目标时段内系统耗时出现异常的原因,能够帮助系统维护人员快速定位出故障,提高了系统维护效率。
可选地,所述装置700还可以包括:
调用标识确定模块,用于在所述系统的内部节点中确定所述目标时段内的系统耗时异常节点之前,基于所述目标时段内所述目标场景对应的系统耗时信息,确定所述参考调用实例对应的调用的标识;
调用详情获取模块,用于基于所述标识,从第一预设数据库中查询获得所述参考调用实例对应的调用的详情;
实例结构确定模块,用于基于所述详情,确定所述参考调用实例的实例结构;
历史调用实例获取模块,用于基于所述参考调用实例的实例结构,从所述第一预设数据库中查询获得所述历史调用实例。
可选地,所述参考调用实例是,所述目标时段内所述目标场景对应的调用实例中系统耗时最长的调用实例;
和/或,所述历史调用实例是与所述参考调用实例的实例结构相同或相似的历史调用实例中,发生时刻与所述目标时段最接近的历史调用实例。
可选地,所述耗时异常确定模块701,具体可以用于:
基于所述目标时段内所述目标场景对应的预设系统耗时参数,以及预设历史时段内所述目标场景对应的预设系统耗时参数,确定所述目标时段内所述目标场景对应的系统耗时是否存在异常。
可选地,如图8所示,在另一个实施例中,所述装置700还可包括:
过滤模块704,用于在所述确定目标时段内目标场景对应的系统耗时是否存在异常之前,基于拉依达准则,过滤所述预设历史时段内所述目标场景对应的预设系统耗时参数中的异常参数。
可选地,如图9所示,在另一个实施例中,所述耗时异常确定模块701,可以包括:
第一确定子模块901,用于基于所述目标时段内所述目标场景对应的预设系统耗时参数,以及所述预设历史时段内所述目标场景对应的预设系统耗时参数,确定所述目标时段内所述目标场景对应的预设系统耗时参数的波动值;
第二确定子模块902,用于基于拉依达准则和所述预设历史时段内所述目标场景对应的预设系统耗时参数,确定所述波动值的阈值区间;
第三确定子模块903,用于基于所述波动值和所述阈值区间,确定所述目标时段内所述目标场景对应的系统耗时是否存在异常。
可选地,所述第一确定子模块901,具体可用于:
确定所述预设历史时段内所述目标场景对应的所述预设系统耗时参数的平均值和标准差;
基于所述平均值和所述标准差,确定所述目标时段内所述目标场景对应的所述预设系统耗时参数的标准分数;
将所述标准分数确定为所述波动值。
图8所示的实施例提供的装置700,除了能够确定出目标时段内系统耗时出现异常的原因外,由于是基于历史时段的预设系统耗时参数,动态地确定系统耗时的异常情况,因此,能够提高系统耗时异常检测结果的准确性。
确定系统耗时异常的装置700能够实现图1的方法实施例的方法,具体可参考图1所示实施例的确定系统耗时异常的方法,不再赘述。
总之,以上所述仅为本说明书的较佳实施例而已,并非用于限定本说明书的保护范围。凡在本说明书一个或多个实施例的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本说明书一个或多个实施例的保护范围之内。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制时,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。