检测报警方法、设备及服务器与流程

本发明实施例涉及服务器运维管理技术领域，尤其涉及一种检测报警方法、设备及服务器。

背景技术：

服务器，也称伺服器，是提供计算服务的设备，其具备提供服务并且保障服务的能力，随着计算机行业的高速发展，服务器的应用范围越来越广，提供的服务也越来越多，相应地，服务器的维护也成为一项重要工作。

目前，现有技术中在对服务器进行维护时，一般是当服务器检测到自身发生故障后，进行报警，以使相关维护人员在发现服务器报警后，对服务器进行维护，处理该服务器存在的故障。

然而，发明人发现现有技术中至少存在如下问题：由于服务器是在故障发生后，才进行报警以使相关维护人员进行维护的，当用户在该服务器的维护期间，向服务器请求某项服务时，该服务器可能由于无法正常运行，无法提供用户所需要的服务，无法满足用户需求。

技术实现要素：

本发明实施例提供一种检测报警方法、设备及服务器，以解决现有技术中服务器无法提供用户所需要的服务的问题。

第一方面，本发明实施例提供一种检测报警方法，应用于第一服务器，所述方法包括：

获取所述第一服务器的性能信息，其中所述性能信息包括运行信息和应用组件信息，所述应用组件信息包括多个应用组件标识；

将所述运行信息发送至第二服务器，以使所述第二服务器根据所述运行信息生成资源预测信息，并根据所述资源预测信息判断是否进行报警；

检测各应用组件标识对应的应用组件是否正常运行，并生成各应用组件对应的检测结果；

将所有检测结果发送至所述第二服务器，以使所述第二服务器根据所述所有检测结果判断是否进行报警。

在一种可能的设计中，所述检测各应用组件标识对应的应用组件是否正常运行，并生成各应用组件对应的检测结果，包括：

从所述多个应用组件标识中选取测试应用组件标识；

获取所述测试应用组件标识对应的报文检测脚本；

根据所述报文检测脚本发送测试报文至所述测试应用组件标识对应的测试应用组件，并接收所述测试应用组件返回的响应报文；

根据所述响应报文判断所述测试应用组件是否正常运行，并生成对应的检测结果。

在一种可能的设计中，所述测试报文包括服务测试报文，所述响应报文包括服务响应报文，所述检测结果包括服务停止运行结果；

所述根据所述报文检测脚本发送测试报文至所述测试应用组件标识对应的测试应用组件，并接收所述测试应用组件返回的响应报文，包括：

根据所述报文检测脚本发送服务测试报文至所述测试应用组件标识对应的测试应用组件，并接收所述测试应用组件返回的服务响应报文；

相应地，所述根据所述响应报文判断所述测试应用组件是否正常运行，并生成对应的检测结果，包括：

判断所述服务响应报文是否与所述服务测试报文对应的预期服务停止运行响应报文相同；

若所述服务响应报文与所述预期服务停止运行响应报文相同，则确定所述测试应用组件的服务停止运行，并生成服务停止运行结果。

在一种可能的设计中，所述应用组件标识包括数据库组件标识，所述检测结果包括数据库组件正常运行结果；

所述检测各应用组件标识对应的应用组件是否正常运行，并生成各应用组件对应的检测结果，包括：

获取所述数据库组件标识对应的数据库检测脚本；

根据所述数据库检测脚本对所述数据库组件标识对应的数据库组件进行检测操作，得到检测操作结果；其中所述检测操作包括查询操作和/或增加操作；

若所述检测操作结果与所述检测操作对应的预期操作结果相同，则确定所述数据库组件正常运行，并生成数据库组件正常运行结果。

在一种可能的设计中，所述将所述运行信息发送至第二服务器，包括：

将所述运行信息发送至集群服务器，以使所述集群服务器将所述运行信息转发至所述第二服务器。

第二方面，本发明实施例提供一种检测报警方法，应用于第二服务器，所述方法包括：

接收第一服务器发送的运行信息，其中所述运行信息是所述第一服务器在获取到自身的运行信息时发送的；

根据所述运行信息生成资源预测信息，并根据所述资源预测信息判断是否进行报警；

接收所述第一服务器发送的所有检测结果，其中所述检测结果是由所述第一服务器获取包括多个应用组件标识的应用组件信息，在检测各应用组件标识对应的应用组件是否正常运行，并生成各应用组件对应的检测结果时发送的；

根据所述所有检测结果判断是否进行报警。

在一种可能的设计中，所述运行信息包括当前内存使用量；所述资源预测信息包括内存预测时间，其中所述内存预测时间为预测内存使用量达到预设内存阈值所需的时间；

在一种可能的设计中，所述根据所述运行信息生成资源预测信息，包括：

将所述当前内存使用量保存至预设队列中，并获取所述预设队列中的内存使用量的总数量；

若所述总数量大于预设数量阈值，则针对所述预设队列中的各个内存使用量，根据该内存使用量与该内存使用量的上一个内存使用量计算内存增长率；

若计算出的内存增长率依次增加，则根据计算出的内存增长率计算内存预测增长率；

根据所述内存预测增长率计算所述第一服务器对应的内存预测时间。

在一种可能的设计中，所述根据计算出的内存增长率计算内存预测增长率，包括：

从计算出的内存增长率中选取预设数量的内存增长率；

根据所述预设数量的内存增长率和预设的平均加权算法计算所述内存预测增长率。

在一种可能的设计中，所述根据所述内存预测增长率计算所述第一服务器对应的内存预测时间，包括：

根据所述预设队列中的内存使用量得到目标内存使用量；

根据所述目标内存使用量、所述内存预测增长率、预设的内存报警阈值和预设的内存预测公式，得到所述内存预测时间。

在一种可能的设计中，所述根据所述资源预测信息判断是否进行报警，包括：

若所述内存预测时间小于预设的内存预测时间阈值，则进行报警。

在一种可能的设计中，所述根据所述所有检测结果判断是否进行报警，包括：

若所述所有检测结果中包括服务停止运行结果，则进行报警。

在一种可能的设计中，在所述若所述所有检测结果中包括服务停止运行结果，则进行报警之后，还包括：

获取所述服务停止运行结果对应的应用组件标识和服务标识；

根据所述服务停止运行结果对应的应用组件标识和服务标识生成服务报警信息，并将所述服务报警信息发送至预设联系人。

第三方面，本发明实施例提供一种检测报警设备，应用于第一服务器，所述设备包括：

性能信息获取模块，用于获取所述第一服务器的性能信息，其中所述性能信息包括运行信息和应用组件信息，所述应用组件信息包括多个应用组件标识；

运行信息处理模块，用于将所述运行信息发送至第二服务器，以使所述第二服务器根据所述运行信息生成资源预测信息，并根据所述资源预测信息判断是否进行报警；

应用组件检测模块，用于检测各应用组件标识对应的应用组件是否正常运行，并生成各应用组件对应的检测结果；

检测结果发送模块，用于将所有检测结果发送至所述第二服务器，以使所述第二服务器根据所述所有检测结果判断是否进行报警。

在一种可能的设计中，所述应用组件检测模块包括：

测试组件选取单元，用于从所述多个应用组件标识中选取测试应用组件标识；

检测脚本获取单元，用于获取所述测试应用组件标识对应的报文检测脚本；

报文检测单元，用于根据所述报文检测脚本发送测试报文至所述测试应用组件标识对应的测试应用组件，并接收所述测试应用组件返回的响应报文；

结果生成单元，用于根据所述响应报文判断所述测试应用组件是否正常运行，并生成对应的检测结果。

在一种可能的设计中，所述所述测试报文包括服务测试报文，所述响应报文包括服务响应报文，所述检测结果包括服务停止运行结果；

所述报文检测单元具体用于：

根据所述报文检测脚本发送服务测试报文至所述测试应用组件标识对应的测试应用组件，并接收所述测试应用组件返回的服务响应报文；

相应地，所述结果生成单元具体用于：

判断所述服务响应报文是否与所述服务测试报文对应的预期服务停止运行响应报文相同；

若所述服务响应报文与所述预期服务停止运行响应报文相同，则确定所述测试应用组件的服务停止运行，并生成服务停止运行结果。

在一种可能的设计中，所述应用组件标识包括数据库组件标识，所述检测结果包括数据库组件正常运行结果；

所述应用组件检测模块包括：

数据库检测脚本获取单元，用于获取所述数据库组件标识对应的数据库检测脚本；

操作结果生成单元，用于根据所述数据库检测脚本对所述数据库组件标识对应的数据库组件进行检测操作，得到检测操作结果；其中所述检测操作包括查询操作和/或增加操作；

操作结果处理单元，用于若所述检测操作结果与所述检测操作对应的预期操作结果相同，则确定所述数据库组件正常运行，并生成数据库组件正常运行结果。

在一种可能的设计中，所述运行信息处理模块具体用于：

将所述运行信息发送至集群服务器，以使所述集群服务器将所述运行信息转发至所述第二服务器。

第四方面，本发明实施例提供一种检测报警设备，应用于第二服务器，所述设备包括：

运行信息接收模块，用于接收第一服务器发送的运行信息，其中所述运行信息是所述第一服务器在获取到自身的运行信息时发送的；

预测信息生成模块，用于根据所述运行信息生成资源预测信息，并根据所述资源预测信息判断是否进行报警；

检测结果接收模块，用于接收所述第一服务器发送的所有检测结果，其中所述检测结果是由所述第一服务器获取包括多个应用组件标识的应用组件信息，在检测各应用组件标识对应的应用组件是否正常运行，并生成各应用组件对应的检测结果时发送的；

检测结果处理模块，用于根据所述所有检测结果判断是否进行报警。

在一种可能的设计中，所述运行信息包括当前内存使用量；所述资源预测信息包括内存预测时间，其中所述内存预测时间为预测内存使用量达到预设内存阈值所需的时间；

所述预测信息生成模块包括：

总数量获取单元，用于将所述当前内存使用量保存至预设队列中，并获取所述预设队列中的内存使用量的总数量；

内存增长率计算单元，用于若所述总数量大于预设数量阈值，则针对所述预设队列中的各个内存使用量，根据该内存使用量与该内存使用量的上一个内存使用量计算内存增长率；

预测增长率计算单元，用于若计算出的内存增长率依次增加，则根据计算出的内存增长率计算内存预测增长率；

内存预测时间计算单元，用于根据所述内存预测增长率计算所述第一服务器对应的内存预测时间。

在一种可能的设计中，内存增长率计算单元具体用于：

从计算出的内存增长率中选取预设数量的内存增长率；

根据所述预设数量的内存增长率和预设的平均加权算法计算所述内存预测增长率。

在一种可能的设计中，所述内存预测时间计算单元具体用于：根据所述预设队列中的内存使用量得到目标内存使用量；

根据所述目标内存使用量、所述内存预测增长率、预设的内存报警阈值和预设的内存预测公式，得到所述内存预测时间。

在一种可能的设计中，所述预测信息生成模块具体用于：

若所述内存预测时间小于预设的内存预测时间阈值，则进行报警。

在一种可能的设计中，所述检测结果处理模块具体用于：若所有检测结果中包括服务停止运行结果，则进行报警。

在一种可能的设计中，所述检测结果处理模块还用于：在所述若所述所有检测结果中包括服务停止运行结果，则进行报警之后，获取所述服务停止运行结果对应的应用组件标识和服务标识；根据所述服务停止运行结果对应的应用组件标识和服务标识生成服务报警信息，并将所述服务报警信息发送至预设联系人。

第五方面，本发明实施例提供一种服务器，包括：至少一个处理器和存储器；

所述存储器存储计算机执行指令；

所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如第一方面任一项所述的检测报警方法。

第六方面，本发明实施例提供一种服务器，包括：至少一个处理器和存储器；

所述存储器存储计算机执行指令；

所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如第二方面任一项所述的检测报警方法。

第七方面，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如第一方面任一项所述的检测报警方法。

第八方面，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如第二方面任一项所述的检测报警方法。

本发明实施例提供的检测报警方法、设备及服务器，该方法通过第二服务器根据第一服务器的运行信息生成资源预测信息，实现对资源的预估操作，并根据资源预测信息判断是否需要进行预估报警，从而实现在第一服务器的资源未达到规定报警阈值，但存在达到规定报警阈值的风险时，便进行提取报警使相关维护人员提前进行维护，保障服务器可以在用户使用时，可以正常运行，且第二服务器在根据各应用组件对应的检测结果判断出存在工作异常的应用组件时，便进行报警，以使相关维护人员提前进行维护，保证用户在使用应用组件时，应用组件可以正常运行，通过根据运行信息和应用组件信息进行相应地检测操作，全面判断第一服务器的性能是否存在异常，若存在异常，便进行报警以使相关人员进行维护，保证服务器在用户使用时可以提供用户所需的服务，满足用户的需求，且可以减轻维护人员的压力，避免出现在故障发生后或在用户使用时，才发现故障导致服务器不能提供用户所需的服务的问题。

附图说明

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

图1为本发明实施例提供的检测报警系统的场景示意图；

图2为本发明实施例提供的检测报警方法的流程图一；

图3为本发明实施例提供的检测报警方法的流程图二；

图4为本发明实施例提供的检测报警方法的流程图三；

图5为本发明实施例提供的检测报警方法的流程图四；

图6为本发明实施例提供的检测报警设备的结构示意图一；

图7为本发明实施例提供的检测报警设备的结构示意图二；

图8为本发明实施例提供的服务器的硬件结构示意图。

具体实施方式

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

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

图1为本发明实施例提供的检测报警系统的场景示意图，如图1所示，该检测报警系统包括第一服务器101和第二服务器102，第一服务器101可以为客户端服务器，第二服务器102可以为服务端服务器。

第一服务器获取自身的性能信息，该性能信息包括运行信息和应用组件信息。第一服务器将运行信息发送给第二服务器，第二服务器根据运行信息生成资源预测信息，实现对资源的预估操作，并根据资源预测信息判断是否需要进行报警，实现资源的预估报警，若需要进行报警，则直接进行报警，从而可以在第一服务器中的资源未达到规定报警阈值，但存在达到报警阈值的风险时，及时进行报警，使维护人员提前对第一服务器进行维护，保证在用户使用时，可以正常为用户提供服务，避免出现在服务器发生故障后再进行维护，导致用户在使用时，由于服务器不能正常运行，而无法满足用户需求的情况，保证服务器运行的稳定性。

其中，应用组件信息包括安装在第一服务器上的应用组件的信息和/或与第一服务器存在关联的应用组件的信息。其中第一服务器可以为esim(embedded-sim，虚拟智能卡)服务器。

其中，与第一服务器存在关联的应用组件可以为与第一服务器存在交互的应用组件。

在用户未使用应用组件时，即使应用组件存在异常，例如由于内存溢出等原因造成该应用组件对应的容器正常，但内部应用程序已停止工作，也无法检测到该应用组件存在异常，只有当用户使用到该应用组件，应用组件无法提供用户所请求的服务时，才能检测到该应用组件存在的异常，从而进行报警，以使相关人员采取相应的操作处理异常的应用组件。而本实施例中的第一服务器在用户还未使用应用组件时，便提前对应用组件进行提前检测，得到相应的检测结果，第二服务器根据各应用组件对应的检测结果判断各应用组件是否存在异常，若存在异常，则进行报警，以使相关维护人员在用户还未使用存在问题的应用组件时，便提前解决该应用组件存在的问题，从而使该应用组件可以在用户使用期间正常工作，满足用户的需求，避免出现在用户使用应用组件时才检测该应用组件存在异常导致无法满足用户的需求的情况。

通过获取第一服务器的运行信息和应用组件信息，根据运行信息进行相应的资源预估操作以及预估报警，根据应用组件信息提前检测各应用组件是否正产工作，若应用组件不能正常工作，则提前进行报警，从而保证在用户使用第一服务器时，第一服务器可以正常提供服务，满足用户的需求，实现对服务器的全面监控，保证服务器运行的健壮性以及稳定性。

下面以具体地实施例对本发明的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图2为本发明实施例提供的检测报警方法的流程图一，本实施例的方法中的执行主体可以为图1中的第一服务器。如图2所示，本实施例的方法，可以包括：

s201、获取第一服务器的性能信息，其中性能信息包括运行信息和应用组件信息，应用组件信息包括多个应用组件标识。

在本实施例中，第一服务器可以定期获取自身的性能信息，该性能信息包括运行信息和各应用组件对应的应用组件信息，运行信息包括内存使用量、cpu(centralprocessingunit，中央处理器)使用率、磁盘使用量、网络i/o(input/output，输入/输出)速率，磁盘i/o速率等。

其中，每个应用组件标识具有唯一性，可以表示其所对应的应用组件，例如，将应用组件的名称作为其对应的标识。

s202、将运行信息发送至第二服务器，以使第二服务器根据运行信息生成资源预测信息，并根据资源预测信息判断是否进行报警。

在本实施例中，将运行信息发送给第二服务器，当第二服务器接收到第一服务器对应的运行信息后，根据该运行信息预估第一服务器的资源是否存在达到规定的报警阈值的风险，若存在达到规定的报警阈值的风险，则进行报警，实现预估报警，以使维护人员可以提前对服务器进行维护，保证服务器运行的健壮性以及稳定性。

其中，第一服务器将运行信息发送给第二服务器的方式可以为：将所述运行信息发送至集群服务器，以使所述集群服务器将所述运行信息转发至所述第二服务器。

其中，集群服务器可以为zookeeper集群服务器。

在本实施例中，第一服务器通过dubbo服务将运行信息发送给zookeeper集群服务器，zookeeper集群服务器获取该第一服务器对应的第二服务器，将该第一服务器对应的运行信息发送至对应的第二服务器，从而保证处于不同域的服务器只需开通特定端口，便可实现数据的高效传输，从而保证报警的实时性。

第一服务器在通过zookeeper集群服务器转发数据前，需要通过dubbo服务在zookeeper集群服务器上进行注册，其注册过程与现有的注册过程类似，在此不再进行赘述。

第二服务器在通过zookeeper集群服务器接收数据前，也需要通过dubbo服务在zookeeper集群服务器上进行注册。

s203、检测各应用组件标识对应的应用组件是否正常运行，并生成各应用组件对应的检测结果。

在本实施例中，按照各应用组件对应的检测方式对对应的应用组件进行检测，检测其是否正常运行，生成各应用组件的检测结果。

其中，应用组件包括数据库组件，相应地，应用组件标识包括数据库组件标识。检测结果包括数据库组件正常运行结果。

不同的应用组件的类型所对应的检测方式不同，当应用组件的类型为报文验证类型时，则采用测试报文对对应的应用组件进行测试，当应用组件的类型为数据库类型时，则对对应的数据库组件执行指定的操作，以数据库组件是否正常运行，即检测数据库组件是否正常运行。

其中，检测数据库组件是否正常运行的过程可以为：获取数据库组件标识对应的数据库检测脚本，根据数据库检测脚本对数据库组件标识对应的数据库组件进行检测操作，得到检测操作结果，其中检测操作包括查询操作和/或增加操作，若检测操作结果与检测操作对应的预期操作结果相同，则确定数据库组件正常运行，并生成数据库组件正常运行结果。

在本实施例中，按照数据库检测脚本规定的检测方式，对对应的数据库组件进行检测操作，检测操作为常用的数据库操作，即检测数据库组件是否可以正常执行常用的数据库操作，得到相应的检测操作结果，若检测操作结果与执行的检测操作对应的预期操作结果相同，则确定数据库组件正常运行，并生成数据库组件正常运行结果，若操作结果与执行的检测操作对应的预期操作结果不相同，则确定数据库组件正常运行，并生成数据库组件异常结果。

其中，检测操作包括以下中的至少一种：查找操作、增加操作、删除操作、修改操作。

可选地，也可以获取数据库组件标识对应的jar(javaarchive)包，对对应的数据库组件进行检测，其规定对数据库组件进行检测时的检测方式。

上述数据库检测脚本和jar包仅是对应的类型不同，其所规定的检测方式是相同的，当通过外部的脚本或jar包检测数据库组件是否正常运行时，实现对服务器更加全面的监控，且由于检测所用的脚本或jar包是外部的，在使用时，只需进行调用即可，具有独立性和安全性，且方便对脚本和jar的维护、更新。

s204、将所有检测结果发送至第二服务器，以使第二服务器根据所有检测结果判断是否进行报警。

在本实施例中，将各个应用组件对应的检测结果发送到第二服务器，当第二服务器接收到各个应用组件对应的检测结果中，判断检测结果中是否存在需要进行报警的检测结果，若存在需要进行报警的检测结果，则进行报警，以使相关维护人员可以在用户使用存在异常的应用组件之前便可以提前处理存在异常的应用组件，解决其所存在的问题，使应用组件可以正常运行，正常提供服务，避免在用户使用应用组件而应用组件不能提供用户所请求的服务时，才能检测到该应用组件存在异常，相关维护人员才采取相应操作处理异常的应用组件，且在维护期间，该应用组件无法正常工作，无法满足用户需求的情况的出现。

可选地，将所有检测结果发送至集群服务器，以使集群服务器将所有检测结果转发至所述第二服务器。

在本实施例中，第一服务器也可以通过dubbo服务将各应用组件对应的检测结果发送至集群服务器，集群服务器获取该第一服务器对应的第二服务器，将该第一服务器对应的检测结果发送至对应的第二服务器，从而保证处于不同域的服务器只需开通特定端口，便可实现数据的高效传输。

第二服务器根据第一服务器的运行信息生成资源预测信息，实现对资源的预估操作，并根据资源预测信息判断是否需要进行预估报警，从而实现在第一服务器的资源未达到规定报警阈值，但存在达到规定报警阈值的风险时，便进行提取报警使相关维护人员提前进行维护，保障服务器可以在用户使用时，可以正常运行，且第二服务器在根据各应用组件对应的检测结果判断出存在工作异常的应用组件时，便进行报警，以使相关维护人员提前进行维护，保证用户在使用应用组件时，应用组件可以正常运行，通过根据运行信息和应用组件信息进行相应地检测操作，全面判断第一服务器的性能是否存在异常，若存在异常，便进行报警以使相关人员进行维护，保证服务器在用户使用时可以提供用户所需的服务，满足用户的需求，且可以减轻维护人员的压力，避免出现在故障发生后或在用户使用时，才发现故障导致服务器不能提供用户所需的服务的问题。

下面结合一个具体的实施例对类型为报文验证类型的应用组件进行检测的过程进行详细描述。

图3为本发明实施例提供的检测报警方法的流程图二，本实施例在图3实施例的基础上，对本实施例的具体实现过程进行了详细说明。如图3所示，该方法包括：

s301、获取第一服务器的性能信息，其中性能信息包括运行信息和应用组件信息，应用组件信息包括多个应用组件标识。

s302、将运行信息发送至第二服务器，以使第二服务器根据运行信息生成资源预测信息，并根据资源预测信息判断是否进行报警。

其中，本实施例的s301和s302的具体实施方式，与上述实施例中的s201和s202类似，此处不再赘述。

s303、从多个应用组件标识中选取测试应用组件标识。

在本实施例中，不同的应用组件的类型所对应的检测方式不同，当应用组件的类型为报文验证类型时，则采用测试报文对对应的应用组件进行测试，检测其是否存在异常，即从应用组件标识中选取类型为报文验证类型对应的应用组件标识，将选取的应用组件标识作为测试应用组件标识。

s304、获取测试应用组件标识对应的报文检测脚本。

在本实施例中，获取应用组件标识对应的报文检测脚本，该报文检测脚本是相关研发人员针对对应的应用组件标识所对应的应用组件编写的脚本，其规定对应用组件进行检测的检测方式。

可选地，也可以获取测试应用组件标识对应的jar包，对对应的测试应用组件进行检测，其规定对应用组件进行检测时的检测方式。

上述报文检测脚本和jar包仅是对应的类型不同，其所规定的检测方式是相同的，当通过外部的脚本或jar包检测应用组件是否正常运行时，实现对服务器更加全面的监控，且由于检测所用的脚本或jar包是外部的，在使用时，只需进行调用即可，具有独立性和安全性，且方便对脚本和jar的维护、更新。

s305、根据报文检测脚本发送测试报文至测试应用组件标识对应的测试应用组件，并接收测试应用组件返回的响应报文。

在本实施例中，可以定期利用不同的测试报文对应用组件的各方面进行测试，例如，测试应用组件提供的服务是否正常工作、应用组件使用的内存是否正常等。

其中，测试报文包括服务测试报文。

当测试应用组件提供的服务是否正常工作时，使用服务测试报文测试应用组件所提供的服务是否正常工作，其具体过程为：根据报文检测脚本发送服务测试报文至测试应用组件标识对应的测试应用组件，并接收测试应用组件返回的服务响应报文。

在本实施例中，第一服务器根据报文检测脚本规定的生成服务测试报文的方式生成相应的服务测试报文，将生成的服务测试报文发送给该报文检测脚本对应的测试应用组件，该测试应用组件在接收到该服务测试报文后，会生成相应的服务响应报文，并返回给第一服务器。

s306、根据响应报文判断测试应用组件是否正常运行，并生成对应的检测结果。

可选地，检测结果包括服务停止运行结果。相应地，步骤s306包括：判断响应报文是否与服务测试报文对应的预期服务停止运行响应报文相同，若服务响应报文与预期服务停止运行响应报文相同，则确定测试应用组件的服务停止运行，并生成服务停止运行结果。

在本实施例中，获取测试应用组件对应的预期响应报文，将测试应用组件返回的服务响应报文与预期的响应报文进行比对，确定与该服务响应报文相同的预期响应报文，将该预期响应报文对应的检测结果作为该测试应用组件对应的检测结果。例如，当发送服务测试报文给测试应用组件时，接收该测试应用组件返回的服务响应报文，基于该服务响应报文，检测该响应报文是否与预期服务停止运行响应报文相同，若相同，则获取该预期服务停止运行响应报文对应的检测结果，并将其作为该测试应用组件对应的检测结果，即生成服务停止运行结果。

s307、将所有检测结果发送至第二服务器，以使第二服务器根据所有检测结果判断是否进行报警。

本实施例的s307的具体实施方式，与上述实施例中的s204类似，此处不再赘述。

在本实施例中，通过测试报文对测试应用组件进行相应地测试，生成相应地检测结果，从而实现在用户使用测试应用组件前，便确定出测试应用组件是否存在异常，实现异常的提前检测。

图4为本发明实施例提供的检测报警方法的流程示意图三，本实施例的执行主体可以为图1所示实施例中的第二服务器。如图4所示，该方法包括：

s401、接收第一服务器发送的运行信息，其中运行信息是第一服务器在获取到自身的运行信息时发送的。

在本实施例中，第二服务器接收第一服务器发送的运行信息。运行信息包括内存使用量、cpu使用率、磁盘使用量、网络i/o速率，磁盘i/o速率等。

s402、根据运行信息生成资源预测信息，并根据资源预测信息判断是否进行报警。

在本实施例中，第二服务器根据运行信息预估第一服务器的资源达到规定阈值所需的时间，即生成对应的资源预测信息，并根据资源预测信息判断是否进行报警，实现资源的预估报警，以使相关维护人员在未发生故障前便可对服务器进行维护。

当运行信息为内存使用量时，则预估对应的内存预测时间，即预测内存使用量达到规定报警阈值所需的时间，若该时间过短，表示内存使用量过高，其可能存在达到报警阈值的风险，因此需要提前报警，以使相关人员对内存提前进行查找导致内存使用量不断升高的原因以采取相应地措施，提前进行维护。

在本实施例中，其它运行信息，例如cpu使用率、磁盘使用量、网络i/o速率，磁盘i/o速率也可按照对内存使用量进行预估报警的方式进行预估操作，检测是否需要预估报警，以使维护人员可以在异常发生前，提前进行维护。

403、接收第一服务器发送的所有检测结果，其中检测结果是由第一服务器获取包括多个应用组件标识的应用组件信息，在检测各应用组件标识对应的应用组件是否正常运行，并生成各应用组件对应的检测结果时发送的。

在本实施例中，接收第一服务器发送的各个应用组件对应的检测结果。

s404、根据所有检测结果判断是否进行报警。

在本实施例中，根据各个应用组件对应的检测结果判断是否进行报警，每个应用组件都存在报警结果集合，其中报警结果集合中包括多个报警结果，针对各个应用组件对应的检测结果，判断该应用组件对应的报警结果集合中是否存在与该应用组件对应的检测结果相同的报警结果，若该报警结果集合中存在与该检测结果相同的报警结果，则表示该检测结果为需要进行报警的结果，需要进行报警。

可选地，若所有检测结果中包括服务停止运行结果，则进行报警。

在进行报警之后，为了使相关维护人员可以尽快解决问题，在进行报警之后，还可以生成相应的报警信息发送至预设联系人，以使该预设联系人可以尽快处理报警，其具体过程为：获取服务停止运行结果对应的应用组件标识和服务标识，根据服务停止运行结果对应的应用组件标识和服务标识生成服务报警信息，并将服务报警信息发送至预设联系人。

在本实施例中，若某个应用组件对应的检测结果为服务停止运行结果，则表示该应用组件对应的容器正常，但内存应用程序已停止工作，不能正常提供服务，为了使维护人员尽快找到存在异常的应用组件，获取该服务停止运行结果对应的应用组件标识和服务标识，并按照预设报警格式生成相应的服务报警信息，将生成的服务报警信息发送给预设联系人。

其中，服务标识表示不能正常运行的服务的标识。

在将服务报警信息发送给预设联系人时，可以按照预设发送方式(例如，邮件)，将服务报警信息发送给预设联系人对应的终端。

在本实施例中，在确定出检测结果中还包括其它需要进行报警的检测结果，也可按照生成服务报警信息的过程，生成对应的报警信息发送给对应的预设联系人，以使维护人员可以尽快处理存在异常的应用组件。

在本实施例中，通过运行信息生成资源预测信息，实现对资源的预估操作，根据资源预测信息判断是否进行报警，在第一服务器中的相关资源(例如，内存使用量)未达到规定阈值时，便判断是否需要进行报警，实现资源预估报警，且在获取到第一服务器发送的各应用组件对应的检测结果，确定各应用组件对应的检测结果是否为需要进行报警的检测结果，若为需要进行报警的检测结果，则进行报警，实现对应用组件的提前检测以及提前报警，从而可以使相关人员在用户使用异常的应用组件前，便解决应用组件存在的问题，保证用户在使用应用组件时，应用组件可以正常为用户提供服务。

下面将采用一个具体实施例对生成资源预测信息的过程进行描述。

图5为本发明实施例提供的检测报警方法的流程示意图四，本实施例在图4实施例的基础上，对本实施例的具体实现过程进行了详细说明，运行信息包括当前内存使用量，资源预测信息包括内存预测时间，其中内存预测时间为预测内存使用量达到预设内存阈值所需的时间，如图5所示，该方法包括：

s501、将当前内存使用量保存至预设队列中，并获取预设队列中的内存使用量的总数量。

在本实施例中，当将接收到当前内存使用量保存至预设队列中后，获取预设队列中当前保存的内存使用量的总数量。

s502、若总数量大于预设数量阈值，则针对预设队列中的各个内存使用量，根据该内存使用量与该内存使用量的上一个内存使用量计算内存增长率。

当将内存使用量保存至队列中时，会有对应的保存时间，相应地，队列中保存的内存使用量是按照保存时间的顺序进行排列的，保存时间较晚的内存使用量在保存时间较早的内存使用量的上方。

在本实施例中，当预设队列中当前保存的内存使用量的总数量大于预设数量阈值时，获取预设队列中的各个内存使用量以及各个内存使用量对应的上一个内存使用量，针对各个内存使用量，将该内存使用量减去该内存使用量对应的上一个内存使用量得到内存增长值，将该内存增长值除以该上一个内存使用量，得到该内存使用量对应的内存增长率。

由于预设队列中排列在最上方的内存使用量并不存在上一个内存使用量，因此，无需计算该内存使用量对应的内存增长率。

为了提高预测的准确性，且为了减少计算量，在确定预设队列中的内存使用量的总数量大于预设数量阈值后，判断预设队列中的各个内存使用量是否均大于预设值，若均大于预设值，则再按照上述计算过程计算各个内存使用量对应的内存增长率。

其中，内存使用量对应的上一个内存使用量表示与该内存使用量相邻，且在该内存使用量的上方的内存使用量。

s503、若计算出的内存增长率依次增加，则根据计算出的内存增长率计算内存预测增长率。

在本实施例中，按照各个内存增长率对应的内存使用量的排列对顺序内存增长率进行排列，即保存时间较晚的内存使用量对应的内存增长率在保存时间较早的内存使用量对应的内存增长率的上方。获取各内存增长率对应的上一个内存增长率，判断各内存增长率是否小于其所对应的上一个内存增长率，若各个内存增长率均小于其所对应的上一个内存增长率，则确定内存增长率依次增加，第一服务器的内存使用量有可能会达到报警阈值。然后根据内存增长率计算出相应地内存预测增长率，例如，共有a、b和c三个内存增长率，b为a的上一个内存增长率，c为b的上一个内存增长率，若b大于a，且c大于b，则确定内存增长率持续增加。

其中内存增长率的上一个内存增长率表示与该内存增长率相邻，且在该内存增长率的上方的内存增长率。

其中，计算内存预测增长率的过程可以为：从计算出的内存增长率中选取预设数量的内存增长率，根据预设数量的内存增长率和预设的平均加权算法计算内存预测增长率。

在本实施例中，为了提高预测准确性，可以选取保存时间较近的内存增长量对应的内存增长率进行平均加权计算，得到内存预测增长率。

其中，保存时间较近的内存增长量可以为预设队列中排名在预设排名上方的内存增长量。

可选地，还可以在预设队列中的各个内存使用量均小于其对应的上一个内存使用量时，选取保存时间较近的内存使用量计算各个保存时间较近的内存使用量各自对应的内存增长率，并根据计算出的内存增长率计算内存预测增长率。

s504、根据内存预测增长率计算第一服务器对应的内存预测时间。

可选地，计算内存预测时间的过程可以为：根据预设队列中的内存使用量得到目标内存使用量，根据目标内存使用量、内存预测增长率、预设的内存报警阈值和预设的内存预测公式，得到内存预测时间。

在本实施例中，可以利用平均法，确定出目标内存使用量，即从预设队列中选取第二预设数量的内存使用量，并计算该第二预设数量的内存使用量的平均值，并作为目标内存使用量。为了减少工作量，也可以直接将预设队列中的最上方的内存使用量作为目标内存使用量，即将保存时间最近的内存使用量作为目标内存使用量。

将目标内存使用量、内存预测增长率和预测的内存报警阈值代入预设的内存预测公式中，得到内存预测时间，其中，预设的内存预测公式可以为：a*(1+s)^t＝t，其中a为目标内存使用量，s为内存预测增长率、t为内存预测时间，t为内存告警阈值。

其中，内存告警阈值表示当内存使用量达到该值后，便进行告警。

其中，内存预测时间表示预测内存使用量达到预设内存阈值所需的时间。

在计算出内存预测时间后，若内存预测时间小于预设的内存预测时间阈值，则进行报警。

在本实施例中，当第一服务器的内存预测时间小于预设的内存预测时间阈值时，表示内存使用量过高，存在达到报警阈值的风险，因此，需要进行报警，以使相关维护人员提前释放该第一服务器的内存，让服务器健壮的运行。

在本实施例中，根据实际的内存使用量计算出内存预测增长率，并根据内存预测增长率计算第一服务器对应的内存预测时间，实现预估操作，且保证内存预测时间的计算准确性，若内存预测时间小于预设的内存预测时间阈值，则进行报警，实现在服务器资源未达到规定阈值时便进行预估报警，可以使相关维护人员查找内存不断升高的原因，提前对服务器进行维护，避免出现服务器发生故障后再进行维护导致服务器不能正常提供服务的情况。

图6为本发明实施例提供的检测报警设备的结构示意图一，本实施例中的检测报警设备600应用于第一服务器，如图6所示，其可以包括：性能信息获取模块601、运行信息处理模块602、应用组件检测模块603和检测结果发送模块604。

其中，性能信息获取模块601，用于获取第一服务器的性能信息，其中性能信息包括运行信息和应用组件信息，应用组件信息包括多个应用组件标识。

运行信息处理模块602，用于将运行信息发送至第二服务器，以使第二服务器根据运行信息生成资源预测信息，并根据资源预测信息判断是否进行报警。

应用组件检测模块603，用于检测各应用组件标识对应的应用组件是否正常运行，并生成各应用组件对应的检测结果。

检测结果发送模块604，用于将所有检测结果发送至第二服务器，以使第二服务器根据所有检测结果判断是否进行报警。

在一种可能的设计中，应用组件检测模块包括：

测试组件选取单元，用于从多个应用组件标识中选取测试应用组件标识。

检测脚本获取单元，用于获取测试应用组件标识对应的报文检测脚本。

报文检测单元，用于根据报文检测脚本发送测试报文至测试应用组件标识对应的测试应用组件，并接收测试应用组件返回的响应报文。

结果生成单元，用于根据响应报文判断测试应用组件是否正常运行，并生成对应的检测结果。

在一种可能的设计中，测试报文包括服务测试报文，响应报文包括服务响应报文，检测结果包括服务停止运行结果。

报文检测单元具体用于：

根据报文检测脚本发送服务测试报文至测试应用组件标识对应的测试应用组件，并接收测试应用组件返回的服务响应报文。

相应地，结果生成单元具体用于：判断服务响应报文是否与服务测试报文对应的预期服务停止运行响应报文相同。若服务响应报文与预期服务停止运行响应报文相同，则确定测试应用组件的服务停止运行，并生成服务停止运行结果。

在一种可能的设计中，应用组件标识包括数据库组件标识，检测结果包括数据库组件正常运行结果。

应用组件检测模块包括：

数据库检测脚本获取单元，用于获取数据库组件标识对应的数据库检测脚本。

操作结果生成单元，用于根据数据库检测脚本对数据库组件标识对应的数据库组件进行检测操作，得到检测操作结果。其中检测操作包括查询操作和/或增加操作。

操作结果处理单元，用于若检测操作结果与检测操作对应的预期操作结果相同，则确定数据库组件正常运行，并生成数据库组件正常运行结果。

在一种可能的设计中，运行信息处理模块具体用于：

将运行信息发送至集群服务器，以使集群服务器将运行信息转发至第二服务器。

本发明实施例提供的检测报警设备，可以实现上述如图2和图3所示的实施例的检测报警方法，其实现原理和技术效果类似，此处不再赘述。

图7为本发明实施例提供的检测报警设备的结构示意图二，本实施例提供的检测报警设备700应用于第二服务器，如图7所示，其可以包括：运行信息接收模块701、预测信息生成模块702、检测结果接收模块703和检检测结果处理模块704。

其中，运行信息接收模块701，用于接收第一服务器发送的运行信息，其中运行信息是第一服务器在获取到自身的运行信息时发送的。

预测信息生成模块702，用于根据运行信息生成资源预测信息，并根据资源预测信息判断是否进行报警。

检测结果接收模块703，用于接收第一服务器发送的所有检测结果，其中检测结果是由第一服务器获取包括多个应用组件标识的应用组件信息，在检测各应用组件标识对应的应用组件是否正常运行，并生成各应用组件对应的检测结果时发送的。

检测结果处理模块704，用于根据所有检测结果判断是否进行报警。

在一种可能的设计中，运行信息包括当前内存使用量。资源预测信息包括内存预测时间，其中内存预测时间为预测内存使用量达到预设内存阈值所需的时间。

预测信息生成模块包括：

总数量获取单元，用于将当前内存使用量保存至预设队列中，并获取预设队列中的内存使用量的总数量。

内存增长率计算单元，用于若总数量大于预设数量阈值，则针对预设队列中的各个内存使用量，根据该内存使用量与该内存使用量的上一个内存使用量计算内存增长率。

预测增长率计算单元，用于若计算出的内存增长率依次增加，则根据计算出的内存增长率计算内存预测增长率。

内存预测时间计算单元，用于根据内存预测增长率计算第一服务器对应的内存预测时间。

在一种可能的设计中，内存增长率计算单元具体用于：从计算出的内存增长率中选取预设数量的内存增长率。根据预设数量的内存增长率和预设的平均加权算法计算内存预测增长率。

在一种可能的设计中，内存预测时间计算单元具体用于：根据预设队列中的内存使用量得到目标内存使用量。

根据目标内存使用量、内存预测增长率、预设的内存报警阈值和预设的内存预测公式，得到内存预测时间。

在一种可能的设计中，预测信息生成模块具体用于：若内存预测时间小于预设的内存预测时间阈值，则进行报警。

在一种可能的设计中，检测结果处理模块具体用于：若所有检测结果中包括服务停止运行结果，则进行报警。

在一种可能的设计中，检测结果处理模块还用于：在若所有检测结果中包括服务停止运行结果，则进行报警之后，获取服务停止运行结果对应的应用组件标识和服务标识。根据服务停止运行结果对应的应用组件标识和服务标识生成服务报警信息，并将服务报警信息发送至预设联系人。

本发明实施例提供的检测报警设备，可以实现上述如图4和图5所示的实施例的检测报警方法，其实现原理和技术效果类似，此处不再赘述。

图8为本发明实施例提供的服务器的硬件结构示意图。如图8所示，本实施例提供的服务器800包括：至少一个处理器801和存储器802。其中，处理器801、存储器802通过总线803连接。

在具体实现过程中，至少一个处理器801执行所述存储器802存储的计算机执行指令，使得至少一个处理器801执行上述方法实施例中的检测报警方法。

处理器801的具体实现过程可参见上述方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。

在上述的图8所示的实施例中，应理解，处理器可以是中央处理单元(英文：centralprocessingunit，简称：cpu)，还可以是其他通用处理器、数字信号处理器(英文：digitalsignalprocessor，简称：dsp)、专用集成电路(英文：applicationspecificintegratedcircuit，简称：asic)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速ram存储器，也可能还包括非易失性存储nvm，例如至少一个磁盘存储器。

总线可以是工业标准体系结构(industrystandardarchitecture，isa)总线、外部设备互连(peripheralcomponent，pci)总线或扩展工业标准体系结构(extendedindustrystandardarchitecture，eisa)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现上述方法实施例的检测报警方法。

上述的计算机可读存储介质，上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(applicationspecificintegratedcircuits，简称：asic)中。当然，处理器和可读存储介质也可以作为分立组件存在于设备中。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。