CN110224880B - 一种心跳监测方法及监控设备 - Google Patents

Abstract

本申请实施例公开了一种心跳监测方法及监控设备，涉及通信技术领域，能够均衡降低心跳超时造成的业务损失的需求和避免频繁进行业务迁移的需求，降低心跳超时对系统业务造成的损耗。包括：监控设备超过第一门限时长未接收到被监控设备发送的数据包，则确定导致所述监控设备超过所述第一门限时长未接收到所述数据包的故障原因；所述数据包为心跳数据包或所述监控设备发送给所述被监控设备的心跳数据包对应的响应数据包，所述故障原因为所述被监控设备故障或所述监控设备与所述被监控设备之间的网络故障；所述监控设备根据所述故障原因以及所述第一门限时长确定第二门限时长，根据所述第二门限时长对所述被监控设备进行心跳监测。

Description

一种心跳监测方法及监控设备

技术领域

本申请实施例涉及通信技术领域，尤其涉及一种心跳监测方法及监控设备。

背景技术

心跳监测机制是一种常见且应用广泛的故障检测机制，具体地：监控设备周期性发送心跳数据包给被监控设备，被监控设备发送响应数据包给监控设备以表明本身的状态正常。或，被监控设备主动地周期性上报心跳数据包给监控设备。

当监控设备在超过门限时长T1收不到被监控设备的心跳数据包或响应数据包(即心跳超时)，则判定该被监控设备故障。此后，监控设备可以把该被监控设备的故障通知给其他正常运行的设备，可以将故障设备上的业务迁移至正常运行的设备上，进行业务迁移的时长为T2。因此，一次心跳超时需要T1+T2才能恢复，在这段时间内被监控设备的业务会受到影响，对系统业务的损失时间为T1+T2。

发生心跳超时的原因可能是被监控设备宕机或监控设备与被监控设备之间的网络异常。其中，被监控设备宕机需要进行业务迁移；监控设备与被监控设备之间的网络异常会自动恢复，不需要进行业务迁移。如果门限时长较小，可以缩短心跳超时造成的损失时间，但是由于门限时长较短会导致网络闪断时长很容易满足门限时长，进而频繁触发业务迁移，频繁进行业务迁移会给系统业务造成很大损失。门限时长较大的话，虽然会降低网络闪断触发业务迁移的几率，但会延长心跳超时造成的业务损失。

可见，现有技术无法均衡降低心跳超时造成的业务损失的需求和避免频繁进行业务迁移的需求，由于心跳超时导致系统业务的损耗较大。

发明内容

本申请实施例提供一种心跳监测方法及监控设备，能够均衡降低心跳超时造成的业务损失的需求和避免频繁进行业务迁移的需求，降低心跳超时对系统业务造成的损耗。

第一方面，公开了一种心跳监测方法，包括：监控设备超过第一门限时长未接收到被监控设备发送的数据包，则确定导致监控设备超过所述第一门限时长未接收到所述数据包的故障原因。其中，所述数据包为心跳数据包或监控设备发送给被监控设备的心跳数据包对应的响应数据包。所述故障原因为被监控设备故障或监控设备与被监控设备之间的网络故障。进一步，监控设备根据所述故障原因以及所述第一门限时长确定第二门限时长，后续过程中监控设备可以根据第二门限时长对被监控设备进行心跳监测。

本发明实施例提供的心跳监测方法，监控设备在被监控设备心跳超时后，确定被监控设备心跳超时的故障原因，进而根据故障原因来调整对目前设备的门限时长进行调整，获得新的门限时长。由于故障具有可重现性、相似性，后续被监控设备有很大的几率会再次出现同样的故障，因此可以通过某一次的故障原因来调整门限时长，并根据新的门限时长在后续过程中对被监控设备进行心跳监测。如此，可以降低后续一段时间内被监控设备出现相同故障对系统业务的整体损耗。示例的，如果故障原因是监控设备与被监控设备之间的网络故障，则设置较大的门限时长，尽可能保证后续网络闪断时长(即监控设备与被监控设备之间的网络故障的时长)小于门限时长，进而不会频繁触发不必要的业务迁移，减少系统的业务损耗。如果故障原因是被监控设备自身出现故障，则设置较小的门限时长，尽可能缩短后续心跳超时进行业务迁移带来的业务损耗。

结合第一方面，在第一方面的第一种可能的实现方式中，监控设备确定被监控设备的故障原因具体包括：查询被监控设备的运行记录确定被监控设备在第一门限时长内连续运行，则确定故障原因为监控设备与被监控设备之间的网络故障；查询被监控设备的连续运行记录确定被监控设备在第一门限时长内未连续运行，则确定故障原因为被监控设备故障。

具体实现中，可以查询故障时间点之间一段时间(大于或等于门限时长)内，被监控设备的运行记录，进而就可以确定被监控设备在第一门限时长内是否连续运行。如果被监控设备在第一门限时长内未连续运行，说明在第一门限时长内被监控设备曾经宕机，反之，如果被监控设备在第一门限时长内连续运行，说明第一门限时长内被监控设备并未发生过宕机，心跳超时的原因是监控设备与被监控设备之间的网络故障。

结合第一方面或第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，第一门限时长为最大门限时长，监控设备根据故障原因将第一门限时长更新为第二门限时长具体包括：若故障原因为监控设备与被监控设备之间的网络故障，则确定第二门限时长等于第一门限时长；若故障原因为监控设备与被监控设备故障，则确定第二门限时长小于第一门限时长。

也就是说如果在先设置的门限时长是一个较大的数值，进一步，如果故障原因为网络闪断则说明网络闪断时间过长，导致的网络长时间中断对NFV系统的业务损耗很大，因此当网络中断的时间大于业务迁移时间，不如直接进行业务迁移，保证业务尽快恢复，尽可能减少对NFV系统的业务损耗。因此可以保持第一门限时长T1不变，即第二门限时长与第一门限时长相等。如此，后续网络闪断会触发业务迁移，减少对NFV系统的业务损耗。若所述故障原因为所述监控设备与所述被监控设备故障，则确定所述第二门限时长小于所述第一门限时长。后续过程中，被监控设备出现的故障很有可能仍是宕机，那么可以适当缩短第一门限时长T1，后续可以通过更短的时间检测到宕机，进而也就缩短了心跳超时触发业务迁移给NFV网络带来的业务损失。

结合第一方面或第一方面的第一种可能的实现方式，在第一方面的第三种可能的实现方式中，第一门限时长为最小门限时长，监控设备根据故障原因将第一门限时长更新为第二门限时长具体包括：若故障原因为监控设备与被监控设备之间的网络故障，则确定第二门限时长大于第一门限时长；若故障原因为监控设备与被监控设备故障，则确定第二门限时长等于第一门限时长。

若所述故障原因为所述监控设备与所述被监控设备之间的网络故障，则确定所述第二门限时长大于所述第一门限时长。后续过程中，被监控设备出现的故障很有可能仍是网络闪断，适当的增加第一门限时长，后续出现网络闪断的持续时间就不容易大于门限时长，进而不会频繁触发业务迁移。若所述故障原因为所述监控设备与所述被监控设备故障，则确定所述第二门限时长等于所述第一门限时长。后续过程中，被监控设备出现的故障很有可能仍是宕机，由于第一门限时长是最小了，那么可以保持第一门限时长不变，使得监控设备在后续过程中仍可以通过较短的时间检测到宕机，进而也就缩短了心跳超时触发业务迁移给NFV网络带来的业务损失。

结合第一方面或第一方面的第一种可能的实现方式，在第一方面的第四种可能的实现方式中，第一门限时长为大于最小门限时长小于最大门限时长的任意值，监控设备根据故障原因将第一门限时长更新为第二门限时长具体包括：若故障原因为监控设备与被监控设备之间的网络故障，则确定第二门限时长大于第一门限时长，且小于最大门限时长；若故障原因为监控设备与被监控设备故障，则确定第二门限时长小于第一门限时长，且大于最小门限时长。

若所述故障原因为所述监控设备与所述被监控设备之间的网络故障，则确定所述第二门限时长大于所述第一门限时长，且小于所述最大门限时长。也就是说，后续过程中，被监控设备出现的故障很有可能仍是网络闪断，适当的增加第一门限时长，后续出现网络闪断的持续时间就不容易大于门限时长，进而不会频繁触发业务迁移。若所述故障原因为所述监控设备与所述被监控设备故障，则确定所述第二门限时长小于所述第一门限时长，且大于所述最小门限时长。后续过程中，被监控设备出现的故障很有可能仍是宕机，适当的调小第一门限时长，使得监控设备在后续过程中仍可以通过较短的时间检测到宕机，进而也就缩短了心跳超时触发业务迁移给NFV网络带来的业务损失。

第二方面，公开了一种监控设备，包括：

处理单元，用于在接收单元超过第一门限时长未接收到被监控设备发送的数据包时，确定导致监控设备超过第一门限时长未接收到数据包的故障原因；数据包为心跳数据包或监控设备发送给被监控设备的心跳数据包对应的响应数据包，故障原因为被监控设备故障或监控设备与被监控设备之间的网络故障；处理单元还用于，根据故障原因以及第一门限时长确定第二门限时长，根据第二门限时长对被监控设备进行心跳监测。

本发明实施例提供的监控设备，在被监控设备心跳超时后，确定被监控设备心跳超时的故障原因，进而根据故障原因来调整对目前设备的门限时长进行调整，获得新的门限时长。由于故障具有可重现性、相似性，后续被监控设备有很大的几率会再次出现同样的故障，因此可以通过某一次的故障原因来调整门限时长，并根据新的门限时长在后续过程中对被监控设备进行心跳监测。如此，可以降低后续一段时间内被监控设备出现相同故障对系统业务的整体损耗。示例的，如果故障原因是监控设备与被监控设备之间的网络故障，则设置较大的门限时长，尽可能保证后续网络闪断时长(即监控设备与被监控设备之间的网络故障的时长)小于门限时长，进而不会频繁触发不必要的业务迁移，减少系统的业务损耗。如果故障原因是被监控设备自身出现故障，则设置较小的门限时长，尽可能缩短后续心跳超时进行业务迁移带来的业务损耗。

结合第二方面，在第二方面的第一种可能的实现方式中，处理单元具体用于，查询被监控设备的运行记录确定被监控设备在第一门限时长内连续运行，则确定故障原因为监控设备与被监控设备之间的网络故障；查询被监控设备的连续运行记录确定被监控设备在第一门限时长内未连续运行，则确定故障原因为被监控设备故障。

结合第二方面或第二方面的第一种可能的实现方式，在第二方面的第二种可能的实现方式中，第一门限时长为最大门限时长，处理单元具体用于，若故障原因为监控设备与被监控设备之间的网络故障，则确定第二门限时长等于第一门限时长；若故障原因为监控设备与被监控设备故障，则确定第二门限时长小于第一门限时长。

结合第二方面或第二方面的第一种可能的实现方式，在第二方面的第三种可能的实现方式中，第一门限时长为最小门限时长，处理单元具体用于，若故障原因为监控设备与被监控设备之间的网络故障，则确定第二门限时长大于第一门限时长；若故障原因为监控设备与被监控设备故障，则确定第二门限时长等于第一门限时长。

结合第二方面或第二方面的第一种可能的实现方式，在第二方面的第四种可能的实现方式中，第一门限时长为大于最小门限时长小于最大门限时长的任意值，处理单元具体用于，若故障原因为监控设备与被监控设备之间的网络故障，则确定第二门限时长大于第一门限时长，且小于最大门限时长；若故障原因为监控设备与被监控设备故障，则确定第二门限时长小于第一门限时长，且大于最小门限时长。

第三方面，公开了一种计算机可读存储介质，该计算机可读存储介质中存储有指令；当其在上述第二方面及其任意一项可能的实现方式所述的监控设备上运行时，使得该监控设备执行如上述第一方面及其各种可能的实现方式所述的心跳监控方法。

第四方面，公开了一种无线通信装置，该无线通信装置中存储有指令，当该无线通信装置在上述第二方面及其任意一项可能的实现方式所述的监控设备上运行时，使得该网络设备执行如上述第一方面及其各种可能的实现方式所述的心跳监控方法。具体实现中，该无线通信装置可以是芯片。

本申请中第二方面、第三方面、第四方面及其各种实现方式的具体描述，可以参考第一方面及其各种实现方式中的详细描述；并且，第二方面、第三方面、第四方面及其各种实现方式的有益效果，可以参考第一方面及其各种实现方式中的有益效果分析，此处不再赘述。

附图说明

图1为NFV系统的架构图；

图2为现有的心跳监测流程的示意图；

图3为本发明实施例提供的监控设备的结构框图；

图4为本发明实施例提供的心跳监控方法的流程示意图；

图5为本发明实施例提供的故障确定方法的流程示意图；

图6为本发明实施例提供的监控设备的另一结构框图；

图7为本发明实施例提供的监控设备的另一结构框图。

具体实施方式

通常，可以利用心跳机制对设备的运行状态进行监控，一旦在特定的时间内没有接收到监控对象的数据包，则可以判断被监控对象出现故障。示例的，在图1所示的网络功能虚拟化(network function virtualization，NFV)系统中，运行维护单元(operationand maintenance unit，OMU)为监控者，服务处理单元(service process unit，SPU)1、SPU2、会话数据库单元(session database unit，SDU)、接口处理单元(interface processunit，IPU)均为被监控者。其中，IPU用于处理整个NFV系统的通信，SDU用于存储业务数据，SPU是用于处理用户业务。

OMU可以向SPU等被监控者发送心跳数据包，随后设置定时器，当定时器超时OMU仍未接收到SPU发送的响应数据包，则判断该SPU出现故障。或者OMU无需发送心跳数据包，SPU周期性向OMU上报心跳数据包，如果OMU在指定时间内没有接收到SPU发送的心跳数据包，则判断该SPU出现故障。如图2所示，心跳监测的流程主要包括以下步骤：

(1)当系统正常运行时，用户先将业务消息发送给IPU，IPU将业务消息发送给SPU1和SPU2进行处理，处理过程中，SPU1和SPU2将用户状态数据保存在SDU中。

(2)以SPU1出现故障为例，假设心跳超时的门限时长为T1。在T1内，由于IPU不知道SPU1已经故障，依然把用户的业务消息发给SPU1处理，则T1内发往SPU1的业务消息指示的用户业务将处理失败。

(3)OMU超过T1仍未接收到SPU1上报的数据包(心跳数据包或响应数据包)，则判定SPU1故障。并通知SPU2进行业务迁移。具体地，业务迁移包括SPU2从SDU获取SPU1正在处理的用户数据，并向IPU通知SPU1发生故障。这个过程需要的时间为T2，在此期间原本需要由SPU1处理的业务被影响。

(4)在迁移完成之后，IPU会把原本由SPU1处理的用户信息发给SPU2进行处理，业务恢复正常。

可见，由于SPU1出现心跳超时触发业务迁移对整个NFV系统造成的业务损失时长包括检测到故障的时长T1+业务迁移的时长T2。

现有技术中，在不用的应用场景下，不管被监控设备是什么原因导致的故障，只要出现心跳超时，都会触发业务迁移，即将出现故障的设备上的业务迁移至正常运行的设备上。一般的电信级应用需承载百万级甚至千万级的用户，每一个被监控设备分担的用户数量也是极其庞大的，并且每个用户进行业务迁移时长(即上述T2)均比较长，因此由于设备故障触发业务迁移给系统带来的业务损失是不可忽略的。为了减少业务迁移造成的业务损失，可以设置较小的门限时长。

通常，发生心跳超时的原因可能是被监控设备宕机或监控设备与被监控设备之间的网络异常，监控设备与被监控设备之间网络闪断时长大于门限时长。实际上，监控设备与被监控设备之间的网络闪断会自动恢复，不需要进行业务迁移，但是由于门限时长较短会导致网络闪断时长很容易满足门限时长，频繁触发业务迁移。频繁进行业务迁移会给系统业务造成很大损失。

另外一方面，如果门限时长较大的话，虽然会降低网络闪断触发业务迁移的几率，但会延长心跳超时造成的业务损失。

可见，现有技术无法均衡降低心跳超时造成的业务损失的需求和避免频繁进行业务迁移的需求。

本发明实施例提供一种心跳监测方法，监控设备在被监控设备心跳超时后，确定被监控设备心跳超时的故障原因，进而根据故障原因设置新的门限时长。由于故障具有可重现性、相似性，后续有很大的几率会再次出现同样的故障，通过一次的故障原因来调整门限时长，新的门限时长可以保证后续一段时间内出现相同故障对业务的整体损耗。具体地，如果故障原因是监控设备与被监控设备之间的网络故障，则设置较大的门限时长，尽可能保证后续网络闪断时长(即监控设备与被监控设备之间的网络故障的时长)小于门限时长，进而不会频繁触发不必要的业务迁移，减少业务损耗。如果故障原因是被监控设备自身出现故障，则设置较小的门限时长，使得监控设备可以通过更短的时间检测到故障，尽可能缩短后续心跳超时进行业务迁移后带来的业务损耗。

本发明实施例提供的心跳监测方法可应用于监控设备，所述监控设备可以是图1中的OMU。如图3所示，该监控设备可以包括至少一个处理器11，存储器12、收发器13以及通信总线14。

下面结合图3对该监控设备的各个构成部件进行具体的介绍：

处理器11是监控设备的控制中心，可以是一个处理器，也可以是多个处理元件的统称。例如，处理器11是一个中央处理器(central processing unit，CPU)，也可以是特定集成电路(Application Specific Integrated Circuit，ASIC)，或者是被配置成实施本发明实施例的一个或多个集成电路，例如：一个或多个微处理器(digital signalprocessor，DSP)，或，一个或者多个现场可编程门阵列(Field Programmable Gate Array，FPGA)。

其中，处理器11可以通过运行或执行存储在存储器12内的软件程序，以及调用存储在存储器12内的数据，执行监控设备的各种功能。

在具体的实现中，作为一种实施例，处理器11可以包括一个或多个CPU，例如图3中所示的CPU0和CPU1。

在具体实现中，作为一种实施例，监控设备可以包括多个处理器，例如图3中所示的处理器11和处理器15。这些处理器中的每一个可以是一个单核处理器(single-CPU)，也可以是一个多核处理器(multi-CPU)。这里的处理器可以指一个或多个监控设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。

存储器12可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储监控设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储监控设备，也可以是电可擦可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(CompactDisc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储监控设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器12可以是独立存在，通过通信总线14与处理器11相连接。存储器12也可以和处理器11集成在一起。

其中，所述存储器12用于存储执行本发明方案的软件程序，并由处理器11来控制执行。

收发器13，使用任何收发器一类的装置，用于与图1系统中的被监控设备间的通信，如图1中的VM。当然，收发器13还可以用于与通信网络通信，如以太网，无线接入网(radio access network，RAN)，无线局域网(Wireless Local Area Networks，WLAN)等。收发器13可以包括接收单元实现接收功能，以及发送单元实现发送功能。

通信总线14，可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部监控设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture，EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图3中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

图3中示出的监控设备结构并不构成对监控设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

图4为本申请实施例提供的心跳监测方法的流程示意图，如图4所示，该方法可以包括以下步骤：

步骤401、监控设备超过第一门限时长未接收到被监控设备发送的数据包，则确定导致所述监控设备超过所述第一门限时长未接收到所述数据包的故障原因。

其中，所述数据包为心跳数据包或所述监控设备发送给所述被监控设备的心跳数据包对应的响应数据包。

具体地，发生心跳超时(即监控设备超过第一门限时长未接收到被监控设备发送的数据包)的原因，可以是被监控设备出现故障不能向监控设备发送数据包，也可以是监控设备与被监控设备之间的网络出现故障导致被监控设备发送的数据包。

在一些实施例中，可以查询被监控设备的运行记录，如果根据被监控设备的运行记录确定被监控设备在第一门限时长内是连续运行的，则确定故障原因为监控设备与被监控设备之间的网络故障。当然，如果查询被监控设备的连续运行记录确定被监控设备在第一门限时长内未连续运行，则确定所述故障原因为所述监控设备故障。在本发明实施例中，可以将监控设备与被监控设备之间的网络故障称为网络闪断，另外，可以将被监控设备故障称为宕机。

需要说明的是，被监控设备的运行记录可以是up time记录，也可以是运行日志。另外，监控设备可以查询被监控设备发生故障的故障时间点之前的一段时间内的运行记录，进而就可以根据被监控设备在这段时间内的运行记录确定被监控设备在第一门限时长内是否连续运行。示例的，示例的，监控设备在08:10:22接收到被监控设备的一个心跳数据包，心跳超时的门限时长为5s，08:10:27监控设备未接收到被监控设备的心跳数据包，则判断被监控设备心跳超时，并且故障时间点为08:10:27。进一步，监控设备查询被监控设备在故障时间点前10s内的运行记录，即08:10:17～08:10:27这段时间内被监控设备的运行记录。如果08:10:17～08:10:27这段时间内被监控设备是连续运行的，说明被监控设备在第一门限时长内是连续运行的。反之，如果08:10:17～08:10:27这段时间内被监控设备未连续运行，说明被监控设备在第一门限时长内未连续运行。

步骤402、所述监控设备根据所述故障原因以及所述第一门限时长确定第二门限时长，根据所述第二门限时长对所述被监控设备进行心跳监测。

具体实现中，所述第二门限时长用于减少预设时长内的业务迁移次数或预设时长内业务迁移的时长，所述业务迁移次数是由于所述监控设备与所述被监控设备之间的网络故障导致的业务迁移的次数，所述业务迁移的时长是由于所述被监控设备故障导致的业务迁移的时长。

需要说明的是，在NFV网络中，各个局点所采用的硬件和Cloud OS组合以及组网的规模呈现多样化，不同类型的硬件质量有差异，不同组网规模也会导致不同的网络质量。一方面，NFV网络中可以采用可靠性高的硬件组合或组网规模较小的局点，即H类局点。H类局点的网络状态及稳定性比较好，出现网络闪断的几率为零或极低，即使出现网络闪断，网络闪断持续的时长ΔT也非常短，远低于设置的门限时长T1，即本发明实施例所述的第一门限时长。

另一方面，NFV网络也可以采用可靠性低的硬件组合或组网规模庞大的局点，即L类局点。H类局点可能频繁出现网络网络闪断，并且网络闪断持续的时长ΔT较长。

如果设置的门限时长T1的值越小，T1+T2也越小，那么H类局点和L类局点的宕机故障导致的业务损失越小。但是，对于L类局点来说，网络网络闪断时长ΔT越容易满足T1<ΔT的条件，进而被判定心跳超时，导致业务越频繁迁移，业务损失越大。

如果T1的值越大，L类局点在出现网络闪断时，越不容易满足T1<ΔT的条件，从而不会触发业务频繁迁移，业务损失越小。但对于H类和L类局点，则需要更长的时间才能检测到宕机，并且由于心跳超时进行业务迁移时间会很长，业务损失越大。

但是，由于NFV网络中不同局点的软硬件组合、组网规模的稳定性，导致故障的可重现性、相似性，即局点出现一个故障后，后续有很大的几率会再次出现同样的故障。因此，可以根据故障原因对设置的门限时长进行灵活调整。如果当前故障原因为网络闪断，利用调整后的门限时长，可以有效的降低网络闪断触发业务迁移的几率，或者，当前故障原因为宕机，利用调整后的门限时长，可以有效缩短宕机导致心跳超时而进行的业务迁移对NFV网络的业务损失。通过自动检测故障原因、调整门限时长T1实现不同局点的故障快速检测，同时无需针对不同类型的局点设置不同的门限时长。

具体地，可以根据以下几种方式将第一门限时长更新为第二门限时长，具体包括：

第一、首先将第一门限时长为最大门限时长。

其中，最大门限时长可以是一次业务迁移的时长，如：上述SPU1的业务迁移到SPU2上所需要的时长T2。

进一步，若故障原因为监控设备与被监控设备之间的网络故障(即网络闪断)，则确定所述第二门限时长等于所述第一门限时长；后续过程中，被监控设备出现的故障很有可能仍是网络闪断，由于步骤401中网络闪断导致了心跳超时，即网络闪断持续的时长ΔT大于或等于第一门限时长T1，由于系统的稳定性，后续出现网络闪断时，网络闪断的时长有很大的可能仍大于第一门限时长T1。网络闪断时间过长，导致的网络长时间中断对NFV系统的业务损耗很大，因此当网络中断的时间大于业务迁移时间，不如直接进行业务迁移，保证业务尽快恢复，尽可能减少对NFV系统的业务损耗。

因此可以保持第一门限时长T1不变，即第二门限时长与第一门限时长相等。如此，后续网络闪断会触发业务迁移，减少对NFV系统的业务损耗。

若所述故障原因为所述监控设备与所述被监控设备故障(即宕机)，则确定所述第二门限时长小于所述第一门限时长。后续过程中，被监控设备出现的故障很有可能仍是宕机，那么可以适当缩短第一门限时长T1，后续可以通过更短的时间检测到宕机，进而也就缩短了心跳超时触发业务迁移给NFV网络带来的业务损失。具体实现中，可以按照一定比例系数或梯度缩短第一门限时长，比例系数为0～1之间的一个小数，示例的，选取的比例系数为0.8，第一门限时长为T1，则第二门限时长为0.8×T1。或者，按照梯度0.1来减少第一门限时长，假设第一门限时长为1s，若所述故障原因为所述监控设备与所述被监控设备故障(即宕机)，则确定所述第二门限时长为1-01＝0.9。

第二、将第一门限时长设置为最小门限时长。本发明实施例中，可以根据能够容忍的丢包个数来确定最小门限时长。示例的，连续丢10个心跳包，即监控设备连续发送10个心跳数据包都没有接收到被监控设备的响应数据包，则认为心跳超时。进一步，心跳周期为0.1秒，即监控设备每隔0.1秒发送一个心跳数据包，则最小的T1值可取1(0.1×10)秒。当然，上述实现方式仅仅是本发明实施例提供的一种确定最小门限时长的方式，还可以通过其他方式来确定最小门限时长，本发明实施例对比不作限定。

进一步，若所述故障原因为所述监控设备与所述被监控设备之间的网络故障，则确定所述第二门限时长大于所述第一门限时长。后续过程中，被监控设备出现的故障很有可能仍是网络闪断，适当的增加第一门限时长，后续出现网络闪断的持续时间就不容易大于门限时长，进而不会频繁触发业务迁移。

若所述故障原因为所述监控设备与所述被监控设备故障，则确定所述第二门限时长等于所述第一门限时长。后续过程中，被监控设备出现的故障很有可能仍是宕机，由于第一门限时长是最小了，那么可以保持第一门限时长不变，使得监控设备在后续过程中仍可以通过较短的时间检测到宕机，进而也就缩短了心跳超时触发业务迁移给NFV网络带来的业务损失。

第三、第一门限时长为大于最小门限时长小于最大门限时长的任意值。

若所述故障原因为所述监控设备与所述被监控设备之间的网络故障，则确定所述第二门限时长大于所述第一门限时长，且小于所述最大门限时长。也就是说，后续过程中，被监控设备出现的故障很有可能仍是网络闪断，适当的增加第一门限时长，后续出现网络闪断的持续时间就不容易大于门限时长，进而不会频繁触发业务迁移。

若所述故障原因为所述监控设备与所述被监控设备故障，则确定所述第二门限时长小于所述第一门限时长，且大于所述最小门限时长。后续过程中，被监控设备出现的故障很有可能仍是宕机，适当的调小第一门限时长，使得监控设备在后续过程中仍可以通过较短的时间检测到宕机，进而也就缩短了心跳超时触发业务迁移给NFV网络带来的业务损失。

第四、如果故障原因是网络闪断，还可以将前N次的网络闪断的持续时长的平均值作为新的门限时长，即本发明实施例所述的第二门限时长。

当然，还可以将前N次的网络闪断的持续时长的最大值作为新的门限时长。

如此，保证后续过程中出现网络闪断时，网络闪断持续的时长不容易大于第二门限时长，不会频繁触发业务迁移。

在一些实施例中，监控设备可以利用被监控设备的up time记录确定被监控设备的故障原因。具体地，如图5所示，包括以下步骤：

501、被监控设备在运行过程中生成up time记录。

具体地，被监控设备定时记录自身操作系统的累积运行时长，示例的，19:17:31up90days，10:03是up time记录中的一条记录，其中，“19:17:31”表示该记录记录的是被监控设备在19点17分31秒的累积运行时长；“up 90days，10:03”表示在19点17分31秒之前被监控设备已经连续运行了90天10分钟03秒。

502、监控设备通过心跳超时检测到被监控设备故障，并通知其他被监控设备进行业务迁移。

其中，故障原因可以是宕机或网络闪断。

503、在被监控设备恢复正常后，监控设备向被监控设备查询故障时的up time记录。

需要说明的是，被监控设备恢复正常即监控者重新接收到被监控设备发送的心跳数据包或响应数据包。

具体实现中，监控设备向被监控设备发送up time指令，被监控设备接收up time指令后查询上述up time记录，并将up time记录返回给监控设备。进一步，up time指令携带故障时间点，被监控设备接收到up time指令后以查询故障时间点为结束时间点的一个时间段内的up time记录，并将查询到的up time记录反馈给监控设备。

需要说明的是，故障时间点是监控设备确定被监控设备心跳超时的时间点。示例的，监控设备在08:10:22接收到被监控设备的一个心跳数据包，心跳超时的门限时长为5s，08:10:27监控设备未接收到被监控设备的心跳数据包，则判断被监控设备心跳超时，并且故障时间点为08:10:27。

504、监控设备根据查询到的up time记录确定被监控设备的故障原因。

具体实现中，如果故障时被监控设备运行记录为连续的，则故障原因为网络闪断，反之，如果故障时被监控设备运行记录是不连续的，则故障原因为宕机。

示例的，查询的记录是19:17:31up 90days，10:03，表明被监控设备已经运行了90天，则故障为网络网络闪断。

查询的记录是19:26:35up 0days,00:01，表明被监控设备已经运行1分钟，则说明故障为被监控设备宕机。

也就是说，如果监控设备接收到的up time记录中被监控设备连续运行的时间很短，如几秒，则说明运行不连续，故障原因为宕机；反之，如果监控设备接收到的up time记录中被监控设备连续运行的时间很长，则说明运行连续，故障原因为网络闪断。

在一些实施例中，在被监控设备故障时，监控者的心跳探测不停止，当判定为故障原因为网络闪断时，在故障恢复(即监控设备再次接收到被监控设备发送的数据包)后，监控者网络闪断的持续时长。具体地，监控设备可以计算心跳中断的时长，即为网络闪断的持续时长。其中，心跳中断的时长为监控设备在被监控设备故障之前一次接收到来自被监控设备的数据包的时刻，与监控设备在被监控设备故障恢复之后第一次接收到来自被监控设备的数据包的时刻之间的间隔。

本发明实施例中，被监控设备还可以通过将时间戳持久化到日志中来记录自身操作系统的累积运行时长。示例的，每隔一秒将当前时刻的运行状态记录到运行日志中，具体地：

2017-11-08 16:15:11Running(运行)

2017-11-08 16:15:12Running

2017-11-08 16:15:13Running

2017-11-08 16:15:14Running

2017-11-08 16:15:15Running

2017-11-08 16:15:16Running

......

当被监控者故障恢复后，监控设备向被监控设备查询故障时间段的运行日志，如果运行日志中记录的被监控设备在故障时间段的时间是连续的(或在故障时间段内有日志)，则说明故障原因为网络闪断，反之，故障原因为宕机。

示例的，监控设备在2017-11-08 16:20:16检测到故障，监控设备在2017年11月08号的16点20分16秒检测到心跳超时，则向被监控设备查询故障时间的运行日志。

假设查询到的结果是：

2017-11-08 16:20:15Running

2017-11-08 16:20:16Running

2017-11-08 16:20:17Running

2017-11-08 16:20:18Running

2017-11-08 16:20:19Running

以上日志中，被监控设备在故障时间2017-11-08 16:20:16为连续运行状态，表明心跳超时是由于网络闪断造成的。

2017-11-08 16:20:15Running

2017-11-08 16:20:16Running

2017-11-08 16:22:24Running

2017-11-08 16:22:25Running

2017-11-08 16:22:26Running

以上日志中，被监控设备在故障时间2017-11-08 16:20:16到2017-11-08 16:22:24之间并未连续运行，表明心跳超时是由于宕机造成的。

在一些实施例中，此外，还可以通过其他方法判断故障原因，即判断被监控设备在故障时间是否连续运行。例如，被监控设备的启动时间比较长，则进一步判断被监控设备心跳中断时长与被监控设备的启动时间是否接近。如果接近，则确定被监控设备重启了，进一步说明故障原因是被监控设备宕机。反之，如果心跳中断时长与被监控设备的启动时间相差较大，则说明故障原因是网络闪断。

其中，被监控设备心跳中断时长，可以认为是被监控设备发生故障的时间段，示例的，心跳超时的门限时长为1s，监控设备在16点20分08秒向被监控设备发送数据包，监控设备在16点20分09秒未接收到被监控设备反馈的响应数据包，判断被监控设备故障。随后被监控设备故障恢复后，向被监控设备发送响应数据包，监控设备在16点22分09秒接收到被监控设备发送的响应数据包。那么，监控设备确定被监控设备故障的时间为2分钟。进一步，如果被监控设备重启的时间接近2分钟，则确定故障原因为被监控设备宕机。

本发明实施例提供的心跳监测方法，监控设备在被监控设备心跳超时后，确定被监控设备心跳超时的故障原因，进而根据故障原因来调整对目前设备的门限时长进行调整，获得新的门限时长。由于故障具有可重现性、相似性，后续被监控设备有很大的几率会再次出现同样的故障，因此可以通过某一次的故障原因来调整门限时长，并根据新的门限时长在后续过程中对被监控设备进行心跳监测。如此，可以降低后续一段时间内被监控设备出现相同故障对系统业务的整体损耗。

上述主要从各个节点之间交互的角度对本申请实施例提供的方案进行了介绍。可以理解的是，监控设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对监控设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

在采用对应各个功能划分各个功能模块的情况下，图6示出了上述监控设备的一种可能的结构示意图。如图6所示，所述监控设备包括接收单元601、处理单元602。

接收单元601，用于支持所述监控设备执行上述实施例中的步骤503，和/或用于本文所描述的技术的其它过程，如：接收被监控设备上报的心跳。

处理单元602，用于支持所述监控设备执行上述实施例中的步骤401、402、502以及504，和/或用于本文所描述的技术的其它过程；

需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

示例性的，在采用集成的单元的情况下，本申请实施例提供的监控设备的结构示意图如图7所示。在图7中，该监控设备包括：处理模块701和通信模块702。处理模块701用于对监控设备的动作进行控制管理，例如，执行上述处理单元602执行的步骤，和/或用于执行本文所描述的技术的其它过程。通信模块702用于支持监控设备与其他设备之间的交互，例如，执行上述接收单元601执行的步骤。如图7所示，监控设备还可以包括存储模块703，存储模块703用于存储监控设备的程序代码和数据。

当处理模块701为处理器，通信模块702为收发器，存储模块703为存储器时，监控设备可以为图3所示的监控设备。如果收发器为接收器和发射器，接收器执行上述接收单元601所执行的步骤。

在上述实施例中，可以全部或部分的通过软件，硬件，固件或者其任意组合来实现。当使用软件程序实现时，可以全部或部分地以计算机程序产品的形式出现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质，(例如，软盘，硬盘、磁带)、光介质(例如，DVD)或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

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

监控设备超过第一门限时长未接收到被监控设备发送的数据包，则确定导致所述监控设备超过所述第一门限时长未接收到所述数据包的故障原因；所述数据包为心跳数据包或所述监控设备发送给所述被监控设备的心跳数据包对应的响应数据包，所述故障原因为所述被监控设备故障或所述监控设备与所述被监控设备之间的网络故障；

所述监控设备根据所述故障原因以及所述第一门限时长确定第二门限时长，根据所述第二门限时长对所述被监控设备进行心跳监测。

2.根据权利要求1所述的方法，其特征在于，所述监控设备确定所述被监控设备的故障原因具体包括：

查询所述被监控设备的运行记录确定所述被监控设备在所述第一门限时长内连续运行，则确定所述故障原因为所述监控设备与所述被监控设备之间的网络故障；查询所述被监控设备的连续运行记录确定所述被监控设备在所述第一门限时长内未连续运行，则确定所述故障原因为所述被监控设备故障。

3.根据权利要求1或2所述的方法，其特征在于，所述第一门限时长为最大门限时长，

所述监控设备根据所述故障原因将所述第一门限时长更新为第二门限时长具体包括：

若所述故障原因为所述监控设备与所述被监控设备之间的网络故障，则确定所述第二门限时长等于所述第一门限时长；

若所述故障原因为所述监控设备与所述被监控设备故障，则确定所述第二门限时长小于所述第一门限时长。

4.根据权利要求1或2所述的方法，其特征在于，所述第一门限时长为最小门限时长，

所述监控设备根据所述故障原因将所述第一门限时长更新为第二门限时长具体包括：

若所述故障原因为所述监控设备与所述被监控设备之间的网络故障，则确定所述第二门限时长大于所述第一门限时长；

若所述故障原因为所述监控设备与所述被监控设备故障，则确定所述第二门限时长等于所述第一门限时长。

5.根据权利要求1或2所述的方法，其特征在于，所述第一门限时长为大于最小门限时长小于最大门限时长的任意值，

所述监控设备根据所述故障原因将所述第一门限时长更新为第二门限时长具体包括：

若所述故障原因为所述监控设备与所述被监控设备之间的网络故障，则确定所述第二门限时长大于所述第一门限时长，且小于所述最大门限时长；

若所述故障原因为所述监控设备与所述被监控设备故障，则确定所述第二门限时长小于所述第一门限时长，且大于所述最小门限时长。

6.一种监控设备，其特征在于，包括：

处理单元，用于在接收单元超过第一门限时长未接收到被监控设备发送的数据包时，确定导致所述监控设备超过所述第一门限时长未接收到所述数据包的故障原因；所述数据包为心跳数据包或所述监控设备发送给所述被监控设备的心跳数据包对应的响应数据包，所述故障原因为所述被监控设备故障或所述监控设备与所述被监控设备之间的网络故障；

所述处理单元还用于，根据所述故障原因以及所述第一门限时长确定第二门限时长，根据所述第二门限时长对所述被监控设备进行心跳监测。

7.根据权利要求6所述的监控设备，其特征在于，所述处理单元具体用于，查询所述被监控设备的运行记录确定所述被监控设备在所述第一门限时长内连续运行，则确定所述故障原因为所述监控设备与所述被监控设备之间的网络故障；查询所述被监控设备的连续运行记录确定所述被监控设备在所述第一门限时长内未连续运行，则确定所述故障原因为所述被监控设备故障。

8.根据权利要求6或7所述的监控设备，其特征在于，所述第一门限时长为最大门限时长，

所述处理单元具体用于，若所述故障原因为所述监控设备与所述被监控设备之间的网络故障，则确定所述第二门限时长等于所述第一门限时长；

若所述故障原因为所述监控设备与所述被监控设备故障，则确定所述第二门限时长小于所述第一门限时长。

9.根据权利要求6或7所述的监控设备，其特征在于，所述第一门限时长为最小门限时长，

所述处理单元具体用于，若所述故障原因为所述监控设备与所述被监控设备之间的网络故障，则确定所述第二门限时长大于所述第一门限时长；

若所述故障原因为所述监控设备与所述被监控设备故障，则确定所述第二门限时长等于所述第一门限时长。

10.根据权利要求6或7所述的监控设备，其特征在于，所述第一门限时长为大于最小门限时长小于最大门限时长的任意值，

所述处理单元具体用于，若所述故障原因为所述监控设备与所述被监控设备之间的网络故障，则确定所述第二门限时长大于所述第一门限时长，且小于所述最大门限时长；

若所述故障原因为所述监控设备与所述被监控设备故障，则确定所述第二门限时长小于所述第一门限时长，且大于所述最小门限时长。

Images