一种软件过载告警方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种软件过载告警方法及装置。

背景技术

目前，对于高性能服务器上安装的软件，需要采集软件在工作状态时的负载值，以便运营人员能够在软件过载时及时对软件进行扩容，从而保证高性能服务器能够正常服务。

相关技术中，可以通过调用采集脚本或外部组件来检测软件的负载值，并根据检测出的负载值进行过载告警。例如，每30秒调用一次采集脚本，通过采集脚本检测获得软件在当前时刻下的负载值。但是，相关技术中的这种定时采集方式，仅能获取到在当前时刻下调用采集脚本时软件的负载值，因此，可能会在采集过程中出现误判，从而降低软件过载告警的准确度。并且，由于相关技术中需要通过调用采集脚本或使用外部组件来检测软件的负载值，频繁地调用采集脚本或使用外部组件会占用大量的系统资源，因此，会增加软件过载告警过程中的系统资源消耗。

发明内容

本申请实施例提供一种软件过载告警方法及装置，以提高对软件过载告警的准确度，并降低软件过载告警的系统资源消耗。

本申请实施例提供的具体技术方案如下：

一种软件过载告警方法，包括：

在预设的采样时间段内至少调用一次监听函数，并获取在所述采样时间段内开始调用所述监听函数的各起始时间和结束调用所述监听函数的各结束时间，其中，结束时间为当监听到通信事件时结束调用所述监听函数采集到的时间，所述监听函数用于持续监听在软件的进程中是否发生通信事件；

根据所述各起始时间和所述各结束时间，确定所述软件在所述采样时间段内的运行时间；

根据所述运行时间确定所述软件在所述采样时间段内的负载值，并根据所述负载值确定是否对所述软件进行过载告警。

可选的，在预设的采样时间段内至少调用一次监听函数，并获取在所述采样时间段内开始调用所述监听函数的各起始时间和结束调用所述监听函数的各结束时间，具体包括：

在预设的采样时间段内至少执行一次以下操作步骤，获得在所述采样时间段内开始调用监听函数的各起始时间和结束调用所述监听函数的各结束时间：在软件的进程中调用监听函数，并获取开始调用所述监听函数的起始时间，若确定在所述进程中监听到通信事件，则结束调用所述监听函数，并获取结束调用所述监听函数的结束时间，处理监听到的通信事件。

可选的，处理监听到的通信事件之后，进一步包括：

判断所述结束时间与初次调用所述监听函数的起始时间之间的时间差值是否大于预设的采样时间段；

若确定所述时间差值大于所述采样时间段，则终止调用所述监听函数，获得各起始时间和各结束时间；

若确定所述时间差值不大于所述采样时间段，则重新执行在软件的进程中调用监听函数的步骤。

可选的，处理监听到的通信事件，具体包括：

基于监听到的通信事件，唤醒所述进程；

在所述进程中处理所述通信事件。

可选的，根据所述各起始时间和所述各结束时间，确定所述软件在所述采样时间段内的运行时间，具体包括：

分别针对各结束时间，计算任意一结束时间与下一次开始调用所述监听函数的起始时间之间的第一时间差值；

将计算出的各第一时间差值相加，获得所述软件在所述采样时间段内的运行时间。

可选的，根据所述各起始时间和所述各结束时间，确定所述软件在所述采样时间段内的运行时间，具体包括：

分别针对所述各起始时间，计算任意一起始时间与对应的结束时间之间的第二时间差值；

将计算出的各第二时间差值相加，获得所述软件在所述采样时间段内的空闲时间；

通过计算所述采样时间段与所述空闲时间之间的时间差值，获得所述软件在所述采样时间段内的运行时间。

可选的，根据所述运行时间确定所述软件在所述采样时间段内的负载值，具体包括：

计算所述运行时间与所述采样时间段之间的比值；

将计算出的比值作为所述软件在所述采样时间段内的负载值。

可选的，根据所述负载值确定是否对所述软件进行过载告警，具体包括：

判断所述负载值是否大于预设的负载阈值，若确定所述负载值大于等于所述负载阈值，则将预设的过载计数器中存储的过载计数加1，若确定所述负载值小于所述负载阈值，则将所述过载计数清零；

根据所述过载计数器中的过载计数，确定对应的告警方式；

基于确定出的告警方式，对所述软件进行负载告警。

一种软件过载告警装置，包括：

处理模块，用于在预设的采样时间段内至少调用一次监听函数，并获取在所述采样时间段内开始调用所述监听函数的各起始时间和结束调用所述监听函数的各结束时间，其中，结束时间为当监听到通信事件时结束调用所述监听函数采集到的时间，所述监听函数用于持续监听在软件的进程中是否发生通信事件；

确定模块，用于根据所述各起始时间和所述各结束时间，确定所述软件在所述采样时间段内的运行时间；

告警模块，用于根据所述运行时间确定所述软件在所述采样时间段内的负载值，并根据所述负载值确定是否对所述软件进行过载告警。

可选的，处理模块具体用于：

在预设的采样时间段内至少执行一次以下操作步骤，获得在所述采样时间段内开始调用监听函数的各起始时间和结束调用所述监听函数的各结束时间：在软件的进程中调用监听函数，并获取开始调用所述监听函数的起始时间，若确定在所述进程中监听到通信事件，则结束调用所述监听函数，并获取结束调用所述监听函数的结束时间，处理监听到的通信事件。

可选的，处理监听到的通信事件之后，处理模块进一步用于：

判断所述结束时间与初次调用所述监听函数的起始时间之间的时间差值是否大于预设的采样时间段；

若确定所述时间差值大于所述采样时间段，则终止调用所述监听函数，获得各起始时间和各结束时间；

若确定所述时间差值不大于所述采样时间段，则重新执行在软件的进程中调用监听函数的步骤。

可选的，处理监听到的通信事件时，处理模块具体用于：

基于监听到的通信事件，唤醒所述进程；

在所述进程中处理所述通信事件。

可选的，确定模块具体用于：

分别针对各结束时间，计算任意一结束时间与下一次开始调用所述监听函数的起始时间之间的第一时间差值；

将计算出的各第一时间差值相加，获得所述软件在所述采样时间段内的运行时间。

可选的，确定模块具体用于：

分别针对所述各起始时间，计算任意一起始时间与对应的结束时间之间的第二时间差值；

将计算出的各第二时间差值相加，获得所述软件在所述采样时间段内的空闲时间；

通过计算所述采样时间段与所述空闲时间之间的时间差值，获得所述软件在所述采样时间段内的运行时间。

可选的，根据所述运行时间确定所述软件在所述采样时间段内的负载值时，告警模块具体用于：

计算所述运行时间与所述采样时间段之间的比值；

将计算出的比值作为所述软件在所述采样时间段内的负载值。

可选的，根据所述负载值确定是否对所述软件进行过载告警时，告警模块具体用于：

判断所述负载值是否大于预设的负载阈值，若确定所述负载值大于等于所述负载阈值，则将预设的过载计数器中存储的过载计数加1，若确定所述负载值小于所述负载阈值，则将所述过载计数清零；

根据所述过载计数器中的过载计数，确定对应的告警方式；

基于确定出的告警方式，对所述软件进行负载告警。

一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述软件过载告警方法的步骤。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述软件过载告警方法的步骤。

本申请实施例中，在预设的采样时间段内至少调用一次监听函数，并获取在采样时间段内开始调用监听函数的各起始时间和结束调用监听函数的各结束时间，根据各起始时间和各结束时间，确定软件在采样时间段内的运行时间，根据运行时间确定软件在采样时间段内的负载值，并根据负载值确定是否对软件进行过载告警。这样，无需依赖外部组件或调用采集脚本，只需要通过在预设的采样时间段内多次调用监听函数确定出各起始时间和各结束时间，并根据各起始时间和各结束时间获得软件在采样时间段内的负载值，从而能够降低系统资源消耗。并且，通过该方法能够获得软件在采样时间段内的负载值，相比于相关技术中仅采集软件在某个时刻的负载值来说，能够避免误判或遗漏，从而提高软件过载告警的准确度。

附图说明

图1为本申请实施例中一种软件过载告警方法的流程图；

图2为本申请实施例中采样数据的采样示意图；

图3为本申请实施例中场景1的效果示意图；

图4为本申请实施例中场景2的效果示意图；

图5为本申请实施例中场景3的效果示意图；

图6为本申请实施例中场景4的效果示意图；

图7为本申请实施例中一种软件过载告警方法的另一流程图；

图8为本申请实施例中软件过载告警装置的结构示意图；

图9为本申请实施例中电子设备的结构示意图。

具体实施方式

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

针对线上为用户提供实时服务的软件，特别是高性能服务器上安装的软件，需要采集软件在工作状态时的负载情况，以便运营人员在软件过载时，能够及时对软件进行扩容，从而保证高性能服务器可以始终保持正常服务。

一般来说，整机的服务指标包括：CPU的占用率、IO的读写频繁程度等，整机的服务指标能够反映出软件的负载值。相关技术中，可以通过采集脚本或者外部组件来检测软件的负载值，从而达到预警的目的。例如，可以通过Linux系统的定时任务或其它组件每30秒调用一次采集脚本来确定软件的负载值。但是，由于相关技术中的这种方式是通过设置定时任务实现的，因此，仅能够获取到在启动定时任务的时刻下软件的负载值，也就是说，相关技术中的这种实现方式仅能获取到某一时刻的负载值，因此，可能会在采集过程中出现误判，从而降低软件过载告警的准确度。例如，在采集瞬间产生的CPU突刺会被误判为负载过高，又例如，在采集点附近刚好恢复成正常状态而被忽略。并且，由于相关技术中需要通过调用采集脚本或使用外部组件来检测软件的负载值，因此，会增加系统资源消耗。

为了解决上述问题，本申请实施例中，提供了一种软件过载告警方法，在预设的采样时间段内至少调用一次监听函数，并获取在采样时间段内开始调用监听函数的各起始时间和结束调用监听函数的各结束时间，根据各起始时间和各结束时间，确定软件在采样时间段内的运行时间，根据运行时间确定软件在采样时间段内的负载值，并根据负载值确定是否对软件进行过载告警，根据各起始时间和各结束时间，确定软件在采样时间段内的运行时间，根据运行时间确定软件在采样时间段内的负载值，并根据负载值确定是否对软件进行过载告警，这样，无需依赖外部组件，只需要通过在预设的采样时间段内多次调用监听函数，获得各起始时间和结束时间，并基于各起始时间和各结束时间确定软件的负载值，在过载告警的过程中几乎没有消耗系统资源。并且，根据采样时间段内的各开始调用监听函数的起始时间和各结束调用监听函数的结束时间计算得出软件在采样时间段内的负载值，能够避免在采集过程中的误判情况，从而提高了软件过载告警的实时性和准确性。

基于上述实施例，参阅图1所示，为本申请实施例中一种软件过载告警方法的流程图，具体包括：

步骤100：在预设的采样时间段内至少调用一次监听函数，并获取在所述采样时间段内开始调用监听函数的各起始时间和结束调用监听函数的各结束时间。

其中，结束时间为当监听到通信事件时结束调用监听函数采集到的时间，监听函数用于持续监听在软件的进程中是否发生通信事件。

本申请实施例中，执行步骤100时，具体包括：

在预设的采样时间段内至少执行一次以下操作步骤，获得在采样时间段内开始调用监听函数的各起始时间和结束调用监听函数的各结束时间：在软件的进程中调用监听函数，并获取开始调用监听函数的起始时间，若确定在进程中监听到通信事件，则结束调用监听函数，并获取结束调用监听函数的结束时间，处理监听到的通信事件。

其中，监听函数用于持续监听在进程是否发生通信事件。

本申请实施例中，高性能服务器中安装有多种不同类型的软件，每一个软件中包含有进程。为了确定软件在采样时间段内的负载值，可以在预设的采样时间段内至少执行一次以下操作步骤，获得在采样时间段内开始调用监听函数的各起始时间和结束调用监听函数的各结束时间，进而就能够根据获取到的各起始时间和各结束时间确定出软件在采样时间段内的负载值：

A1：在软件的进程中调用监听函数，并获取开始调用监听函数的起始时间。

本申请实施例中，确定需要进行过载告警的软件，并在确定出的软件的进程中搭建事件驱动框架，在事件驱动框架搭建完成之后，在确定出的软件的进程中调用监听函数，也就是说，从函数数据库中将监听函数调用到软件的进程中，并获取开始调用监听函数的起始时间。

其中，起始时间表征的软件的进程开始调用监听函数的瞬时的时间，例如，假设软件的进程开始调用监听函数的时间为16:00:26，结束调用监听函数的时间为16:00:53，则获取到的开始调用监听函数的起始时间为16:00:26。

其中，本申请实施例中的事件驱动框架可以基于不同的方式实现，例如可以为select、poll、epoll等多路复用机制，本申请实施例中对此并不进行限制。

需要说明的是，若确定软件的进程已调用监听函数，则软件的该进程会被阻塞，此时进程处于休眠状态，处于休眠状态的进程会持续等待是否有通信事件发生。

以事件驱动框架为epoll为例，当事件驱动框架为epoll时，监听函数为epoll_wait函数，在调用epoll_wait函数时，获取开始调用epoll_wait函数的起始时间t0。并且，若此时在进程中未监听到通信事件，则该软件的进程会被阻塞，该软件的进程会从工作状态转换为休眠状态，休眠状态时，进程未进行工作。

A2：若确定在进程中监听到通信事件，则结束调用监听函数，并获取结束调用监听函数的结束时间。

本申请实施例中，当软件的进程调用监听函数之后，进程此时处于休眠状态，但是，进程会运行已调用的监听函数，并基于监听函数持续监听在软件的进程中是否发生预设类型的通信事件，若确定在软件的进程中未发生预设类型的通信事件，则继续监听是否发生预设类型的通信事件，此时该软件的进程仍然处于休眠状态，若确定在软件的进程中发生预设类型的通信事件，则处于休眠状态的进程被唤醒，结束调用监听函数，并将监听函数返回至函数数据库中，并获取结束调用监听函数的结束时间。

其中，结束时间表征的软件的进程结束调用监听函数的瞬时的时间，例如，假设软件的进程开始调用监听函数的时间为16:00:26，结束调用监听函数的时间为16:00:53，则软件的进程在16:00:26-16:00:53中，持续调用监听函数。那么，最终获取到的结束调用监听函数的结束时间为16:00:53。

以事件驱动框架为epoll为例，对本申请实施例中获取结束时间的步骤进行详细阐述。当事件驱动框架为epoll时，监听函数为epoll_wait函数，若确定在软件的进程中监听到预设的通信事件，则进程会被唤醒，并触发epoll_wait函数返回，此时结束调用epoll_wait函数，获取当前结束调用epoll_wait函数的时间t1。并且，由于此时在进程中发生了预设的通信事件，则该软件的进程被唤醒，该软件的进程会从休眠状态转换为工作状态，工作状态时，进程在工作。

A3：处理监听到的通信事件。

本申请实施例中，在监听到通信事件之后，处理监听到的通信事件。

需要说明的是，可将上述步骤A1至A3认为是一个循环，并在预设的采样时间段内至少执行一次步骤A1至A3，直至预设的采样时间段到时之后，停止执行上述步骤。因此，在预设的采样时间段内包含有至少一个循环，也即在采样时间段内至少调用一次监听函数。

并且，需要说明的是，本申请实施例仅针对于单进程的软件，并且，由于主线程是循环处理通信事件的，因此，本申请实施例仅针对于单进程内的主线程进行采集。

进一步地，在每一次调用监听函数的循环中，处理完成监听到的通信事件之后，还需要根据从当前循环中获取到的结束时间来确定预设的采样时间段是否到时，从而判断是否需要终止调用监听函数，具体包括：

A1：判断结束时间与初次调用监听函数的起始时间之间的时间差值是否大于预设的采样时间段。

A2：若确定时间差值大于采样时间段，则终止调用监听函数，获得各起始时间和各结束时间。

A3：若确定时间差值不大于采样时间段，则返回在软件的进程中调用监听函数的步骤。

本申请实施例中，当软件的进程处理完成监听到的通信事件之后，获取初次调用监听函数的起始时间，并判断结束时间与初次调用监听函数的起始时间之间的时间差值是否大于预设的采样时间段，具体可以分为以下两种情况：

第一种情况：结束时间与初次调用监听函数的起始时间之间的时间差值大于预设的采样时间段。

具体包括：若确定结束时间与初次调用监听函数的起始时间之间的时间差值大于预设的采样时间段，则终止调用监听函数，获得各起始时间和各终止时间。

本申请实施例中，将第一次调用监听函数的起始时间作为初次调用监听函数的起始时间。若确定在某次循环结束时，获取到的该循环内的结束时间与初次调用监听函数的起始时间之间的时间差值大于预设的采样时间段，则终止调用监听函数，获得在采样时间段内采集到的各起始时间和各终止时间。

例如，假设预设的采样时间段为10s，初次调用监听函数的起始时间为16:00:06，若在第三次循环中，获取到的结束时间为16:00:17，则将初次调用监听函数的起始时间、初次返回监听函数的结束时间、第二次调用监听函数的起始时间、第二次返回监听函数的结束时间、第三次调用监听函数的起始时间和第三次返回监听函数的结束时间作为在该采样时间段10s内采集到的各起始时间和各结束时间。

第二种情况：结束时间与初次调用监听函数的起始时间之间的时间差值不大于预设的采样时间段。

具体包括：若确定结束时间与初次调用监听函数的起始时间之间的时间差值不大于采样时间段，则返回在软件的进程中调用监听函数的步骤。

本申请实施例中，若确定结束时间与初次调用监听函数的起始时间之间的时间差值不大于采样时间段，则确定还需要在采样时间段内继续采集调用监听函数的起始时间和结束时间，因此，返回在软件的进程中调用监听函数的步骤，重新调用监听函数。

例如，假设预设的采样时间段为10s，初次调用监听函数的起始时间为16:00:06，若在第三次循环中，获取到的结束时间为16:00:13，则确定在还未采集完成，需要继续采集调用监听函数的起始时间和结束时间，返回在软件的进程中调用监听函数的步骤。

进一步地，本申请实施例中，还可以设置定时器，在定时器设定的定时时间段中，持续执行在软件的进程中调用监听函数，并获取开始调用监听函数的起始时间，若确定在进程中监听到通信事件，则结束调用监听函数，并获取结束调用监听函数的结束时间，处理监听到的通信事件的循环步骤，直至定时器到时，则结束采集，获得在定时器的定时时间段中的各起始时间和结束时间。

例如，假设在定时器中设定的定时时间段为10s，则在10s内持续执行上述循环步骤，直至10s到时，停止执行循环步骤。并获得在该10s内调用监听函数的各起始时间和各结束时间。

进一步地，当软件的进程结束调用监听函数之后，可以唤醒处于休眠状态的进程，并在进程中处理监听到的通信事件，下面对本申请实施例中处理通信事件的步骤进行详细阐述，具体包括：

A1：基于监听到的通信事件，唤醒进程。

本申请实施例中，若确定在软件的进程中监听到通信事件，则基于监听到的通信事件，唤醒此时正处于休眠状态的软件中的进程。

其中，通信事件可以为一件事件，也可以为多件事件，本申请实施例中对此并不进行限制。

并且，通信事件为预先设置的不同类型的通信事件，例如可以为读写事件等，本申请实施例中对此并不进行限制。

需要说明的是，若在软件的进程中监听到多个通信事件，则在监听到第一个通信事件时，唤醒进程，并结束调用监听函数。

A2：在进程中处理通信事件。

本申请实施例中，在进程中处理监听到的通信事件，若确定监听到的通信事件被处理完成，则确定软件中的进程的工作状态结束，并重新将监听函数再次调用至进程中，将进程此时的工作状态转换为休眠状态。

步骤110：根据各起始时间和各结束时间，确定软件在采样时间段内的运行时间。

本申请实施例中，在确定软件在采样时间段内的运行时间时，可以通过以下两种方式实现，下面对本申请实施例中，确定软件在采样时间段内的运行时间的两种方式进行详细阐述。

第一种处理方式，具体包括：

S1：分别针对各结束时间，计算任意一结束时间与下一次开始调用监听函数的起始时间之间的第一时间差值。

本申请实施例中，由于开始调用监听函数的起始时间为软件停止工作的时间，结束调用监听函数的结束时间为软件开始工作的时间，因此，可以将每一个结束时间，以及与其对应的下一次开始调用监听函数的起始时间分为一组，获得在采样时间段内的各时间组合，并分别针对各时间组合，计算任意一时间组合中包含的结束调用监听函数的结束时间，与开始调用监听函数的起始时间之间的第一时间差值，也就是说，该第一时间差值为当前结束调用监听函数时的结束时间与下一次再次开始调用监听函数的起始时间之间的差值。在该第一时间差值中，进程处于工作状态，且进程一直在处理监听到的通信事件，因此，可以认为在该时间段中软件处于工作状态。

例如，参阅图2所示，为本申请实施例中采集起始时间和结束时间的采集示意图，在图2中，假设初次开始调用监听函数的起始时间为t0，初次结束调用监听函数的结束时间为t1，第二次开始调用监听函数的起始时间为t2，第二次结束调用监听函数的结束时间为t3，第三次开始调用监听函数的起始时间为t4，第三次结束调用监听函数的结束时间为t5，第四次开始调用监听函数的起始时间为t6，第四次结束调用监听函数的结束时间为t7，第五次开始调用监听函数的起始时间为t8，则将第二次开始调用监听函数的起始时间t2与初次结束调用监听函数的结束时间t1分为一组，将第三次开始调用监听函数的起始时间t4与第二次结束调用监听函数的结束时间t3分为一组，将第四次开始调用监听函数的起始时间t6与第三次结束调用监听函数的结束时间t5分为一组，将第五次开始调用监听函数的起始时间t8与第四次结束调用监听函数的结束时间t7分为一组，共得到4组时间组合。然后，计算第二次调用监听函数的起始时间t2与初次返回监听函数的结束时间t1之间的时间差值为t2-t1，计算第三次调用监听函数的起始时间t4与第二次返回监听函数的结束时间t3之间的时间差值t4-t3，计算第四次调用监听函数的起始时间t6与第三次返回监听函数的结束时间t5之间的时间差值t6-t5，计算第五次调用监听函数的起始时间t8与第四次返回监听函数的结束时间t7之间的时间差值t8-t7。

需要说明的是，以监听函数为epoll_wait函数为例，在开始调用epoll_wait函数到该epoll_wait函数返回的这段时间可以认为是空闲时间，epoll_wait函数返回之后到下次调用该函数前的时间都属于工作时间。

其中，工作时间至少包括以下一种：CPU处理时间、休眠时间、输入端口读写时间、输出端口读写事件、互斥锁竞争等待时间，本申请实施例中对此并不进行限制。

S2：将计算出的各第一时间差值相加，获得软件在采样时间段内的运行时间。

本申请实施例中，由于各第一时间差值表示软件的工作时间，因此，在获得各时间组合对应的工作时间之后，将软件的各工作时间相加，也就是说，将计算出的各第一时间差值相加，就能够获得软件在采样时间段内的运行时间。

例如，如图2所示，计算出的各第一时间差值分别为t2-t1、t4-t3、t6-t5和t8-t7，则软件在采样时间内的运行时间为t＝(t2-t1)+(t4-t3)+(t6-t5)+(t8-t7)。

第二种处理方式，具体包括：

S1：分别针对各起始时间，计算任意一起始时间与对应的结束时间之间的第二时间差值。

本申请实施例中，由于开始调用监听函数的起始时间为软件停止工作的时间，结束调用监听函数的结束时间为软件开始工作的时间，因此，可以将每一个循环中采集到的开始调用监听函数的起始时间和对应的结束调用监听函数的结束时间分为一组，获得在采样时间段内的各时间组合，计算任意一时间组合中包含的开始调用监听函数的起始时间，与结束调用监听函数的结束时间之间的第二时间差值，也就是说，该第二时间差值为当前开始调用监听函数的起始时间与当前结束调用监听函数的结束时间之间的差值。在该第二时间差值中，进程处于空闲状态。

例如，如图2所示，采样时间段为t8-t0假设初次开始调用监听函数的起始时间为t0，初次结束调用监听函数的结束时间为t1，第二次开始调用监听函数的起始时间为t2，第二次结束调用监听函数的结束时间为t3，第三次开始调用监听函数的起始时间为t4，第三次结束调用监听函数的结束时间为t5，第四次开始调用监听函数的起始时间为t6，第四次结束调用监听函数的结束时间为t7，第五次开始调用监听函数的起始时间为t8，则将初次结束调用监听函数的起始时间t1与初次开始调用监听函数的起始时间t0分为一组，将第二次结束调用监听函数的结束时间t3与第二次开始调用监听函数的起始时间t2分为一组，将第三次结束调用监听函数的结束时间t5与第三次开始调用监听函数的起始时间t4分为一组，将第四次结束调用监听函数的结束时间t7与第四次开始调用监听函数的起始时间t6分为一组，共获得4组时间组合。然后，计算初次结束调用监听函数的起始时间t1与初次开始调用监听函数的起始时间t0之间的时间差值为t1-t0，计算第二次结束调用监听函数的结束时间t3与第二次开始调用监听函数的起始时间t2之间的时间差值t3-t2，计算第三次结束调用监听函数的结束时间t5与第三次开始调用监听函数的起始时间t4之间的时间差值t5-t4，计算第四次结束调用监听函数的结束时间t7与第四次开始调用监听函数的起始时间t6之间的时间差值t7-t6。

S2：将计算出的各第二时间差值相加，获得软件在采样时间段内的空闲时间。

本申请实施例中，由于各第二时间差值表示软件的空闲时间，因此，在获得各时间组合对应的空闲时间之后，将软件的各空闲时间相加，也就是说，将计算出的各第二时间差值相加，就能够获得软件在采样时间段内的空闲时间。

例如，如图2所示，计算出的各第二时间差值分别为t1-t0、t3-t2、t5-t4和t7-t6，则软件在采样时间段内的空闲时间为t＝(t1-t0)+(t3-t2)+(t5-t4)+(t7-t6)。

S3：通过计算采样时间段与空闲时间之间的时间差值，获得软件在采样时间段内的运行时间。

例如，如图2所示，当采样时间段为t0到t8，则软件在采样时间段内的运行时间为采样时间段减去空闲时间，为t＝(t8-t0)-((t1-t0)+(t3-t2)+(t5-t4)+(t7-t6))。

本申请实施例中，由于在采样时间段内，软件仅会处于有两种状态，一种为休眠状态，另一种为工作状态，因此，若需要得到软件在采样时间段内的运行时间，则计算采样时间段与空闲时间之间的时间差值，计算出的时间差值即为软件在采样时间段内的工作时间。

步骤120：根据运行时间确定软件在采样时间段内的负载值，并根据负载值确定是否对软件进行过载告警。

本申请实施例中，在根据运行时间确定软件在采样时间段内的负载值时，具体包括：

S1：计算运行时间与采样时间段之间的比值。

本申请实施例中，由于采样时间段内，进程仅可能处于两种状态，一种状态为工作状态，另一种状态为运行状态。那么，计算进程在采样时间段内处于工作状态的占比，就能够获得软件的在采样时间段内的负载值。因此，计算运行时间与采样时间段之间的比值。

S2：将计算出的比值作为软件在采样时间段内的负载值。

本申请实施例中，可以将进程在采样时间段内处于工作状态的时间的占比，作为软件在采样时间段内的负载值。

例如，例如，假设采样时间段为t，运行时间为t1，则负载值可以表示为：

t0＝t1*100％/t

需要说明的是，本申请实施例中的负载值表征进程在采样时间段内处于工作状态的时间的占比。

当然，负载值还可以为一个数值，则计算运行时间与采样时间段之间的比值，并将计算出的比值乘以100，从而得到负载值，例如，假设采样时间段为t，运行时间为t1，则负载值可以表示为：

t0＝t1*100/t

进一步地，本申请实施例中，获得软件在采样时间段内的负载值时，还可以计算进程在采样时间段内处于空闲状态的时间的占比，并用1减去进程在采样时间段内处于空闲状态的时间的占比，从而得到进程在采样时间段内处于工作状态的时间的占比。

例如，假设空闲占比为idle_ratio，采样时间段为Totaltime，各处于空闲状态的时间为deltaWait，则空闲占比可以表示为：

idle_ratio＝deltaWait/Totaltime*100

＝(t1-t0+t3-t2+t5-t4+t7-t6)/(t8-t0)*100

因此，可以计算出软件的负载占比为：

work_ratio＝100-idle_ratio

另外，需要说明的是，本申请实施例中的方法仅针对单进程内的主线程，也即主线程处理事件循环进行采集，因此，日志打印的负载usage不会超过100。通过top命令获得的％CPU会超过100，这是因为top统计的是所有线程的CPU使用率，因此，该方法关注的是主线程处理事件时的负载，不考虑其他线程的情况。

其中，top命令用于显示在Linux系统中各进程的资源占用状况。本申请实施例中，可以通过top命令显示的资源占用情况来确定基于调用监听函数的起始时间和结束时间确定出的负载值是否正确。例如，相关测试人员将top命令输入至Linux系统中，从而通过top命令能够显示出采样时间段内在Linux系统中包含的进程的CPU占用率％CPU，然后，在测试过程中，通过本申请实施例的方法能够得出在采样时间段内CPU的负载值usage，并将％CPU和usage进行比对。从而能够确定出通过本申请实施例中的方法计算出的软件的负载值是否可靠。

在获得软件在采样时间段内的负载值之后，就能够确定出的负载值判断是否需要对软件进行过载告警，下面对本申请实施例中的根据负载值判断是否需要对软件进行过载告警的步骤进行详细阐述，具体包括：

S1：判断负载值是否大于预设的负载阈值，若确定负载值大于等于负载阈值，则将预设的过载计数器中存储的过载计数加1，若确定负载值小于负载阈值，则将过载计数清零。

本申请实施例中，判断负载值是否大于预设的负载阈值，具体可以分为以下两种情况。

第一种情况：负载值大于等于负载阈值。

具体包括：读取过载计数器中存储的过载计数，并判断计算出的负载值是否大于预设的负载阈值，若确定负载值大于等于负载阈值，则将预设的过载计数器中存储的过载计数加1。

第二种情况：负载值小于负载阈值。

具体包括：读取过载计数器中存储的过载计数，并判断计算出的负载值是否大于预设的负载阈值，若确定负载值小于负载阈值，则将过载计数清零。

S2：根据过载计数器中的过载计数，确定对应的告警方式。

本申请实施例中，若确定过载计数器中的过载计数大于预设的计数阈值，则确定触发过载告警，若确定过载计数器中的过载计数等于预设的计数阈值，则确定触发将要过载告警，若确定过载计数器中的过载计数小于预设的计数阈值，则不触发告警。

S3：基于确定出的告警方式，对软件进行负载告警。

下面以4个场景为例，对本申请实施例中确定软件负载值的过程进行测试：

场景1：参阅图3所示，为本申请实施例中场景1的效果示意图，场景1中，软件包括2个工作进程，并发数为2，则此时通过top命令显示的CPU的负载占比分别为36.0％和31.6％，日志打印的负载usage分别为31、30、33、29、31、31。

场景2：参阅图4所示，为本申请实施中场景2的效果示意图，场景2中，软件包括2个工作进程，并发数为8，则此时通过top命令显示的CPU的负载占比分别为79.9％、72.6％，日志打印的负载usage分别为76、84、76、84、78、84、84、77。

场景3：参阅图5所示，为本申请实施例中场景3的效果示意图，场景3中，软件包括2个工作进程，并发数为16，则此时通过top命令显示的CPU的负载占比分别为101.2％、88.6％，日志打印的负载usage分别为88、95、91、91、94、87、87。

场景4：参阅图6所示，为本申请实施例中场景4的效果示意图，场景4中，软件包括2个工作进程，并发数为30，则此时通过top命令显示的CPU的负载占比分别为108.9％、92.2％，日志打印的负载usage分别为99、97、98、98、93、93。

需要说明的是，以上4个场景的测试数据是基于nginx事件驱动框架进行测试从而获得的，基于上述4组测试数据可知，总体上通过本申请实施例中的方法计算出的负载usage和通过top命令显示的％CPU数值接近，可以认为通过本申请实施例中的方法计算出的负载值是可靠的。

相关技术中，在对软件的负载进行检测时，需要外部频繁地执行采集任务会占用大量的系统资源，而本申请实施例中是通过采集调用监听函数的开始时间和结束时间来检测软件的负载值，不依赖于外部组件或者脚本，几乎没有消耗系统资源。并且，相关技术中，在外部探测时，只能通过缩短采集时间来提高灵敏度，因为探测间隔过长会导致灵敏度偏低。另外，通过外部手段可能会出现误判或者遗漏，比如在采集瞬间产生的cpu突刺会被误判为负载过高，也有可能在采集点附近因为状态刚好恢复成正常而被忽略。而通过本申请实施例中的方法，在计算负载的时候，根据最近一个统计周期内的数据计算得出负载，显著提高了负载判断的实时性，同时也提高了准确性。

基于上述实施例，参阅图7所示，为本申请实施例中一种软件过载告警方法的另一流程图，具体包括：

步骤700：开始。

步骤701：初始化采样时间段开始的时间，软件的空闲时间、过载计数器中的过载计数。

步骤702：记录结束调用监听函数的结束时间。

步骤703：判断结束时间与初次开始调用监听函数的起始时间之间的时间差值是否大于等于预设的采样时间段，若是，则执行步骤704，若否，则执行步骤710。

步骤704：判断(100-100*空闲时间)/采样时间段获得的比值是否大于过载阈值，若是，则执行步骤705，若否，则执行步骤706。

步骤705：将过载计数器中的过载计数加1。

步骤706：将过载计数器中的过载计数清0。

步骤707：判断过载计数器中的过载计数是否大于等于预设的计数阈值，若是，则执行步骤708，若否，则执行步骤713。

步骤708：触发告警。

步骤709：将空闲时间清0，并将当前时间记录为新的采样时间段的开始时间。

步骤710：开始调用监听函数。

步骤711：累计空闲时间。

步骤712：处理监听到的通信事件，并重新执行步骤702。

步骤713：结束。

本申请实施例中，针对单进程内的主线程，通过采集调用epoll_wait函数的开始时间和结束时间，并利用开始时间和结束时间计算出空闲等待时间在统计周期内的占比，进而得到工作时间的占比，也就是进程实际的负载情况，这样，计算出来的负载值能够真实反映出高性能服务器中安装的软件的进程的负载情况，并且在采集过程几乎不消耗系统资源，同时大大提高了负载判断的准确性和实时性。可以为负载均衡或者上层调度提供可靠的判断依据，从而能够提高软件过载告警的实时性和准确度。

基于同一发明构思，本申请实施例中提供了软件过载告警装置，该软件过载告警装置可以是硬件结构、软件模块、或硬件结构加软件模块。基于上述实施例，参阅图8所示，为本申请实施例中软件过载告警装置的结构示意图，具体包括：

处理模块800，用于在预设的采样时间段内至少调用一次监听函数，并获取在所述采样时间段内开始调用所述监听函数的各起始时间和结束调用所述监听函数的各结束时间，其中，结束时间为当监听到通信事件时结束调用所述监听函数采集到的时间，所述监听函数用于持续监听在软件的进程中是否发生通信事件；

确定模块810，用于根据所述各起始时间和所述各结束时间，确定所述软件在所述采样时间段内的运行时间；

告警模块820，用于根据所述运行时间确定所述软件在所述采样时间段内的负载值，并根据所述负载值确定是否对所述软件进行过载告警。

可选的，处理模块800具体用于：

在预设的采样时间段内至少执行一次以下操作步骤，获得在所述采样时间段内开始调用监听函数的各起始时间和结束调用所述监听函数的各结束时间：在软件的进程中调用监听函数，并获取开始调用所述监听函数的起始时间，若确定在所述进程中监听到通信事件，则结束调用所述监听函数，并获取结束调用所述监听函数的结束时间，处理监听到的通信事件。

可选的，处理监听到的通信事件之后，处理模块800进一步用于：

判断所述结束时间与初次调用所述监听函数的起始时间之间的时间差值是否大于预设的采样时间段；

若确定所述时间差值大于所述采样时间段，则终止调用所述监听函数，获得各起始时间和各结束时间；

若确定所述时间差值不大于所述采样时间段，则重新执行在软件的进程中调用监听函数的步骤。

可选的，处理监听到的通信事件时，处理模块800具体用于：

基于监听到的通信事件，唤醒所述进程；

在所述进程中处理所述通信事件。

可选的，确定模块810具体用于：

分别针对各结束时间，计算任意一结束时间与下一次开始调用所述监听函数的起始时间之间的第一时间差值；

将计算出的各第一时间差值相加，获得所述软件在所述采样时间段内的运行时间。

可选的，确定模块810具体用于：

分别针对所述各起始时间，计算任意一起始时间与对应的结束时间之间的第二时间差值；

将计算出的各第二时间差值相加，获得所述软件在所述采样时间段内的空闲时间；

通过计算所述采样时间段与所述空闲时间之间的时间差值，获得所述软件在所述采样时间段内的运行时间。

可选的，根据所述运行时间确定所述软件在所述采样时间段内的负载值时，告警模块820具体用于：

计算所述运行时间与所述采样时间段之间的比值；

将计算出的比值作为所述软件在所述采样时间段内的负载值。

可选的，根据所述负载值确定是否对所述软件进行过载告警时，告警模块820具体用于：

判断所述负载值是否大于预设的负载阈值，若确定所述负载值大于等于所述负载阈值，则将预设的过载计数器中存储的过载计数加1，若确定所述负载值小于所述负载阈值，则将所述过载计数清零；

根据所述过载计数器中的过载计数，确定对应的告警方式；

基于确定出的告警方式，对所述软件进行负载告警。

基于上述实施例，参阅图9所示为本申请实施例中电子设备的结构示意图。

本申请实施例提供了一种电子设备，该电子设备可以包括处理器910(CenterProcessing Unit，CPU)、存储器920、输入设备930和输出设备940等，输入设备930可以包括键盘、鼠标、触摸屏等，输出设备940可以包括显示设备，如液晶显示器(Liquid CrystalDisplay，LCD)、阴极射线管(Cathode Ray Tube，CRT)等。

存储器920可以包括只读存储器(ROM)和随机存取存储器(RAM)，并向处理器910提供存储器920中存储的程序指令和数据。在本申请实施例中，存储器920可以用于存储本申请实施例中任一种软件过载告警方法的程序。

处理器910通过调用存储器920存储的程序指令，处理器910用于按照获得的程序指令执行本申请实施例中任一种软件过载告警方法。

基于上述实施例，本申请实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意方法实施例中的软件过载告警方法。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。