CN109714202B - 一种客户端离线原因判别方法和集群式安全管理*** - Google Patents

Abstract

本申请公开了一种客户端离线原因判别方法和集群式安全管理***，该方法包括：判断是否在心跳时间周期内接收到心跳信息；如果否，判定客户端离线，并将离线原因初步判定为网络故障或强制关机；监控进程循环读取心跳时间文件，并判断心跳时间文件记录的时刻与当前时刻之差是否大于一次心跳周期；如果是，判定未收到心跳成功回复；监控进程搜集主进程信息并发送至管理平台；根据主进程信息更新客户端离线原因。集群式安全管理***包括管理平台和多个客户端，管理平台包括数据库、通讯组件、Web服务器以及主程序模块，客户端包括主进程模块和监控进程模块。通过本申请能够提高客户端离线原因的排查效率，提高管理平台和客户端之间的通信稳定性。

Description

一种客户端离线原因判别方法和集群式安全管理***

技术领域

本申请涉及安全管理技术领域，特别是涉及一种客户端离线原因判别方法和集群式安全管理***。

背景技术

在安全管理***中，信息安全越来越引起人们的重视。传统的安全软件一般安装在单台资源上，例如单台计算机、服务器或智能终端上，在单台计算机上配置安全策略并查看执行情况。随着大数据和云计算的发展，安全软件逐渐向集群化方向发展，集群化的安全软件主要包括管理平台和客户端，管理平台用于管理客户端，客户端用于负责具体安全策略的执行和策略执行结果的反馈。

在集群化的安全软件中，客户端能否正常运作并连接到管理平台上，对于***的稳定运行是非常重要的。在一般的应用场景下，管理平台和客户端之间的网络是可靠的，但是对于某些特定的应用场景，如距离较远的分布式终端，客户端与管理平台之间的通讯网络有时候是是不可靠的。当通讯网络不可靠时，会出现客户端离线，判断客户端的离线原因，进而根据离线原因继续处理，是个重要的问题。

目前的集群化安全软件中，管理平台发现客户端离线后，就暂停对客户端的管理，在客户端进行故障排查，直到故障处理后重新启动管理平台对客户端的管理。

然而，目前对客户端离线原因的排查方法中，由于需要中断管理平台和客户端之间的通信，进行线下排查，排查效率低，影响安全软件的正常运行，不利于对整个***的安全保护。

发明内容

本申请提供了一种客户端离线原因判别方法和集群式安全管理***，以解决现有技术中对客户端离线原因的排查效率低、影响安全软件正常运行以及不利于整个***的安全保护的问题。

为了解决上述技术问题，本申请实施例公开了如下技术方案：

一种客户端离线原因判别方法，应用于集群式安全管理***中，所述集群式安全管理***中包括管理平台和多个客户端，所述客户端安装于需要进行安全保护的计算机上，所述管理平台安装于一***立的计算机上，所述管理平台与客户端之间通过消息总线连接，所述客户端中设置有主进程和监控进程，所述方法包括：

判断管理平台是否在第一周期内接收到客户端的心跳信息，所述第一周期为一次正常心跳周期；

如果否，判定客户端离线，并将客户端离线原因初步判定为网络故障或强制关机；

监控进程循环读取存储于主进程中的心跳时间文件，并判断所述心跳时间文件中记录的时刻与当前时刻之差是否大于第一周期，所述心跳时间文件用于记录管理平台回复客户端心跳成功的时刻；

如果是，判定客户端未收到管理平台的心跳成功回复；

监控进程每隔第二周期搜集主进程信息，并将所述主进程信息发送至管理平台，所述第二周期为监控进程对主进程进行相邻两次监控的时间间隔，所述主进程信息包括：主进程所占用的CPU大小、主进程内存大小、主进程的线程数、主进程的句柄数，以及主进程软件目录下是否有dump文件且所述dump文件的产生时刻在所述心跳时间文件中记录的时刻之后；

根据所述主进程信息更新客户端离线原因。

可选地，判断管理平台是否在第一周期内接收到客户端的心跳信息之前，所述方法还包括：

客户端通过消息总线向管理平台发送心跳消息；

管理平台通过消息总线接收到所述心跳消息时，向客户端返回一心跳成功回复；

客户端通过消息总线接收到所述心跳成功回复时，将心跳成功回复的时刻写入心跳时间文件。

可选地，监控进程将所述主进程信息发送至管理平台的方法，具体为：

监控进程通过消息总线将所述主进程信息以特定格式发送至管理平台，所述特定格式包括：消息队列名称或命令字。

可选地，所述根据所述主进程信息更新客户端离线原因，包括：

判断主进程是否在运行；

如果主进程停止运行，判断是否有dump文件产生；

如果有dump文件，将离线原因更新为软件崩溃；

如果没有dump文件，将离线原因更新为其他原因关闭；

如果主进程在运行，判断所述主进程信息中的参数是否在正常参数范围内；

如果是，将离线原因更新为其他原因；

如果否，将离线原因更新为软件异常。

可选地，所述方法还包括：

当客户端***主动关机时，客户端通过消息总线向管理平台发送第一消息，所述第一消息中包括：***关闭或重启；

当客户端通过管理工具手动停止客户端主程序时，客户端通过消息总线向管理平台发送第二消息，所述第二消息中包括：软件手动关闭。

可选地，根据所述主进程信息更新客户端离线原因之前，所述方法还包括：

判断管理平台是否收到客户端所发送的第一消息；

如果是，将离线原因更新为***关闭或重启；

如果否，判断管理平台是否收到客户端所发送的第二消息；

如果管理平台收到客户端所发送的第二消息，将离线原因更新为软件手动关闭。

一种集群式安全管理***，所述集群式安全管理***中包括管理平台和多个客户端，所述客户端安装于需要进行安全保护的计算机上，所述管理平台安装于一***立的计算机上，所述管理平台与客户端之间通过消息总线连接，所述管理平台包括：数据库、通讯组件、Web服务器以及主程序模块，所述客户端中包括主进程模块和监控进程模块；

所述主程序模块，用于判断管理平台是否在第一周期内接收到客户端的心跳信息，以及，当管理平台没有在第一周期内接收到客户端的心跳信息时，判定客户端离线，并将客户端离线原因初步判定为网络故障或强制关机，所述第一周期为一次正常心跳周期；

所述主进程模块，用于运行客户端所有业务功能或逻辑；

所述监控进程模块，用于循环读取存储于主进程模块中的心跳时间文件，并判断所述心跳时间文件中记录的时刻与当前时刻之差是否大于第一周期，以及，当所述心跳时间文件中记录的时刻与当前时刻之差大于第一周期时，判定客户端未收到管理平台的心跳成功回复，所述心跳时间文件用于记录管理平台回复客户端心跳成功的时刻；

所述监控进程模块还用于，每隔第二周期搜集主进程模块的主进程信息，并将所述主进程信息发送至管理平台，所述第二周期为监控进程模块对主进程模块连续进行两次监控的时间间隔；

所述主程序模块还用于，根据所述主进程信息更新客户端离线原因。

可选地，所述主程序模块包括：

判断单元，用于判断管理平台是否在第一周期内接收到客户端的心跳信息；

离线原因初步判定单元，用于当管理平台没有在第一周期内接收到客户端的心跳信息时，判定客户端离线，并将客户端离线原因初步判定为网络故障或强制关机；

离线原因更新单元，用于根据所述主进程信息更新客户端离线原因。

可选地，所述离线原因更新单元包括：

第一判断子单元，用于判断主进程是否正在进行；

第二判断子单元，用于当主进程停止运行时，判断是否有dump文件产生；

第三判断子单元，用于当主进程在运行时，判断所述主进程信息中的参数是否在正常参数范围内；

更新子单元，用于当第二判断子单元判定有dump文件时，将离线原因更新为软件崩溃，当第二判断子单元判定没有dump文件时，将离线原因更新为其他原因关闭，当第三判断子单元判定所述主进程信息中的参数在正常参数范围内时，将离线原因更新为其他原因，以及，当第三判断子单元判定所述主进程信息中的参数不在正常参数范围内时，将离线原因更新为软件异常。

可选地，所述客户端中还包括：

第一消息发送模块，用于当客户端***主动关机时，通过消息总线向管理平台发送第一消息，所述第一消息中包括：***关闭或重启；

第二消息发送模块，用于当客户端通过管理工具手动停止客户端主程序时，通过消息总线向管理平台发送第二消息，所述第二消息中包括：软件手动关闭。

本申请的实施例提供的技术方案可以包括以下有益效果：

本申请提供一种客户端离线原因判别方法，该方法应用于集群式安全管理***中，该方法首先判断管理平台是否在一次正常心跳周期内接收到客户端的心跳信息，如果否，判定客户端离线，并将客户端离线原因初步判定为网络故障或强制关机，其次通过客户端的监控进程循环读取心跳时间文件，并判断心跳时间文件中记录的时刻与当前时刻之差是否大于第一周期，如果是，判定客户端没有收到管理平台的心跳成功回复，也就是最后一次正常心跳之后，客户端主进程发生异常。然后监控进程每隔第二周期的时间搜集主进程信息，并将所搜集的主进程信息发送至管理平台，管理平台根据主进程信息更新客户端离线原因。本申请通过运行于客户端中的监控进程对主进程进行监控，能够及时将主进程的异常上传至管理平台，管理平台根据客户端监控进程所上传的信息自动判断客户端离线原因，能够大大提高客户端离线原因的排查效率。而且本申请中的方法可以在线进行，因此不影响安全软件的正常运行，有利于提高管理平台和客户端之间的通信稳定性。管理平台采用离线原因初步判断和更新离线原因的方式，最终确定客户端离线原因，能够结合客户端主进程信息进行更加准确的判断，有利于提高离线原因判断的准确性和可靠性。另外，本申请中运行于客户端的监控进程属于轻量级进程，其业务逻辑少，运行稳定，有利于及时而准确地通过消息总线向管理平台发送主进程信息，能够进一步提高客户端离线原因判断的准确性。

本申请还提供一种集群式安全管理***，该***主要包括管理平台和多个客户端，其中管理平台和客户端之间通过消息总线连接，管理平台包括：数据库、通讯组件、Web服务器以及主程序模块，客户端中包括主进程模块和监控进程模块。本实施例中的集群式安全管理***除了能够对客户端进行正常的逻辑业务之外，通过主程序模块能够判断是否在一次正常心跳周期内接收到客户端的心跳信息，从而判断客户端是否为离线，当判定客户端离线时，将客户端离线原因初步判定为网络故障或强制关机。其次，监控进程模块循环读取存储于主进程模块中的心跳时间文件，并判断心跳时间文件中记录的时刻与当前时刻之差是否大于第一周期，如果是判定客户端未收到管理平台的心跳成功回复，监控进程每隔第二周期的时间搜集主进程信息，并将主进程信息发送至管理平台。主进程模块还用于根据主进程信息更新客户端离线原因。本申请通过在客户端中设置一监控进程模块，能够及时对客户端的主进程模块进行监控，并将异常上传至管理平台，管理平台根据监控进程模块所上传的信息分别对客户端离线原因进行初步判定和更新，从而更加准确地判定客户端的离线原因，进而提高管理平台和客户端之间的通信稳定性。另外，本申请中监控进程模块所进行的是一种轻量级进程，所占用的***资源少，且其自身业务逻辑少，使得监控进程模块的可靠性较高，有利于及时而准确地通过消息总线向管理平台发送主进程信息，能够进一步提高客户端离线原因判断的准确性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

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

图1为本申请实施例所提供的一种客户端离线原因判别方法的流程示意图；

图2为本申请实施例中步骤S14的实现过程示意图；

图3为本申请实施例中管理平台和客户端之间的信息传递关系示意图；

图4为本申请实施例所提供的一种集群式安全管理***的结构示意图。

具体实施方式

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

本实施例中客户端离线原因判别方法主要应用于集群式安全管理***中。通常一个集群式安全管理***中包括管理平台和客户端两种子***。管理平台有一个，一般安装于单独的机器上，用于统一管理客户端；客户端有多个，分别安装在需要进行安全保护的计算机上，负责具体的安全策略的执行和策略执行结果的反馈。本实施例的客户端中同时运行着主进程和监控进程，主进程运行着客户端所有的业务功能或逻辑，功能全面但稳定性相对较低，监控进程用于对主进程进行监控，是一个轻量级的进程，业务逻辑少，稳定性和可靠性比较高。

本实施例中的客户端通过消息总线与管理平台连接，也就是通过网络与管理平台通信连接。客户端在使用时需要注册到管理平台上，注册完成后，管理平台通过Web界面的方式展现所有已经注册的客户端的列表，管理员通过Web界面对客户端配置安全策略并且进行审计。对于每一个注册上来的客户端，管理平台维护其在线状态，客户端在线状态包括在线或离线，离线时，采用本申请中的方法从管理平台端初步了解离线原因，以方便定位问题，迅速诊断。

本实施例中，客户端每隔一段时间向管理平台发送一个内容很短的心跳消息，管理平台接收到心跳消息后，认为该客户端是在线的；当一段时间之内管理平台没有收到某客户端的心跳消息时，则认为该客户端时离线的。同时，客户端向管理平台发送的消息，管理平台会给出一个内容很短的应答，当客户端收不到应答消息时，客户端判定自身是离线的。本实施例中默认管理平台和消息总线均一直稳定运行、不会出现崩溃、网络断开等情况。且默认管理平台与消息总线之间的通道是稳定运行的，不会出现断开或丢失数据的情况。

为了更好地理解本申请，下面结合附图来详细解释本申请的实施方式。

实施例一

参见图1，图1为本申请实施例所提供的一种客户端离线原因判别方法的流程示意图。由图1可知，本实施例中客户端离线原因判别方法主要包括如下过程：

S04：判断管理平台是否在第一周期内接收到客户端的心跳信息。其中，第一周期为一次正常心跳周期。

S05：如果否，判定客户端离线，并将客户端离线原因初步判定为网络故障或强制关机。

如果管理平台在一次正常心跳周期内接收到客户端的心跳消息，判定客户端在线。

由以上步骤S04和S05可知，首先通过确定管理平台是否在第一周期内接收到客户端的心跳信息，判断客户端是否离线，当判定客户端离线时开始分析离线原因。由于管理平台和客户端互相不知道IP地址，而且有可能存在子网的情况，当客户端离线时，对于客户端来说，是因为设备网络故障导致离线还是突然掉电等原因导致强制关机，并不能进行区分，因此，将客户端离线原因初步判定为网络故障或强制关机。

进一步地，本实施例在步骤S04之前还包括：

S01：客户端通过消息总线向管理平台发送心跳消息。

本实施例中管理平台和客户端通过消息总线连接，也就是管理平台和客户端均连接到消息总线上，向消息总线发送消息并从消息总线接收消息，管理平台无法向客户端主动发起请求，只能根据客户端的心跳消息进行回复。

S02：管理平台通过消息总线接收到心跳消息时，向客户端返回一心跳成功回复。

S03：客户端通过消息总线接收到心跳成功回复时，将心跳成功回复的时刻写入心跳时间文件。

当客户端接收到心跳成功回复时，更新一个心跳时间文件，将本次成功的心跳回复时间写入心跳时间文件，一次正常的心跳完成。其中，心跳时间文件用于记录管理平台回复客户端心跳成功的时刻。

继续参见图1可知，通过步骤S05将客户端离线原因初步判定为网络故障或强制关机之后，执行步骤S06：监控进程循环读取存储于主进程中的心跳时间文件，并判断心跳时间文件中记录的时刻与当前时刻之差是否大于第一周期。

S07：如果是，判定客户端未收到管理平台的心跳成功回复。

如果心跳时间文件中记录的时刻与当前时刻之差大于一次正常心跳周期，也就是，从心跳时间文件中记录的时刻起到当前时刻止的时间超过一次正常心跳周期，说明客户端没有在一次正常心跳周期内收到管理平台的心跳成功回复。如果心跳时间文件中记录的时刻与当前时刻之差小于或等于一次正常心跳周期，判定客户端能够正常收到管理平台的心跳成功回复。

当客户端未收到管理平台的心跳成功回复时，执行步骤S08：监控进程每隔第二周期搜集主进程信息，并将主进程信息发送至管理平台。其中，第二周期为监控进程对主进程进行相邻两次监控的时间间隔。

本实施例客户端中除了正常运行主进程之外，还运行监控进程，监控进程将主进程信息发送至管理平台的方法，具体为：

监控进程通过消息总线将主进程信息以特定格式发送至管理平台，特定格式包括：消息队列名称或命令字。消息总线可以采用消息队列软件，例如：RabbitMQ等。在通讯时，消息总线上的消息内容有特定的格式，例如：可以采用消息队列名称或命令字等字段来区分不同的消息种类。

本实施例通过客户端的监控进程对主进程进行循环监控，能够及时将主进程的异常上传至管理平台，从而能够大大提高客户端离线原因的排查效率。而且，运行于客户端的监控进程属于轻量级进程，其业务逻辑少，运行稳定，有利于及时而准确地通过消息总线向管理平台发送主进程信息，能够进一步提高客户端离线原因判断的准确性。

本实施例中主进程信息包括：主进程所占用的CPU大小、主进程内存大小、主进程的线程数、主进程的句柄数，以及主进程软件目录下是否有dump文件且dump文件的产生时刻在心跳时间文件中记录的时刻之后。需要注意的是，判断主进程软件目录下是否有dump文件时，所判断的dump文件产生的范围是：心跳时间文件中所记录的时刻之后所产生的dump文件，即：心跳时间文件中所记录的时刻之后产生的dump文件，表示最后一次正常的心跳之后，客户端主进程发生崩溃或异常。

本实施例中第一周期和第二周期的大小，根据实际的应用场景进行设置，例如：需要频繁更新监控结果的，第二周期设置的可以小一些。

S14：根据主进程信息更新客户端离线原因。

本实施例中管理平台所判定的客户端离线原因主要包括：网络故障或强制关机、***关闭或重启、软件手动关闭、软件崩溃、软件异常、其他原因关闭以及其他原因。

参见图2可知，步骤S14包括如下过程：

S141：判断主进程是否在运行；

如果主进程停止运行，执行步骤S142：判断是否有dump文件产生；

如果有dump文件，执行步骤S143：将离线原因更新为软件崩溃；

否则，如果没有dump文件，执行步骤S144：将离线原因更新为其他原因关闭；

如果主进程在运行，执行步骤S145：判断主进程信息中的参数是否在正常参数范围内；

如果主进程信息中的参数在正常参数范围内，执行步骤S146：将离线原因更新为其他原因；

如果主进程信息中的参数不在正常参数范围内，执行步骤S147：将离线原因更新为软件异常。

当软件异常时，相关性能参数会超出异常范围，同时心跳的发送和接收也会产生障碍，会导致客户端离线。

进一步地，本实施例的客户端离线原因判别方法中还包括：

当客户端***主动关机时，客户端通过消息总线向管理平台发送第一消息，其中第一消息中包括：***关闭或重启。

当客户端通过管理工具手动停止客户端主程序时，客户端通过消息总线向管理平台发送第二消息，其中第二消息中包括：软件手动关闭。

本实施例中客户端主进程能够捕捉客户端***的关机信号，当客户端***主动关机时，主进程通过消息总线向管理平台发送第一消息，且在第一消息中说明客户端离线原因为：***关闭或重启；当用户通过客户端管理工具手动停止客户端主进程时，客户端主进程通过消息总线向管理平台发送第二消息，且第二消息中说明客户端离线原因为：手动关闭。

进一步地，步骤S14之前，客户端离线原因判别方法还包括：

S10：判断管理平台是否收到客户端所发送的第一消息；

如果收到客户端所发送的第一消息，则执行步骤S11：将离线原因更新为***关闭或重启；否则，执行步骤S12：判断管理平台是否收到客户端所发送的第二消息；如果收到客户端所发送的第二消息，则执行步骤S13：将离线原因更新为软件手动关闭。如果没有收到客户端所发送的第二消息，则执行步骤S14。

当然，本实施例中也可以先执行步骤S12，如果没有收到客户端所发送的第二消息，执行步骤S10，如果收到客户端所发送的第一消息则执行步骤S11，否则执行步骤S14。即：没有收到客户端所发送的第一消息和第二消息时，执行步骤S14，先根据客户端直接上传的离线原因更新客户端离线原因，然后根据客户端主进程信息更新客户端离线原因。

下面以一个实际应用场景为例，详细描述本实施例中的方法。参见图3，由图3可知，管理平台与消息总线进行通讯，如图3中(1)所示；客户端主进程和监控进程与消息总线通讯，如图3中(2)所示。在通讯时，消息总线中的消息内容有特定的格式，客户端发送特定格式的消息时，只有管理平台特定的模块会接收并处理该信息，反之，管理平台所发送的消息也由客户端的特定模块接收并处理。即：管理平台的特定模块与客户端的相应模块匹配，从外部来看管理平台和客户端之间有虚拟通道。在图3中，这样虚拟的通道采用虚线箭头。

正常工作时，客户端主进程的心跳发送模块向管理平台的心跳接收模块发送心跳信息，如图3中(3)所示；管理平台的心跳接收模块接收到心跳消息后，返回一个成功消息，如图3中(4)所示，并且更新客户端的在线状态为“在线”，如果已经是在线状态了，则不更新。如果连续一段时间接收不到心跳消息，则认为客户端的在线状态为“离线”，并且暂定认为离线原因是“网络故障或强制关机”。当客户端接收到心跳成功回复时，则更新一个心跳时间文件，将该次成功的心跳回复时间写入该文件，一次正常的心跳完成。

另外客户端运行着监控进程，监控一直运行并循环检测心跳时间文件，如果心跳时间文件里面记录的时间与当前的时间之差超过了一定的阈值，则认为客户端很久没有收到管理平台的成功心跳回复，此时监控进程会进行信息搜集，如图3中(5)所示。搜集主进程占用的CPU、内存大小、线程数、句柄数，主进程软件目录下是否有新产生的dump文件，且新产生的dump文件的时刻范围是心跳时间文件中记录的时间之后，即认为最后一次正常的心跳后，客户端主进程发生了崩溃或异常。

搜集完信息后，监控进程将所搜集的信息以特定格式发送至管理平台的信息接收模块，如图3中(6)所示。管理平台的信息接收模块接收到该信息后，进行分析处理，处理后更新客户端离线的原因，具体的更新策略为：

A)首先根据客户端上传的信息，判断是否是因为手动关闭主进程或重启***/关闭***引起的，如果是则直接更新原因为“***关闭或重启”或“软件手动关闭”。

B)否则继续查看主进程是否在运行，如果不在运行，则判断是否有dump文件，如果有，则更新离线原因为“软件崩溃”，如果没有dump文件，则更新离线原因为“其他原因关闭”；如果主进程软件在运行，则判断信息中包含的主进程的CPU、内存、句柄数、线程数等参数是否在正常范围之内，如果超出了正常范围，则更新离线原因为“软件异常”；如果这些参数均在正常范围之内，则更新离线原因为“其他原因”。

实施例二

本申请还提供一种集群式安全管理***，集群式安全管理***中包括管理平台和多个客户端，客户端安装于需要进行安全保护的计算机上，管理平台安装于一***立的计算机上，管理平台与客户端之间通过消息总线连接。

在图1-图3所示实施例的基础之上参见图4，图4为本申请实施例所提供的一种集群式安全管理***的结构示意图。由图4可知，本实施例中管理平台包括：数据库、通讯组件、Web服务器以及主程序模块，客户端中包括主进程模块和监控进程模块。

其中，主程序模块用于判断管理平台是否在第一周期内接收到客户端的心跳信息，以及，当管理平台没有在第一周期内接收到客户端的心跳信息时，判定客户端离线，并将客户端离线原因初步判定为网络故障或强制关机，其中，第一周期为一次正常心跳周期；主进程模块用于运行客户端所有业务功能或逻辑；监控进程模块用于循环读取存储于主进程模块中的心跳时间文件，并判断心跳时间文件中记录的时刻与当前时刻之差是否大于第一周期，以及，当心跳时间文件中记录的时刻与当前时刻之差大于第一周期时，判定客户端未收到管理平台的心跳成功回复，心跳时间文件用于记录管理平台回复客户端心跳成功的时刻；监控进程模块还用于，每隔第二周期搜集主进程模块的主进程信息，并将主进程信息发送至管理平台，第二周期为监控进程模块对主进程模块连续进行两次监控的时间间隔；主程序模块还用于根据主进程信息更新客户端离线原因。

进一步地，主进程模块包括：判断单元、离线原因初步判定单元和离线原因更新单元。其中，判断单元用于判断管理平台是否在第一周期内接收到客户端的心跳信息，第一周期为一次正常心跳周期；离线原因初步判定单元用于当管理平台没有在第一周期内接收到客户端的心跳信息时，判定客户端离线，并将客户端离线原因初步判定为网络故障或强制关机；离线原因更新单元，用于根据主进程信息更新客户端离线原因。

其中，离线原因更新单元又包括：第一判断子单元、第二判断子单元、第三判断子单元和更新子单元。其中，第一判断子单元用于判断主进程是否正在进行；第二判断子单元用于当主进程停止运行时，判断是否有dump文件产生；第三判断子单元用于当主进程在运行时，判断主进程信息中的参数是否在正常参数范围内；更新子单元用于当第二判断子单元判定有dump文件时，将离线原因更新为软件崩溃，当第二判断子单元判定没有dump文件时，将离线原因更新为其他原因关闭，当第三判断子单元判定主进程信息中的参数在正常参数范围内时，将离线原因更新为其他原因，以及，当第三判断子单元判定主进程信息中的参数不在正常参数范围内时，将离线原因更新为软件异常。也就是，更新子单元用于根据第二判断单元和第三判断单元的判断结果，分别更新相应的离线原因。

进一步地，客户端中还包括第一消息发送模块和第二消息发送模块，其中，第一消息发送模块用于当客户端***主动关机时，通过消息总线向管理平台发送第一消息，第一消息中包括：***关闭或重启；第二消息发送模块用于当客户端通过管理工具手动停止客户端主程序时，通过消息总线向管理平台发送第二消息，第二消息中包括：软件手动关闭。

本实施例中集群式安全管理***的工作原理和工作方法，在图1-图3所示的实施例中已经详细阐述，两者之间客户互相参照，在此不再赘述。

以上所述仅是本申请的具体实施方式，使本领域技术人员能够理解或实现本申请。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (7)

1.一种客户端离线原因判别方法，应用于集群式安全管理***中，所述集群式安全管理***中包括管理平台和多个客户端，所述客户端安装于需要进行安全保护的计算机上，所述管理平台安装于一***立的计算机上，其特征在于，所述管理平台与客户端之间通过消息总线连接，所述客户端中设置有主进程和监控进程，所述方法包括：

判断管理平台是否在第一周期内接收到客户端的心跳信息，所述第一周期为一次正常心跳周期；

如果否，判定客户端离线，并将客户端离线原因初步判定为网络故障或强制关机；

监控进程循环读取存储于主进程中的心跳时间文件，并判断所述心跳时间文件中记录的时刻与当前时刻之差是否大于第一周期，所述心跳时间文件用于记录管理平台回复客户端心跳成功的时刻；

如果是，判定客户端未收到管理平台的心跳成功回复；

监控进程每隔第二周期搜集主进程信息，并将所述主进程信息发送至管理平台，所述第二周期为监控进程对主进程进行相邻两次监控的时间间隔，所述主进程信息包括：主进程所占用的CPU大小、主进程内存大小、主进程的线程数、主进程的句柄数，以及主进程软件目录下是否有dump文件且所述dump文件的产生时刻在所述心跳时间文件中记录的时刻之后；

根据所述主进程信息更新客户端离线原因；

其中，所述根据所述主进程信息更新客户端离线原因，包括：

判断主进程是否在运行；

如果主进程停止运行，判断是否有dump文件产生；

如果有dump文件，将离线原因更新为软件崩溃；

如果没有dump文件，将离线原因更新为其他原因关闭；

如果主进程在运行，判断所述主进程信息中的参数是否在正常参数范围内；

如果是，将离线原因更新为其他原因；

如果否，将离线原因更新为软件异常。

2.根据权利要求1所述的一种客户端离线原因判别方法，其特征在于，判断管理平台是否在第一周期内接收到客户端的心跳信息之前，所述方法还包括：

客户端通过消息总线向管理平台发送心跳消息；

管理平台通过消息总线接收到所述心跳消息时，向客户端返回一心跳成功回复；

客户端通过消息总线接收到所述心跳成功回复时，将心跳成功回复的时刻写入心跳时间文件。

3.根据权利要求1所述的一种客户端离线原因判别方法，其特征在于，监控进程将所述主进程信息发送至管理平台的方法，具体为：

监控进程通过消息总线将所述主进程信息以特定格式发送至管理平台，所述特定格式包括：消息队列名称或命令字。

4.根据权利要求1所述的一种客户端离线原因判别方法，其特征在于，所述方法还包括：

当客户端***主动关机时，客户端通过消息总线向管理平台发送第一消息，所述第一消息中包括：***关闭或重启；

当客户端通过管理工具手动停止客户端主程序时，客户端通过消息总线向管理平台发送第二消息，所述第二消息中包括：软件手动关闭。

5.根据权利要求4所述的一种客户端离线原因判别方法，其特征在于，根据所述主进程信息更新客户端离线原因之前，所述方法还包括：

判断管理平台是否收到客户端所发送的第一消息；

如果是，将离线原因更新为***关闭或重启；

如果否，判断管理平台是否收到客户端所发送的第二消息；

如果管理平台收到客户端所发送的第二消息，将离线原因更新为软件手动关闭。

6.一种集群式安全管理***，所述集群式安全管理***中包括管理平台和多个客户端，所述客户端安装于需要进行安全保护的计算机上，所述管理平台安装于一***立的计算机上，其特征在于，所述管理平台与客户端之间通过消息总线连接，所述管理平台包括：数据库、通讯组件、Web服务器以及主程序模块，所述客户端中包括主进程模块和监控进程模块；

所述主程序模块，用于判断管理平台是否在第一周期内接收到客户端的心跳信息，以及，当管理平台没有在第一周期内接收到客户端的心跳信息时，判定客户端离线，并将客户端离线原因初步判定为网络故障或强制关机，所述第一周期为一次正常心跳周期；

所述主进程模块，用于运行客户端所有业务功能或逻辑；

所述监控进程模块，用于循环读取存储于主进程模块中的心跳时间文件，并判断所述心跳时间文件中记录的时刻与当前时刻之差是否大于第一周期，以及，当所述心跳时间文件中记录的时刻与当前时刻之差大于第一周期时，判定客户端未收到管理平台的心跳成功回复，所述心跳时间文件用于记录管理平台回复客户端心跳成功的时刻；

所述监控进程模块还用于，每隔第二周期搜集主进程模块的主进程信息，并将所述主进程信息发送至管理平台，所述第二周期为监控进程模块对主进程模块连续进行两次监控的时间间隔；

所述主程序模块还用于，根据主进程模块的主进程信息更新客户端离线原因；

其中，所述主程序模块包括：

判断单元，用于判断管理平台是否在第一周期内接收到客户端的心跳信息；

离线原因初步判定单元，用于当管理平台没有在第一周期内接收到客户端的心跳信息时，判定客户端离线，并将客户端离线原因初步判定为网络故障或强制关机；

离线原因更新单元，用于根据所述主进程模块的主进程信息更新客户端离线原因；

所述离线原因更新单元包括：

第一判断子单元，用于判断主进程是否正在进行；

第二判断子单元，用于当主进程停止运行时，判断是否有dump文件产生；

第三判断子单元，用于当主进程在运行时，判断所述主进程信息中的参数是否在正常参数范围内；

更新子单元，用于当第二判断子单元判定有dump文件时，将离线原因更新为软件崩溃，当第二判断子单元判定没有dump文件时，将离线原因更新为其他原因关闭，当第三判断子单元判定所述主进程信息中的参数在正常参数范围内时，将离线原因更新为其他原因，以及，当第三判断子单元判定所述主进程信息中的参数不在正常参数范围内时，将离线原因更新为软件异常。

7.根据权利要求6所述的一种集群式安全管理***，其特征在于，所述客户端中还包括：

第一消息发送模块，用于当客户端***主动关机时，通过消息总线向管理平台发送第一消息，所述第一消息中包括：***关闭或重启；

第二消息发送模块，用于当客户端通过管理工具手动停止客户端主程序时，通过消息总线向管理平台发送第二消息，所述第二消息中包括：软件手动关闭。

Images