服务器状态检测方法和装置
技术领域
本发明涉及计算机领域,具体而言,涉及一种服务器状态检测方法和装置。
背景技术
如今,用户通常通过客户端访问业务服务器上提供的业务,为了保证用户可以及时地从业务服务器获取正确的业务信息,需要不断地检测业务服务器的状态,例如,检测业务服务器自身的负荷情况或是否收到非法的攻击等,以保证业务服务器能够及时响应客户端发送的访问请求。
目前,通常采用以下检测方法来检测业务服务器的状态:
S1:采集并统计业务服务器中的各项性能参数,例如,网络连接数、内存/CPU使用率、IO负载等;
S2:根据上述各项性能参数来进行综合判定业务服务器的状态是否出现异常。
然而,在上述的检测方法中仅通过业务服务器本机检测得到的数据进行状态的判断,而没有考虑客户端与业务服务器之间的网络情况,这样大大降低业务服务器的状态的判断准确性。
针对上述的问题,目前尚未提出有效的解决方案。
发明内容
本发明实施例提供了一种服务器状态检测方法和装置,以至少解决现有技术中仅基于服务器本机进行状态检测所导致的检测不准确的技术问题。
根据本发明实施例的一个方面,提供了一种服务器状态检测方法,包括:生成与待检测服务器的配置参数对应的测试任务;将上述测试任务发送到分布式部署的多个检测客户端;接收上述多个检测客户端返回的对上述待检测服务器执行上述测试任务的测试结果;根据上述多个检测客户端返回的上述测试结果判断上述待检测服务器的状态。
根据本发明实施例的另一方面,还提供了一种服务器状态检测装置,包括:生成单元,用于生成与待检测服务器的配置参数对应的测试任务;发送单元,用于将上述测试任务发送到分布式部署的多个检测客户端;接收单元,用于接收上述多个检测客户端返回的对上述待检测服务器执行上述测试任务的测试结果;判断单元,用于根据上述多个检测客户端返回的上述测试结果判断上述待检测服务器的状态。
在本发明实施例中,通过将与待检测服务器的配置参数相对应的测试任务下发至分布式部署的多个检测客户端,根据上述多个检测客户端返回的测试结果来判断上述待检测服务器的状态是否处于正常,从而避免了现有技术中仅基于服务器本机进行状态检测所导致的检测不准确的技术问题,从而实现了从分布式部署的检测客户端的角度识别待检测服务器的状态,提高了状态检测的准确性。
此外,采用基于历史参考值对多个检测客户端所返回的测试结果进行比较分析的方式,实现了对上述待检测服务器的状态地有效检测,进一步提高待测服务器的状态检测的准确性。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1是根据本发明实施例的一种可选的服务器状态检测***的示意图;
图2是根据本发明实施例的一种可选的服务器状态检测方法的流程图;
图3是根据本发明实施例的另一种可选的服务器状态检测方法的流程图;
图4是根据本发明实施例的又一种可选的服务器状态检测方法的流程图;
图5是根据本发明实施例的又一种可选的服务器状态检测方法的流程图;
图6是根据本发明实施例的一种可选的服务器状态检测装置的示意图;以及
图7是根据本发明实施例的一种可选的服务器状态检测装置的示意图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分的实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本发明保护的范围。
需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
实施例1
根据本发明实施例,提供了一种服务器状态检测方法,上述方法可以应用于如图1所示的检测***中,其中,上述***可以包括但不限于:业务服务器102、检测客户端104-1至检测客户端104-4、服务器状态检测控制***106,其中,在本实施例中上述服务器状态检测控制***106可以包括但不限于:数据采集与处理模块108、分析模块110、结果输出模块112、探测策略管理与配置模块114、业务基础信息库116。可选地,在本实施例中,上述服务器状态检测控制***106中的各个模块可以集成在一个网络设备中,也可以分布式地位于不同的网络设备中。
可选地,在本实施例中,上述检测客户端104-1至检测客户端104-4与业务服务器102可以但不限于分布式地部署在不同的位置。例如,检测客户端104-1位于北京,检测客户端104-2位于上海,检测客户端104-3位于广州,检测客户端104-3位于成都,业务服务器102位于大连。通过多个不同位置的检测客户端对业务服务器进行全面的状态测试。
进一步,上述检测客户端的个数和所处的位置仅是一个示例,本实施例对此不做限定,可以根据实际地检测需求增加检测客户端的个数和/或调整检测客户端所处的位置。
可选地,在本实施例中,如图2所示,上述服务器状态检测方法可以包括:
S202,生成与待检测服务器的配置参数对应的测试任务;
S204,将测试任务发送到分布式部署的多个检测客户端;
S206,接收多个检测客户端返回的对待检测服务器执行测试任务的测试结果;
S208,根据多个检测客户端返回的测试结果判断待检测服务器的状态。
可选地,在本实施例中,待检测服务器的配置参数可以包括但不限于以下至少之一:协议类型、开放端口、操作***、开放服务和***控制策略。
可选地,在本实施例中,与待检测服务器的配置参数对应的测试任务可以事先约定,例如,约定测试数据包和测试响应数据包中的内容。
可选地,在本实施中,对待检测服务器生成的测试任务可以但不限于:基于不同的业务类型生成不同的测试任务、基于服务器的不同特性生成不同的测试任务。其中,上述业务类型可以包括但不限于:TCP/UDP server、WEB server、DNS server。其中,上述服务器的特性可以包括但不限于:PING延迟、端口连通率、生存时间(TTL,Time To Live)、HTTP返回码。可选地,在本实施例中,为待检测服务器生成的测试任务可以是用于测试上述待检测服务器在针对同一任务时的不同特性,也可以是用于测试上述待检测服务器在针对不同任务时的同一特性。
例如,结合图1所示,检测客户端104-1在1小时内向业务服务器102发送了1000个请求执行业务(例如,TCP/UDP server)的测试数据包,然而,从业务服务器102只接收到850个测试响应数据包。也就是说,检测客户端104-1向业务服务器102请求业务的连通率为85%。同理,可以获得检测客户端104-2向业务服务器102请求业务的连通率为80%,检测客户端104-3向业务服务器102请求业务的连通率为90%,检测客户端104-4向业务服务器102请求业务的连通率为75%,如表1所示。
又例如,例如,结合图1所示,检测客户端104-1向业务服务器102发送请求业务(例如,TCP/UDP server)的测试数据包的时间为10:00,而接收到由业务服务器102发送的测试响应数据包的时间为10ms后,即,检测客户端104-1检测到的请求延时为10ms。同理,可以获得检测客户端104-2向业务服务器102请求业务的延时为8ms,检测客户端104-3向业务服务器102请求业务的延时为6ms,检测客户端104-4向业务服务器102请求业务的延时为12ms,如表1所示。
表1
检测客户端 |
连通率 |
延时(单位:ms) |
检测客户端104-1 |
85% |
10 |
检测客户端104-2 |
80% |
8 |
检测客户端104-3 |
90% |
6 |
检测客户端104-4 |
75% |
12 |
可选地,在本实施例中,用于检测待检测服务器的测试技术可以包括但不限于:TCP探测、UDP探测、IMCP探测。
可选地,在本实施例中,上述测试任务被发送到分布式部署的多个检测客户端104中的方式可以包括但不限于:并行发送。例如,如图1所示,建立检测客户端104-1用于向待检测服务器(例如,业务服务器102)发送测试数据包的多个进程或线程,则可以实现检测客户端104-1向业务服务器102并行地发送多个测试数据包,提高了服务器状态检测的检测速度。
可选地,在本实施例中根据上述多个检测客户端返回的测试结果,判断上述待检测服务器的状态的方式可以包括但不限于:将测试结果中的结果参数与历史参考值进行比较,通过判断二者之间的差值是否大于预定阈值,判断上述待检测服务器的是否处于正常状态。
可选地,在本实施例中,将根据待检测服务器的实时变化,实时更新已保存的上述待检测服务器的配置参数。
可选地,在本实施例中,结合图1所示的服务器状态检测***,上述检测方法的执行流程可以如图3所示:
S302,探测策略管理与配置模块114从业务信息库116中获取待检测服务器(例如,业务服务器102)的相关信息(例如,配置参数,包括但不限于协议类型、开放端口、操作***、开放服务和***控制策略);
S304,探测策略管理与配置模块114将生成的与待检测服务器(例如,业务服务器102)的配置参数对应的测试任务,并下发至分布式部署的多个检测客户端104;
S306,待检测服务器执行测试任务,并由数据采集与处理模块108采集测试数据;
S308,将多个检测客户端执行完测试任务后的测试数据返回至分析模块110;
S310,将分析后的测试记过反馈给探测策略管理与配置模块114,判断待检测服务器的状态是否正常。
S312,对业务信息库116中的数据进行更新。可选地,可以根据反馈的结果更新业务信息库中记载的与待检测服务器对应的信息,例如,业务服务器102的状态信息。
通过本发明提供的实施例,通过将与待检测服务器的配置参数相对应的测试任务下发至分布式部署的多个检测客户端,由上述多个检测客户端返回的测试结果进行综合分析,来判断上述待检测服务器的状态是否处于正常,从而避免了现有技术中仅从服务器本机进行状态检测所导致的检测不准确的问题,从分布式部署的检测客户端的角度识别待检测服务器的状态,提高了状态检测的准确性。
作为一种可选的方案,步骤S208,根据多个检测客户端返回的测试结果判断待检测服务器的状态包括:
S1,判断测试结果中的结果参数与对应的历史参考值之间的差值是否大于预定阈值,其中,历史参考值是对待检测服务器已执行的多次在先测试任务所得到的在先测试结果进行统计得到的;
S2,若差值大于预定阈值,则判断出待检测服务器处于异常状态;否则,判断出待检测服务器处于正常状态。
可选地,在本实施例中,已执行的在先测试任务统计后得到的历史参考值可以为但不限于:多次在先测试结果的平均值、多次在先测试结果的期望值。可选地,在本实施例中,测试结果中的测试参数可以为但不限于:多个检测客户端测试结果的平均值、多个检测客户端测试结果的期望值。
可选地,在本实施例中,与测试结果中的结果参数和对应的历史参考值之间的差值比较的预定阈值,在不同的应用场景下可以预先配置相同或不同的取值,本实施例对此不做任何限定。
例如,结合图1所示,检测客户端在1小时内向业务服务器102发送了请求执行业务(例如,TCP/UDP server)的测试数据包,假设业务服务器102的连通率的历史参考值为80%,而经多个检测客户端返回的测试结果可知,检测客户端104-1向业务服务器102请求业务的连通率为85%,检测客户端104-2向业务服务器102请求业务的连通率为80%,检测客户端104-3向业务服务器102请求业务的连通率为90%,检测客户端104-4向业务服务器102请求业务的连通率为75%。假设将多个检测客户端的测试结果的平均值作为最终测试结果,则上述对于业务服务器102关于业务TCP/UDP server的连通率为82.5%。
进一步,判断由上述多个检测客户端得到的最终测试结果中的测试参数连通率(例如,连通率为82.5%)与历史参考值(例如,历史参考值为80%)之间的差值为2.5%,假设本实施例中设定的预定阈值为2%,则可以判断出上述差值大于预定阈值2%,则判断出上述业务服务器处于异常状态。
通过本发明提供的实施例,通过对测试结果中的结果参数与对应的历史参考值之间的差值进行判断,以实现基于历史参考值对测试结果进行分析,进而达到判断出待检测服务器的状态是否正常的目的,实现了对上述待检测服务器的状态地有效检测,进一步提高待测服务器的状态检测的准确性。
作为一种可选的方案,如图4所示,在步骤S202,生成与待检测服务器的配置参数对应的测试任务之前,还包括:
S402,对待检测服务器执行多次在先测试任务,得到在先测试结果;
S404,统计在先测试结果得到与不同的结果参数对应的历史参考值。
以下结合具体示例说明,结合图1所示,在本实施例中,上述测试任务用于检测客户端向业务服务器102请求执行业务(例如,TCP/UDPserver)的连通率。进一步,上述检测客户端104-1至检测客户端104-4在10:00-11:00、12:00-13:00、14:00-15:00对业务服务器102执行了三次在先测试任务,并得到如表2所示的每个检测客户端每次的测试结果(例如,连通率)以及计算所得的多个检测客户端每次测试得到的连通率的平均值。
表2
如表2所示,由上述统计在先测试结果得到的连通率的历史参考值可以但不限于为上述检测客户端多次测试结果的平均值,其中,上述检测客户端每次的测试结果可以但不限于为多个检测客户端的测试结果的平均值。例如,统计第一次测试得到的连通率为检测客户端104-1至检测客户端104-4的测试结果的平均值85%,进一步,第二次测试得到的连通率为82.5%,第三次测试得到的连通率为83.75%,则业务服务器102关于业务TCP/UDP server的连通率的历史参考值为(85%+82.5%+83.75%)/3=83.75%。
通过本发明提供的实施例,通过建立历史参考值,使得服务器状态检测可以基于历史参考值进行分析,实现了对上述待检测服务器的状态地有效检测,进一步提高待测服务器的状态检测的准确性。。
作为一种可选的方案,如图5所示,在将测试任务发送到分布式部署的多个检测客户端之后,以及在接收多个检测客户端返回的对待检测服务器执行测试任务的测试结果之前,多个检测客户端中的每一个(例如,检测客户端104-1)都将执行以下操作:
S502,生成与测试任务对应的测试数据包;
S504,将测试数据包发送给待检测服务器(例如,业务服务器102);
S506,接收到待检测服务器返回的响应于测试数据包的测试结果响应信息;
S508,根据测试结果响应信息生成测试结果。
可选地,在本实施例中应用于服务器状态检测的多个检测客户端中的每个检测客户端都会将由待检测服务器接收到的测试结果进行反馈。
可选地,在本实施例中,对多个检测客户端中的每个检测客户端反馈的测试结果进行统计,可选地,在本实施例中,统计的方式可包括但不限于:计算多个检测客户端的测试结果的期望值、计算多个检测客户端测试结果的平均值。
以下结合具体示例说明,结合图1以及表2中第一列所示,在本实施例中,上述测试任务用于检测客户端向业务服务器102请求执行业务(例如,TCP/UDP server)的连通率。多个检测客户端中的每一个(例如,检测客户端104-1)都将生成与连通率测试的测试任务对应的测试数据包,并将上述测试数据包发送给业务服务器102,然后,上述检测客户端将接收到业务服务器102返回的响应于测试数据包的测试结果响应信息,例如,检测客户端104-1接收到与业务服务器102的连通率为85%,检测客户端104-3接收到与业务服务器102的连通率为80%,检测客户端104-3接收到与业务服务器102的连通率为90%,检测客户端104-4接收到与业务服务器102的连通率为85%。最后,上述检测客户端将根据多个检测客户端得到的测试结果响应信息生成如表2所示的测试结果,例如,多个检测客户端的连通率的平均值为85%。
通过本发明提供的实施例,通过基于网络中的多个检测客户端进行对待检测服务器的状态检测,避免了现有技术中仅基于服务器本机进行状态检测所导致的检测不准确的问题,从而实现了通过从分布式部署的检测客户端的角度识别待检测服务器的状态,提高了状态检测的准确性。
作为一种可选的方案,多个检测客户端将测试数据包发送给待检测服务器包括:
S1,多个检测客户端并行地将测试数据包发送给待检测服务器。
可选地,在本实施例中,多个检测客户端中的每一个检测客户端均可以但不限于建立多个进程或线程。例如,结合图1所示,检测客户端104-1可以向业务服务器102并行发送多个测试数据包,同时测试业务服务器102关于某个业务的多个特性,或者,同时测试多个业务服务器中的多个业务的某个特性。
通过本发明提供的实施例,多个检测客户端通过并行发送测试数据包的方式,进而实现了提高对待检测服务器的状态检测的检测速度。
作为一种可选的方案,在多个检测客户端将测试数据包发送给待检测服务器之后,还包括:
S1,若判断出待检测服务器处于异常状态,则设置防护配置参数,其中,防护配置参数用于过滤掉部分发送到待检测服务器的数据包。
可选地,在本实施例中的防护配置参数可以但不限于包括:客户端所发送的数据包的数量、业务服务器所接收的数据包的数量。可选地,在本实施例中,过滤部分发送到待检测服务器的数据包的方式可以包括但不限于:限制指定客户端在单位时间内所发送的数据包的数量在预定阈值范围内、屏蔽指定客户端的IP地址、限制待检测服务器在单位时间内所接收的数据包的数量。
例如,结合图1所示,当判断出待检测服务器(例如,业务服务器102)处于异常状态,则修改设置上述业务服务器102的防护配置参数以实现过滤掉部分发送到业务服务器102的数据包。其中,过滤数据包的方式可以如下:
1)假设检测客户端104-1在单位时间内所发送的数据包的数量过大(例如,5000个/小时),则可以限制检测客户端104-1在单位时间内发送的数据包的数量小于1000个,则大于1000个的数据包都将被过滤掉。
2)假设检测客户端104-1在单位时间内所发送的数据包的数量过大(例如,5000个/小时),则可以直接屏蔽上述检测客户端104-1的IP地址,进而实现过滤掉检测客户端104-1所发送的全部数据包。
3)假设业务服务器102在单位时间内所接收到的数据包的数量过大(例如,8000个/小时),则可以限制检测客户端104-1在单位时间内发送的数据包的数量小于5000个,例如,将发送来的数据包进行随机的丢弃,以实现过滤掉较大数量的数据包。
通过本发明提供的实施例,通过将处于异常状态的待检测服务器的防护配置参数进行设置,以使上述待检测服务器保持在比较健康的运行状态。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本发明并不受所描述的动作顺序的限制,因为依据本发明,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本发明所必须的。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
实施例2
根据本发明实施例,还提供了一种用于实施上述方法的服务器状态检测装置,上述装置可以应用于如图1所示的检测***中,其中,上述***可以包括但不限于:业务服务器102、检测客户端104-1至检测客户端104-4、服务器状态检测控制***106,其中,在本实施例中上述服务器状态检测控制***106可以包括但不限于:数据采集与处理模块108、分析模块110、结果输出模块112、探测策略管理与配置模块114、业务基础信息库116。可选地,在本实施例中,上述服务器状态检测控制***106中的各个模块可以集成在一个网络设备中,也可以分布式地位于不同的网络设备中。
可选地,在本实施例中,上述检测客户端104-1至检测客户端104-4与业务服务器102可以但不限于分布式地部署在不同的位置。例如,检测客户端104-1位于北京,检测客户端104-2位于上海,检测客户端104-3位于广州,检测客户端104-3位于成都,业务服务器102位于大连。通过多个不同位置的检测客户端对业务服务器进行全面的状态测试。
进一步,上述检测客户端的个数和所处的位置仅是一个示例,本实施例对此不做限定,可以根据实际地检测需求增加检测客户端的个数和/或调整检测客户端所处的位置。
可选地,在本实施例中,如图6所示,在本实施例中该装置包括:
1)生成单元602,用于生成与待检测服务器的配置参数对应的测试任务;
2)发送单元604,用于将测试任务发送到分布式部署的多个检测客户端;
3)接收单元606,用于接收多个检测客户端返回的对待检测服务器执行测试任务的测试结果;
4)判断单元608,用于根据多个检测客户端返回的测试结果判断待检测服务器的状态。
可选地,在本实施例中,待检测服务器的配置参数可以包括但不限于以下至少之一:协议类型、开放端口、操作***、开放服务和***控制策略。
可选地,在本实施例中,与待检测服务器的配置参数对应的测试任务可以事先约定,例如,约定测试数据包和测试响应数据包中的内容。
可选地,在本实施中,对待检测服务器生成的测试任务可以但不限于:基于不同的业务类型生成不同的测试任务、基于服务器的不同特性生成不同的测试任务。其中,上述业务类型可以包括但不限于:TCP/UDP server、WEB server、DNS server。其中,上述服务器的特性可以包括但不限于:PING延迟、端口连通率、生存时间(TTL,Time To Live)、HTTP返回码。可选地,在本实施例中,为待检测服务器生成的测试任务可以是用于测试上述待检测服务器在针对同一任务时的不同特性,也可以是用于测试上述待检测服务器在针对不同任务时的同一特性。
例如,结合图1所示,检测客户端104-1在1小时内向业务服务器102发送了1000个请求执行业务(例如,TCP/UDP server)的测试数据包,然而,从业务服务器102只接收到850个测试响应数据包。也就是说,检测客户端104-1向业务服务器102请求业务的连通率为85%。同理,可以获得检测客户端104-2向业务服务器102请求业务的连通率为80%,检测客户端104-3向业务服务器102请求业务的连通率为90%,检测客户端104-4向业务服务器102请求业务的连通率为75%,如表3所示。
又例如,例如,结合图1所示,检测客户端104-1向业务服务器102发送请求业务(例如,TCP/UDP server)的测试数据包的时间为10:00,而接收到由业务服务器102发送的测试响应数据包的时间为10ms后,即,检测客户端104-1检测到的请求延时为10ms。。同理,可以获得检测客户端104-2向业务服务器102请求业务的延时为8ms,检测客户端104-3向业务服务器102请求业务的延时为6ms,检测客户端104-4向业务服务器102请求业务的延时为12ms,如表3所示。
表3
检测客户端 |
连通率 |
延时(单位:ms) |
检测客户端104-1 |
85% |
10 |
检测客户端104-2 |
80% |
8 |
检测客户端104-3 |
90% |
6 |
检测客户端104-4 |
75% |
12 |
可选地,在本实施例中,用于检测待检测服务器的测试技术可以包括但不限于:TCP探测、UDP探测、IMCP探测。
可选地,在本实施例中,上述测试任务被发送到分布式部署的多个检测客户端104中的方式可以包括但不限于:并行发送。例如,如图1所示,建立检测客户端104-1用于向待检测服务器(例如,业务服务器102)发送测试数据包的多个进程或线程,则可以实现检测客户端104-1向业务服务器102并行地发送多个测试数据包,提高了服务器状态检测的检测速度。
可选地,在本实施例中根据上述多个检测客户端返回的测试结果,判断上述待检测服务器的状态的方式可以包括但不限于:将测试结果中的结果参数与历史参考值进行比较,通过判断二者之间的差值是否大于预定阈值,判断上述待检测服务器的是否处于正常状态。
可选地,在本实施例中,将根据待检测服务器的实时变化,实时更新已保存的上述待检测服务器的配置参数。
通过本发明提供的实施例,通过将与待检测服务器的配置参数相对应的测试任务下发至分布式部署的多个检测客户端,由上述多个检测客户端返回的测试结果进行综合分析,来判断上述待检测服务器的状态是否处于正常,从而避免了现有技术中仅从业务服务器本机进行状态检测所导致的检测不准确的问题,从分布式部署的检测客户端的角度识别待检测服务器的状态,提高了状态检测的准确性。
作为一种可选的方案,判断单元608包括:
1)判断模块,用于判断测试结果中的结果参数与对应的历史参考值之间的差值是否大于预定阈值,其中,历史参考值是对待检测服务器已执行的多次在先测试任务所得到的在先测试结果进行统计得到的;若差值大于预定阈值,则判断出待检测服务器处于异常状态;否则,判断出待检测服务器处于正常状态。
可选地,在本实施例中,已执行的在先测试任务统计后得到的历史参考值可以为但不限于:多次在先测试结果的平均值、多次在先测试结果的期望值。可选地,在本实施例中,测试结果中的测试参数可以为但不限于:多个检测客户端测试结果的平均值、多个检测客户端测试结果的期望值。
可选地,在本实施例中,与测试结果中的结果参数和对应的历史参考值之间的差值比较的预定阈值,在不同的应用场景下可以预先配置相同或不同的取值,本实施例对此不做任何限定。
例如,结合图1所示,检测客户端在1小时内向业务服务器102发送了请求执行业务(例如,TCP/UDP server)的测试数据包,假设业务服务器102的连通率的历史参考值为80%,而经多个检测客户端返回的测试结果可知,检测客户端104-1向业务服务器102请求业务的连通率为85%,检测客户端104-2向业务服务器102请求业务的连通率为80%,检测客户端104-3向业务服务器102请求业务的连通率为90%,检测客户端104-4向业务服务器102请求业务的连通率为75%。假设将多个检测客户端的测试结果的平均值作为最终测试结果,则上述对于业务服务器102关于业务TCP/UDP server的连通率为82.5%。
进一步,判断由上述多个检测客户端得到的最终测试结果中的测试参数连通率(例如,连通率为82.5%)与历史参考值(例如,历史参考值为80%)之间的差值为2.5%,假设本实施例中设定的预定阈值为2%,则可以判断出上述差值大于预定阈值2%,则判断出上述业务服务器处于异常状态。
通过本发明提供的实施例,通过对测试结果中的结果参数与对应的历史参考值之间的差值进行判断,以实现基于历史参考值,对测试结果进行分析,进而达到判断出待检测服务器的状态是否正常的目的,实现了对上述待检测服务器的状态地有效检测,进一步提高待测服务器的状态检测的准确性。
作为一种可选的方案,如图7所示,在本实施例中该装置还包括:
1)测试单元702,用于在生成与所述待检测服务器的配置参数对应的所述测试任务之前,对所述待检测服务器执行所述多次在先测试任务,得到所述在先测试结果;
2)统计单元704,用于统计所述在先测试结果得到与不同的结果参数对应的所述历史参考值。
以下结合具体示例说明,结合图1所示,在本实施例中,上述测试任务用于检测客户端向业务服务器102请求执行业务(例如,TCP/UDPserver)的连通率。进一步,上述检测客户端104-1至检测客户端104-4在10:00-11:00、12:00-13:00、14:00-15:00对业务服务器102执行了三次在先测试任务,并得到如表4所示的每个检测客户端每次的测试结果(例如,连通率)以及计算所得的多个检测客户端每次测试得到的连通率的平均值。
表4
如表4所示,由上述统计在先测试结果得到的连通率的历史参考值可以但不限于为上述检测客户端多次测试结果的平均值,其中,上述检测客户端每次的测试结果可以但不限于为多个检测客户端的测试结果的平均值。例如,统计第一次测试得到的连通率为检测客户端104-1至检测客户端104-4的测试结果的平均值85%,进一步,第二次测试得到的连通率为82.5%,第三次测试得到的连通率为83.75%,则业务服务器102关于业务TCP/UDP server的连通率的历史参考值为(85%+82.5%+83.75%)/3=83.75%。
通过本发明提供的实施例,通过建立历史参考值,使得服务器状态检测可以基于历史参考值进行分析,实现了对上述待检测服务器的状态地有效检测,进一步提高待测服务器的状态检测的准确性。
作为一种可选的方案,上述多个检测客户端中的每一个检测客户端,包括:
1)第一生成单元,用于生成与测试任务对应的测试数据包;
2)发送单元,用于将测试数据包发送给待检测服务器(例如,业务服务器102);
3)接收单元,用于接收到待检测服务器返回的响应于测试数据包的测试结果响应信息;
4)第二生成单元,用于根据测试结果响应信息生成测试结果。
可选地,在本实施例中应用于服务器状态检测的多个检测客户端中的每个检测客户端都会将由待检测服务器接收到的测试结果进行反馈。
可选地,在本实施例中,对多个检测客户端中的每个检测客户端反馈的测试结果进行统计,可选地,在本实施例中,统计的方式可包括但不限于:计算多个检测客户端的测试结果的期望值、计算多个检测客户端测试结果的平均值。
以下结合具体示例说明,结合图1以及表4中第一列所示,在本实施例中,上述测试任务用于检测客户端向业务服务器102请求执行业务(例如,TCP/UDP server)的连通率。多个检测客户端中的每一个(例如,检测客户端104-1)都将生成与连通率测试的测试任务对应的测试数据包,并将上述测试数据包发送给业务服务器102,然后,上述检测客户端将接收到业务服务器102返回的响应于测试数据包的测试结果响应信息,例如,检测客户端104-1接收到与业务服务器102的连通率为85%,检测客户端104-3接收到与业务服务器102的连通率为80%,检测客户端104-3接收到与业务服务器102的连通率为90%,检测客户端104-4接收到与业务服务器102的连通率为85%。最后,上述检测客户端将根据多个检测客户端得到的测试结果响应信息生成如表4所示的测试结果,例如,多个检测客户端的连通率的平均值为85%。
通过本发明提供的实施例,通过基于网络中的多个检测客户端进行对待检测服务器的状态检测,避免了现有技术中仅基于服务器本机进行状态检测所导致的检测不准确的问题,从而实现了通过从分布式部署的检测客户端的角度识别待检测服务器的状态,提高了状态检测的准确性。
作为一种可选的方案,所述发送单元包括:
1)发送模块,用于并行地将测试数据包发送给待检测服务器。
可选地,在本实施例中,多个检测客户端中的每一个检测客户端均可以但不限于建立多个进程或线程。例如,结合图1所示,检测客户端104-1可以向业务服务器102并行发送多个测试数据包,同时测试业务服务器102关于某个业务的多个特性,或者,同时测试多个业务服务器中的多个业务的某个特性。
通过本发明提供的实施例,多个检测客户端通过并行发送测试数据包的方式,进而实现了提高对待检测服务器的状态检测的检测速度。
作为一种可选的方案,如图7所示,在本实施例中该装置还包括:
1)过滤单元706,用于在所述多个检测客户端将所述测试数据包发送给所述待检测服务器之后,当判断出所述待检测服务器处于异常状态时,则设置防护配置参数,其中,所述防护配置参数用于过滤掉部分发送到所述待检测服务器的数据包。
可选地,在本实施例中的防护配置参数可以但不限于包括:客户端所发送的数据包的数量、业务服务器所接收的数据包的数量。可选地,在本实施例中,过滤部分发送到待检测服务器的数据包的方式可以包括但不限于:限制指定客户端在单位时间内所发送的数据包的数量在预定阈值范围内、屏蔽指定客户端的IP地址、限制待检测服务器在单位时间内所接收的数据包的数量。
例如,结合图1所示,当判断出待检测服务器(例如,业务服务器102)处于异常状态,则修改设置上述业务服务器102的防护配置参数以实现过滤掉部分发送到业务服务器102的数据包。其中,过滤数据包的方式可以如下:
1)假设检测客户端104-1在单位时间内所发送的数据包的数量过大(例如,5000个/小时),则可以限制检测客户端104-1在单位时间内发送的数据包的数量小于1000个,则大于1000个的数据包都将被过滤掉。
2)假设检测客户端104-1在单位时间内所发送的数据包的数量过大(例如,5000个/小时),则可以直接屏蔽上述检测客户端104-1的IP地址,进而实现过滤掉检测客户端104-1所发送的全部数据包。
3)假设业务服务器102在单位时间内所接收到的数据包的数量过大(例如,8000个/小时),则可以限制检测客户端104-1在单位时间内发送的数据包的数量小于5000个,例如,将发送来的数据包进行随机的丢弃,以实现过滤掉较大数量的数据包。
通过本发明提供的实施例,通过将处于异常状态的待检测服务器的防护配置参数进行设置,以使上述待检测服务器保持在比较健康的运行状态。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
在本发明的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中,应该理解到,所揭露的客户端,可通过其它的方式实现。其中,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个***,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,单元或模块的间接耦合或通信连接,可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。