CN111614501A - 一种监控方法及系统 - Google Patents

Abstract

本申请公开了一种监控方法及系统，用以实时监控服务器是否正常，包括：启动监控任务；所述监控任务每隔时间T1访问一次预设的服务器；监听所述服务器的响应消息；根据所述监听的结果判断所述服务器的运行状态。本申请还公开了一种监控系统。通过本申请公开的方法及系统，降低了监控成本，提高了监控效率，同时能达到实时监控的目的。

Description

一种监控方法及系统

技术领域

本申请涉及网络技术领域，尤其涉及一种web业务系统可用性监控的方法及装置。

背景技术

近年来，随着信息化技术的快速发展，企业内部网络中建立了大量的业务信息系统，而这些信息系统多数属于web应用系统。为确保这些web系统平稳运行以满足日常业务正常开展，要求达到24小时无故障运行，且要求能够及时发现故障以快速处理。目前web系统自身并未提供异常报警功能，运维工作中大多采用人工巡检的方式监控系统的可用性。这种人工的监控的方式成本高，效率低，不能达到实时监控报警的目的。

发明内容

针对上述技术问题，本申请实施例提供了监控方法及系统，用以降低监控成本，提高监控效率，同时能达到实时监控的目的。

第一方面，本发明实施例提供了一种监控方法，包括：

启动监控任务；

所述监控任务每隔时间T1访问一次预设的服务器；

监听所述服务器的响应消息；

根据所述监听的结果判断所述服务器的运行状态；

其中T1是预设的监控周期，所述运行状态包括故障或者非故障。

进一步的，启动监控任务之前还包括：

创建监控项目；设置报警项目；设置报警规则；设置报警通知对象。

优选的，根据所述监听的结果判断所述服务器的运行状态，具体包括：

访问服务器后，若在时间T2内未收到所述服务器的响应消息，则确定本次访问异常；

若在时间T2内收到了所述服务器的响应消息，则确定本次访问正常；

其中T2是预先配置的等待时间，且T2小于T1。

优选的，根据所述监听的结果判断所述服务器的运行状态，还可以是：

访问服务器后，在时间T2内收到所述服务器的响应消息；

所述响应消息的响应码和/或关键词不满足预设的条件，则确定本次访问异常；

若响应消息的响应码和关键词满足预设条件，则确定本次访问正常。

其中T2是预先配置的等待时间，且T2小于T1。

进一步的，所述根据所述监听的结果判断所述服务器的运行状态，还可以包括：若连续N次访问异常，则确定服务器故障；或者在M次连续的访问中累计有N次访问异常，则确定服务器故障；其中，N是大于1的正整数，M是大于N的正整数。

进一步的，确定服务器故障后，还可以包括：

记录报警状态；

若报警开关打开，则每隔时间T3向预设的通知对象发送A次服务器故障报警；若报警开关关闭，则不发送报警。其中所述的A次服务器故障报警是连续发送的。

优选的，本发明还可以包括故障恢复判断和通知步骤，确定访问正常后，可以包括：

如果已记录报警状态，则清除报警状态；或者

如果已记录报警状态，且连续P次访问正常，则清除报警状态；或者

如果已记录报警状态，且在连续Q次访问中累计有P次访问正常，则清除报警状态；

其中，P是大于1的正整数，Q是大于P的正整数。

清楚报警状态后，还可以包括向预设的报警通知对象发送故障恢复消息。

第二方面，本发明实施例还提供一种监控系统，用于实现上述监控方法

在本发明实施例中，周期性的访问待监控的服务器，自动判断服务器是否故障，并在发现故障时及时通知维护人员，实现实时、高效、低成本的监控。

附图说明

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

图1为本申请实施例提供的一种监控方法示意图；

图2为本申请实施例提供的另一种监方法控流程示意图；

图3为本申请实施例提供的一种监控系统示意图；

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部份实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

下面对文中出现的一些词语进行解释：

1、本发明实施例中术语“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

2、本申请实施例中术语“多个”是指两个或两个以上，其它量词与之类似。

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

针对现有技术问题，本申请实施例提供了一种监控方法及系统，用以降低监控成本，提高监控效率，同时能达到实时监控的目的。

其中，方法和系统是基于同一申请构思的，由于方法和系统解决问题的原理相似，因此系统和方法的实施可以相互参见，重复之处不再赘述。

下面结合说明书附图对本申请各个实施例进行详细描述。需要说明的是，本申请实施例的展示顺序仅代表实施例的先后顺序，并不代表实施例所提供的技术方案的优劣。

实施例一

参见图1，为本申请实施例提供的一种监控方法示意图，该流程可包括：

S101，启动监控任务。

监控任务需要人工启动，关闭时也需要人工操作。也可以设置定时器，当定时器超时时，系统自动启动监控任务。

进一步的，还可以设定每天启动监控和关闭监控的时间。作为一种优选实施例，每天晚上20点启动监控，每天早上8点关闭监控。

S102，所述监控任务每隔时间T1访问一次预设的服务器。

监控任务启动后，周期性进行监控。即每隔时间一定时间T1向预设的服务器发起访问请求。

需要说明的是，监控间隔T1的设置，根据业务需要确定。T1越短，越能及时发现故障。作为优选实施例，T1可以是以下之一：

30秒，1分钟，2分钟，3分钟，5分钟，10分钟，15分钟，30分钟，1小时或者1天。

对于实时性性要求高的服务器，可设置较短的监控周期；对于实时性要求低的服务器，可设置较长的监控周期。

需要说明的是，待监控的服务器是在任务启动前预先设置的，可以是一个，也可以是多个。当监待监控的服务器是多个时，可逐个监控，即访问一个服务器且判断结束后再访问下一个服务器。也可以同时监控，即同时向多个服务器发起访问请求，同时监控多个服务器的响应消息。

S103，监听所述服务器的响应消息。

访问请求发出后，监听服务器针对访问请求的响应消息。

S104，根据所述监听的结果判断所述服务器的运行状态。

访问请求发送后，可启动定时器T2，若果在定时器T2超时之前监听到服务器针对访问请求的响应消息，则判断访问正常。若定时器T2超时仍然未鉴定到服务器针对访问请求的响应消息，或者响应消息与访问请求不相符，则判断访问异常。

需要说明的是，T2大小的设置，需要根据监控系统与服务器的距离考虑合理的网络传输延时，或者根据对服务器实时性的要求，设置合理的响应消息等待时间。

在访问正常或者异常的基础上，再判断服务器是否故障。

通过本实施例的方法，通过监控系统自动周期性监控服务器运行状态，提高了实时性，降低了监控成本，提高了监控效率。

实施例二

如图2所示，本实施例还提供了一种监控方法流程示意图，该流程可包括以下步骤：

S201，创建监控项目。

S202，设置报警项目。

需要说明的是，报警项目包括多个，在启动监控之前可以根据需要选择不同的报警项目，不同的报警项目的报警规则可以不同。例如，高实时性报警项目，用于监控服务器的快速响应能力，当服务器响应时间超过报警值时即可触发报警。再例如，服务器死机报警，用于监控服务器崩溃死机的情况，相应的，服务器的响应时间报警门限可以设置的较长。

S203，设置报警规则。

报警规则包括异常的判定规则和报警的发送规则。判定规则可以包括：若连续N次访问异常，则确定服务器故障；或者在M次连续的访问中累计有N次访问异常，则确定服务器故障；其中，N是大于1的正整数，M是大于N的正整数。报警规则的设置即修改N和M的值。作为一种优选示例，N可以为1到10的整数，M可以比N大2。

报警的发送规则可以包括报警的发送次数和报警发送的对象，还可以包括报警开关。报警的发送次数即为每隔时间T3向预设的通知对象发送A次服务器故障报警，T3和A的值根据实际业务需要设置，在此不做限定。作为一种优选的示例，T3可以为30秒，A可以为1到5的整数。

S204，设置报警通知对象。

本实施例的报警通知对象即为当系统检测到报警时，将报警信息送达的对象。其中，送达方式可以为短信通知，邮件通知，或者其他能将报警信息送达通知对象的方式。对象可以是IT系统的运营维护人员。

S205，启动监控任务。

设置完成后，需要启动监控任务。详细与S101一致，本实施例不再赘述。

S206，访问预设的服务器。

待监控的服务器是在任务启动前预先设置的，可以是一个，也可以是多个。当监待监控的服务器是多个时，可逐个监控，即访问一个服务器且判断结束后再访问下一个服务器。也可以同时监控，即同时向多个服务器发起访问请求，同时监控多个服务器的响应消息。

S207，将监控记录写入数据库。

在数据库中记录每一条监控访问记录，记录的内容可以包括：访问时间，访问服务器地址，访问关键词，预期的服务器反馈时间等，还可以包括其他预设的内容。

S208，监听服务器的响应消息。

本步骤所述的监听，是监听S206步骤发起的访问相对应的响应消息。如果收到的反馈消息不是访问相对应的，视为未收到反馈消息。

需要说明的是，本实施例所述的响应消息，至少包括响应码相对应，还可以包括关键词相对应。

S209，判断服务器是否故障。若判断结果为是，则执行S213；若判断结果为否，则执行S210。

根据监听的结果，判断服务器是否故障。具体包括两个步骤：

步骤一：判断单次访问是正常或异常；

步骤二：根据访问异常的次数确定服务器是否故障。

其中，步骤一中，判断单次访问是正常或异常的方法包括：

方法一：

访问服务器后，若在时间T2内未收到所述服务器的响应消息，则确定本次访问异常；若在时间T2内收到了所述服务器的响应消息，则确定本次访问正常；其中T2是预先配置的等待时间，且T2小于T1。

方法二：

访问服务器后，在时间T2内收到所述服务器的响应消息；所述响应消息的响应码和/或关键词不满足预设的条件，则确定本次访问异常；若响应消息的响应码和关键词满足预设条件，则确定本次访问正常。其中T2是预先配置的等待时间，且T2小于T1。

需要说明的是，方法一和方法二可以单独使用，也可以同时使用，本实施例不做限定。

进一步的，上述步骤二中，根据访问异常的次数确定服务器是否故障的方法具体包括：

方法A：若连续N次访问异常，则确定服务器故障；

方法B：在M次连续的访问中累计有N次访问异常，则确定服务器故障；其中，N是大于1的正整数，M是大于N的正整数。

需要说明的是，方法A和方法B可以单独使用，也可以同时使用，本实施例不做限定。

优选的，本步骤还可以包括：将判断结果写入数据库。即无论判断结果是故障还是未故障，均将结果写入数据库。其中，写入的记录与S207写入的记录相对应，即记录一次访问对应的结果是故障还是不故障。进一步的，还可以记录一次访问对应的响应消息是异常还是正常。

S210，判断是否为故障恢复。若判断结果为是，则执行S211；若判断结果为否，则执行S206。

确定访问正常后，需要根据记录的报警状态，判断是否恢复报警，具体方法可包括：

如果已记录报警状态，则清除报警状态；或者

如果已记录报警状态，且连续P次访问正常，则清除报警状态；或者

如果已记录报警状态，且在连续Q次访问中累计有P次访问正常，则清除报警状态；

其中，P是大于1的正整数，Q是大于P的正整数。P和Q的具体值，可根据实际需要确定。作为一种优选实施例，P可以为2到10的整数，Q比P大1到5。

S211，清除报警状态。

S210确定清除报警状态时，清除数据库记录的报警状态。

S212，向报警通知对象发送故障恢复消息。

故障恢复通知消息的通知对象，同报警通知的对象，在确定报警恢复，清除报警状态后，发送故障恢复消息。具体的，可以连续通知X次，X可以为1到5的整数。

S213，判断是否报警。若判断结果为是，则执行S214；若判断结果为否，则执行S206。

在确定服务器故障后，需要判断报警开关是否打开。只有报警开关打开的情况下，才会启动报警发送步骤。

S214，记录报警状态。

当报警功能打开后，将报警的记录写入数据库，并将报警状态置位。记录的信息可以包括：报警的时间，报警发送的对象，报警的服务器，报警的原因等。

需要说明的是，报警状态置位后，判断报警是否恢复的步骤才能读取到报警状态。若果报警恢复，则将报警状态清除。

S215，向报警通知对象发送报警。

出现报警，且报警开关打开的情况下，将报警信息发送给报警通知对象。报警通知对象是S204设置的。

通过本实施的监控方法，监控成本低，效率高，能及时高效的发现故障，并及时通知维护人员及时修复，确保这些web系统平稳运行。

实施例三

如图3所示，本实施例还提供了一种监控系统，包括：

主机301，用于运行监控系统软件；

网络接口302，用于监控系统与被监控服务器之间的通信。

本实施例提供的监控系统，能实现上述实施例一或者实施例二所述的方法，达到相同的技术效果，本实施例不再赘述。

需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

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

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

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

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

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

Claims (9)

1.一种监控方法，其特征在于，包括：

启动监控任务；

所述监控任务每隔时间T1访问一次预设的服务器；

监听所述服务器的响应消息；

根据所述监听的结果判断所述服务器的运行状态；

其中T1是预设的监控周期，所述运行状态包括故障或者非故障。

2.根据权利要求1所述的方法，其特征在于，所述启动监控任务之前还包括：

创建监控项目；

设置报警项目；

设置报警规则；

设置报警通知对象。

3.根据权利要求1所述的方法，其特征在于，所述根据所述监听的结果判断所述服务器的运行状态，具体包括：

访问服务器后，若在时间T2内未收到所述服务器的响应消息，则确定本次访问异常；

若在时间T2内收到了所述服务器的响应消息，则确定本次访问正常；

其中T2是预先配置的等待时间，且T2小于T1。

4.根据权利要求1所述的方法，其特征在于，所述根据所述监听的结果判断所述服务器的运行状态具体包括：

访问服务器后，在时间T2内收到所述服务器的响应消息；

所述响应消息的响应码和/或关键词不满足预设的条件，则确定本次访问异常；

若响应消息的响应码和关键词满足预设条件，则确定本次访问正常；

其中T2是预先配置的等待时间，且T2小于T1。

5.根据权利要求3或者4所述的方法，其特征在于，所述根据所述监听的结果判断所述服务器的运行状态，具体包括：

若连续N次访问异常，则确定服务器故障；或者

在M次连续的访问中累计有N次访问异常，则确定服务器故障；

其中，N是大于1的正整数，M是大于N的正整数。

6.根据权利要求5所述的方法，其特征在于，确定服务器故障后还包括：

记录报警状态；

若报警开关打开，则每隔时间T3向预设的通知对象发送A次服务器故障报警；若报警开关关闭，则不发送服务器故障报警；

其中所述的A次服务器故障报警是连续发送的。

7.根据权利要求3所述的方法，其特征在于，确定本次访问正常后，还包括：

如果已记录报警状态，则清除报警状态；或者

如果已记录报警状态，且连续P次访问正常，则清除报警状态；或者

如果已记录报警状态，且在连续Q次访问中累计有P次访问正常，则清除报警状态；

其中，P是大于1的正整数，Q是大于P的正整数。

8.根据权利要求7所述的方法，其特征在于，清除报警状态后，还包括：

向预设的报警通知对象发送故障恢复消息。

9.一种监控系统，其特征在于，该系统用于实现如权利要求1到11之一所述的监控方法。

Images