CN114338765B - 设备连接异常识别方法与系统、电子装置及存储介质 - Google Patents

Abstract

本发明涉及一种设备连接异常识别方法与系统、电子装置及存储介质。该方法包括：获取设备的运行日志；根据运行日志，确定离线恢复时长；将离线恢复时长与离线恢复阈值进行比较，确定设备的连接是否异常。本发明通过获取设备运行日志中的心跳事件上报时刻与离线原因事件上报时刻来计算设备离线恢复时长，利用设备离线恢复时长与离线恢复阈值之间的大小比较，确定该设备的连接是否异常。

Description

设备连接异常识别方法与系统、电子装置及存储介质

技术领域

本发明涉及物联网技术领域，更特别地，涉及一种设备连接异常识别方法与系统、电子装置及存储介质。

背景技术

随着物联网技术的快速发展，不同设备之间实现了高效的互连。通常，一个控制终端可以控制一个或多个设备，其中，各个设备之间可以相互通信，设备也可以主动离线(例如，用户主动切换或退出连接)或者由于其他原因(例如，网络不兼容或信号弱)而离线，即连接异常。这些连接异常可能会导致设备失去控制，从而影响用户使用。

为了识别连接异常，需要获取设备的离线恢复时长。现有技术中，一般采用设备上下线通知的日志埋点规则，其中，在设备真正离线三分钟内没有再上报任何数据时，平台会认为设备已离线，这显然无法获得准确的设备离线恢复时长，从而无法识别设备连接是否异常。

发明内容

针对现有技术中的问题，本发明提供一种设备连接异常识别方法与系统、电子装置及存储介质。

第一方面，本发明提供一种设备连接异常识别方法，所述设备连接异常识别方法包括：

获取设备的运行日志；

根据所述运行日志，确定离线恢复时长；

将所述离线恢复时长与离线恢复阈值进行比较，确定所述设备的连接是否异常。

进一步地，所述设备连接异常识别方法包括：

所述根据所述运行日志，确定离线恢复时长，包括：

基于所述运行日志中的离线原因事件的上报时刻，确定上线时刻；

基于所述运行日志中的心跳事件的上报时刻，确定离线时刻；

将所述设备的上线时刻与离线时刻之间的差确定为所述离线恢复时长。

进一步地，所述设备连接异常识别方法包括：

所述根据所述运行日志，确定离线恢复时长，包括：

基于所述运行日志中的离线原因事件的上报时刻，确定上线时刻；

基于所述运行日志中的上一次离线原因事件的上报时刻，确定离线时刻；

将所述设备的上线时刻与离线时刻之间的差确定为所述离线恢复时长。

进一步地，所述设备连接异常识别方法包括：

在所述运行日志中连续出现两次以上的离线原因事件的情况下，所述根据所述运行日志，确定离线恢复时长，包括：

基于所述运行日志中最后一次离线原因事件的上报时刻，确定上线时刻；

基于所述运行日志中第一次离线原因事件的上报时刻，确定离线时刻；

将所述设备的上线时刻与离线时刻之间的差确定为所述离线恢复时长。

进一步地，所述离线恢复阈值为基于所述设备的运行日志而获得的平均离线恢复时长，或者基于所述设备的同类型设备的运行日志而获得的平均离线恢复时长。

进一步地，所述设备连接异常识别方法包括：

所述将所述离线恢复时长与离线恢复阈值进行比较，确定所述设备的连接是否异常，包括：

当所述离线恢复时长大于所述离线恢复阈值时，确定所述设备连接异常。

进一步地，所述设备连接异常识别方法还包括：

获取所述设备连接异常对应的解决方案；

利用所述解决方案解决连接异常。

第二方面，本发明提供一种设备连接异常识别系统，包括：

设备运行日志获取单元，用于获取设备的运行日志；

离线恢复时长确定单元，用于根据所述运行日志，确定离线恢复时长；以及

设备连接异常确定单元，用于将所述离线恢复时长与离线恢复阈值进行比较，确定所述设备的连接是否异常。

第三方面，本发明提供一种电子装置，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面中任一项所述设备连接异常识别方法的步骤。

第四方面，本发明提供一种非暂态计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面中任一项所述设备连接异常识别方法的步骤。

本发明通过获取设备运行日志中的心跳事件上报时刻与离线原因事件上报时刻来计算设备离线恢复时长，利用设备离线恢复时长与离线恢复阈值之间的大小比较，确定该设备的连接是否异常。

附图说明

图1是根据本发明实施例的连接异常识别方法的流程图；

图2至图7是根据本发明实施例的确定上线时刻与离线时刻的示意图；

图8是根据本发明实施例的连接异常识别系统的结构示意图；以及

图9是根据本发明实施例的电子装置的结构示意图。

具体实施方式

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

本发明使用的各种术语或短语具有本领域普通技术人员公知的一般含义，即便如此，本发明仍然希望在此对这些术语或短语作更详尽的说明和解释。如果本文涉及的术语和短语有与公知含义不一致的，则以本发明所表述的含义为准；并且如果在本申请中没有定义，则其具有本领域普通技术人员通常理解的含义。

图1示出了根据本发明实施例的连接异常识别方法的流程图。参照图1，该方法包括以下步骤：

步骤101：获取设备的运行日志；

步骤103：根据运行日志，确定离线恢复时长；以及

步骤105：将离线恢复时长与离线恢复阈值进行比较，确定设备的连接是否异常。

根据本发明，设备可以为智能电视、智能冰箱、智能空调、智能洗衣机等，终端可以为移动终端、计算机、智能手机、智能手环等，这些设备与终端之间可以支持各种通信方式，例如蓝牙、WIFI、ZIGBEE等。

在步骤101中，可以获取设备运行的日志。日志可以包括心跳(Heartbeat)日志与离线原因(OfflineCause)日志。离线原因日志可以包括与离线原因事件(下文中也称为“第一事件”)相关的各个参数，例如，离线原因事件代码、时间等。心跳日志可以包括与心跳事件(下文中也称为“第二事件”)相关的各个参数，例如，连接方式、强度、时间等。

一般地，心跳事件可以是发送方按照一定规则(例如，周期性发送、空闲发送等)向接收方发送固定格式的消息，接受方收到消息后回复一个固定格式的消息，如果长时间(例如，心跳周期的3倍)没有收到，则认为当前连接失效，将其断开。换句话说，心跳消息是一种发送源发送到接收方的消息。这种消息可以让接收方确定发送源是否以及何时出现故障或终止。通常，心跳消息从发送源启动时开始发送，直到发送源关闭，期间发送源会不间断的发送周期性或重复消息。当接收方在某个消息接收周期内未收到消息，接收方可能会认为发送源已经关闭、出现故障、或者当前不可用。

在实施例中，当设备处于心跳状态(即，处于上线状态)时，可以按照预定时间间隔上报心跳事件，例如，时间间隔可以为1分钟、2分钟、30秒等。

可选地，可以根据需要对时间间隔进行调整。例如，在时间间隔为2分钟的情况下，设备每间隔2分钟上报一次心跳事件，当以最后一次上报心跳事件的时间作为离线时刻时，该离线时刻存在2分钟范围内的误差，这导致计算最后计算离线恢复时长时也会存在2分钟范围内的误差。

如果期望获得更加精确的离线恢复时长，则可以使用较低的时间间隔。例如，可以将间隔时间设置为30秒，设备每间隔30秒上报一次心跳事件，当以最后一次上报心跳事件的时间作为离线时刻时，该离线时刻仅存在30秒范围内的误差，这使得计算最后计算离线恢复时长时仅存在30秒范围内的误差。

在实施例中，在设备经历离线之后再一次上线的情况下，设备每当上线时，将立即上报设备上一次的离线原因事件。

基于步骤101的设备运行日志，在步骤103中，可以对设备的离线恢复时长进行计算。

在实施例中，在计算离线恢复时长时，可以基于设备运行日志，以预定时间作为一个周期来计算离线恢复时长，其中预定时间可以为12小时、24小时、48小时等(下文中，为了便于描述，将预定时间标记为“T”)。

可选地，在获得设备的运行日志之后，可以按照时间升序对日志中的离线原因事件进行排列，然后再针对每个离线原因事件计算离线恢复时长。

例如，在获得设备的运行日志之后，可以按照时间戳对日志进行升序排列，从而可以快速确定离线时刻与上线时刻。例如，根据设备的运行日志，存在以下几个升序的时间戳“06：36”(上报第一事件的时刻)、“08：40”(上报第一事件的时刻)、“11：44”(上报第二事件的时刻)、“16：12”(上报第一事件的时刻)等，则可以确认设备的第一事件与第二事件的先后顺序，从而确定离线时刻与上线时刻。

可选地，在包含多个设备的情况下，在按照时间升序对离线原因事件进行排列之前，按照各个设备的设备ID(设备唯一标识)对各自的日志进行分组，然后再针对各个设备计算离线恢复时长。

例如，在一种网络(例如，WIFI网络)环境下，当多个设备(例如，A、B、C、D、E)同时处于该网络环境下并运行一段时间产生一段时间的运行日志之后，为了分析各个设备的离线恢复时长，可以按照设备ID(A、B、C、D、E分别具有的设备唯一标识)对各自设备的日志进行分组，然后再针对各个设备计算离线恢复时长。

以下将描述根据离线原因事件上报时刻与心跳事件上报时刻来确定离线时刻与上线时刻从而确定离线恢复时长的过程。为了便于说明，将24小时的时间段作为一个周期(即，T＝24小时，从“0：00”至“24：00”)，将时间T内离线原因事件上报时刻标记为“O”，将时间T内小于“O”的最近一次离线原因事件上报时刻标记为“RO”，将时间T内小于“O”的最近一次心跳事件上报时刻标记为“RHO”。

在一种情况下，根据时间T内的运行日志，离线原因事件上报之前存在心跳事件上报，但是不存在离线原因事件上报。此时，确定离线时刻与上线时刻从而计算离线恢复时长的步骤包括：基于运行日志中的离线原因事件的上报时刻，确定上线时刻；基于运行日志中的心跳事件的上报时刻，确定离线时刻；将设备的上线时刻与离线时刻之间的差确定为离线恢复时长。以下图2示出了这种情况下确定上线时刻与离线时刻从而计算离线恢复时长的过程。

如图2所示，在时间T内，运行日志中的离线原因事件上报时刻为“O”，在“O”之前上报最近一次心跳事件的时刻为“RHO”，也就是说，在“0：00”至“RHO”期间设备一直处于在线状态，在“RHO”至“O”期间设备一直处于离线状态，此时可以将上线时刻确定为“O”，并将离线时刻确定为“RHO”。因此，可以将上线时刻与离线时刻之间的差确定为离线恢复时长(即，“O”-“RHO”)。

在另一种情况下，根据时间T内的运行日志，离线原因事件上报之前不存在心跳事件上报，但是存在离线原因事件上报。此时，确定离线恢复时长的步骤包括：基于运行日志中的离线原因事件的上报时刻，确定上线时刻；基于运行日志中的上一次离线原因事件的上报时刻，确定离线时刻；将设备的上线时刻与离线时刻之间的差确定为离线恢复时长。以下图3示出了这种情况下确定上线时刻与离线时刻从而计算离线恢复时长的过程。

如图3所示，在时间T内，运行日志中的离线原因事件上报时刻为“O”，在“O”之前不存在心跳事件上报，但是存在离线原因事件上报，该离线原因事件上报时刻为“RO”，也就是说，在“0：00”至“RO”期间设备一直处于离线状态，从“RO”开始设备上线，然而经历了短暂的上线之后又发生了离线直到“O”，由于上线时间很短，还来不及上报心跳事件(例如，上线时间小于上报心跳事件的时间间隔)，此时可以将上线时刻确定为“O”，并将离线时刻确定为“RO”。因此，可以将上线时刻与离线时刻之间的差确定为离线恢复时长(即，“O”-“RO”)。

图3示出了离线原因事件上报之前不存在心跳事件上报而是仅仅存在一个离线原因事件上报的情况，以下图4示出了离线原因事件上报之前不存在心跳事件上报而是存在两个以上离线原因事件上报的情况，即，运行日志中连续出现两次以上的离线原因事件。此时，确定离线时刻与上线时刻从而计算离线恢复时长的步骤包括：基于运行日志中最后一次离线原因事件的上报时刻，确定上线时刻；基于运行日志中第一次离线原因事件的上报时刻，确定离线时刻；将设备的上线时刻与离线时刻之间的差确定为离线恢复时长。

如图4所示，在时间T内，运行日志中的离线原因事件上报时刻为“O”，在“O”之前不存在心跳事件上报，而是存在两次离线原因事件上报，两次离线原因事件上报时刻分别标记为“ROx”与“ROy”，也就是说，在“0：00”至“ROx”期间设备一直处于离线状态，从“ROx”开始设备上线，然而经历了短暂的上线之后又发生了离线直到“ROy”，由于上线时间很短，还来不及上报心跳事件(例如，上线时间小于上报心跳事件的时间间隔)，接着从“ROy”开始设备又上线，然而经历了短暂的上线之后又发生了离线直到“O”，由于上线时间很短，还来不及上报心跳事件(例如，上线时间小于上报心跳事件的时间间隔)，此时可以将上线时刻确定为最后一次离线原因事件上报时刻(即，“O”)，并将离线时刻确定为第一次离线原因事件上报时刻(即，“ROx”)。因此，可以将上线时刻与离线时刻之间的差确定为离线恢复时长(即，“O”-“ROx”)。

由以上可知，在连续出现两次以上的离线原因事件上报的情况下，可以将最后一次离线原因事件上报时刻确定为上线时刻，并且可以将第一次离线原因事件上报时刻确定为离线时刻，从而计算离线恢复时长。也就是说，在连续出现两次以上的离线原因事件上报的情况下，可以将这几个离线原因事件进行合并。

除了以上图2至图4示出的各种情况，还存在以下情况：在时间T内，离线原因事件上报之前既不存在心跳事件上报，也不存在离线原因事件上报。以下图5示出了这种情况下确定上线时刻与离线时刻从而计算离线恢复时长的过程。

如图5所示，在时间T内，运行日志中的离线原因事件上报时刻为“O”，在“O”之前既不存在心跳事件上报，也不存在离线原因事件上报，也就是说，在“0：00”至“O”期间设备一直处于离线状态，此时可以将上线时刻确定为“O”，并将离线时刻确定为“0：00”。因此，可以将上线时刻与离线时刻之间的差确定为离线恢复时长(即，“O”-“0：00”)。

在实际的设备运行过程中，在时间T内，设备可能会出现多次上线和离线，也就是说，在时间T内，在离线原因事件上报之前会同时存在心跳事件上报与离线原因事件上报，以下图6与图7示出了这种情况下确定上线时刻与离线时刻从而计算离线恢复时长的过程。

如图6所示，在时间T内，运行日志中的离线原因事件上报时刻为“O”，在“O”之前既存在心跳事件上报，也存在离线原因事件上报，心跳事件上报时刻为“RHO”，前一次离线原因事件上报时刻为“RO”，也就是说，在“0：00”至“RO”期间设备一直处于离线状态，在“RO”至“RHO”期间设备一直处于在线状态，在“RHO”至“O”期间设备一直处于离线状态，此时可以将上线时刻确定为“O”，并将离线时刻确定为“RHO”。因此，可以将上线时刻与离线时刻之间的差确定为离线恢复时长(即，“O”-“RHO”)。

如图7所示，在时间T内，运行日志中的离线原因事件上报时刻为“O”，在“O”之前既存在心跳事件上报，也存在离线原因事件上报，心跳事件上报时刻为“RHO”，前一次离线原因事件上报时刻为“RO”，也就是说，在“0：00”至“RHO”期间设备一直处于在线状态，在“RHO”至“RO”期间设备一直处于离线状态，从“RO”开始设备上线，然而经历了短暂的上线之后又发生了离线直到“O”，由于上线时间很短，还来不及上报心跳事件(例如，上线时间小于上报心跳事件的时间间隔)，此时可以将上线时刻确定为“O”，并将离线时刻确定为“RO”。因此，可以将上线时刻与离线时刻之间的差确定为离线恢复时长(即，“O”-“RO”)。

由以上可知，在离线原因事件上报之前同时存在心跳事件上报与其它离线原因事件上报的情况下，可以将上线时刻确定为该离线原因事件上报时刻，并且可以将离线时刻确定为心跳事件上报时刻与其它离线原因事件上报时刻之中的、最靠近该离线原因事件上报时刻的时刻，从而计算离线恢复时长。

基于步骤103计算得到的离线恢复时长，在步骤105中，可以对设备的连接异常状态进行识别。

在实施例中，可以通过获得的离线恢复时长来识别用户的行为或者设备的使用规律。

例如，通过分析某种设备(例如，智能电视)在多个周期(例如，一个周期为24小时)的历史运行日志得到以下数据：离线恢复时长最长约为8小时，该离线恢复时长的时间段(离线时刻至上线时刻)主要集中在“0：00至8：00”，则可以认为该智能电视在“0：00至8：00”的时间段是没有连网使用的。

例如，通过分析某种设备(例如，智能电视)在多个周期(例如，一个周期为24小时)的历史运行日志得到以下数据：在“19：00至21：00”之间多次离线且每次离线的时间很短，并且该时间段的信号强度较弱，则可以认为该智能电视在“19：00至21：00”的时间段的信号较弱而导致经常离线。

由以上可知，通过计算设备的离线恢复时长，可以获得用户的使用习惯或设备的运行规律。

此外，可以通过获得的离线恢复时长来确定设备连接是否异常。例如，当通过计算获得的离线恢复时长为20分钟，而设置的离线恢复阈值为10分钟时，可以认为设备的连接存在异常；当通过计算获得的离线恢复时长为20分钟，而设置的离线恢复阈值为30分钟时，可以认为设备的连接不存在异常。

在实施例中，可以通过该设备的历史运行日志或与该设备经由相同连接方式(例如，WIFI、蓝牙等)的同类型(例如，产品型号)设备的历史运行日志来确定离线恢复阈值。

具体地，可以基于该设备的运行日志计算一定时间段内的历史离线恢复时长，并取各个历史离线恢复时长的平均值作为离线恢复阈值。类似地，可以基于各种同类型设备的历史运行日志来获得离线恢复阈值。

例如，可以选择设备多个周期(例如，100个周期，一个周期为24小时，时间从“0：00至24：00”)的历史运行日志，按照每个周期计算24小时的离线恢复时长得到总离线恢复时长。

例如，可以选择设备多个周期(例如，100个周期，一个周期为24小时，时间从“0：00至24：00”)，按照每个周期计算24小时中的某个时间段(例如，“19：00至21：00”)的离线恢复时长得到总离线恢复时长。

例如，可以选择设备多个周期(例如，100个周期，一个周期为24小时，时间从“0：00至24：00”)，按照每个周期针对预定离线原因(例如，IP不兼容、信号弱)计算24小时的离线恢复时长得到总离线恢复时长。

例如，可以选择设备多个周期(例如，100个周期，一个周期为24小时，时间从“0：00至24：00”，按照每个周期计算24小时中的某个时间段(例如，“19：00至21：00”)，针对预定离线原因(例如，IP不兼容、信号弱)的离线恢复时长得到总离线恢复时长。

此外，除了针对设备本身统计多个周期(例如，100个周期，一个周期为24小时，时间从“0：00至24：00”)内的历史运行日志，还可以针对同类型的设备统计运行日志，从而得到同类型设备的总离线恢复时长。

在获得总离线恢复时长之后，可以对多个周期的总离线恢复时长取平均值作为离线恢复阈值。

由以上可知，可以针对不同时间段、不同离线原因(也称为连接异常情况)获得不同的离线恢复阈值，例如，针对“19：00至21：00”的时间段网络不兼容的情况，可以设置第一离线恢复阈值；针对“19：00至21：00”的时间段信号弱的连接情况，可以设置第二离线恢复阈值。在这种情况下，如果在“19：00至21：00”期间因网络不兼容引起的离线恢复时长大于第一离线恢复阈值，则认为设备的连接存在异常；如果离线恢复时长小于第一离线恢复阈值，则认为设备的连接不存在异常。

可选地，离线恢复阈值不限于上述多个周期的总离线恢复时长的平均值，也可以是能够代表设备历史离线恢复时长水平的其他值，例如，多个周期的总离线恢复时长的中位数、众数等。

如上所述，可以通过判断离线恢复时长与离线恢复阈值之间的大小比较来确定设备的连接是否异常。

在实施例中，在确定设备连接异常的情况下，可以获取连接异常对应的解决方案，并利用该解决方案解决连接异常的问题。

在实施例中，不同连接异常对应的解决方案可以预先存储在设备中，并且也可以存储在服务器中。

当发生连接异常时，可以在设备中直接查找连接异常对应的解决方案；也可以由控制终端(例如，手机、平板、遥控器等)通过向服务器发送关于连接异常的请求来获得连接异常对应的解决方案。

例如，在因网络信号弱引起的离线恢复时长大于第一离线恢复阈值而认为设备连接存在异常的情况下，可以直接在设备中查找或者通过向服务器发送请求而获取网络信号弱对应的解决方案(例如，使用信号增强设备、利用“网桥”扩大网络信号等)，然后再利用这些解决方案解决连接异常。

例如，在因用户过多设备无法获取IP地址引起的离线恢复时长大于第一离线恢复阈值而认为设备连接存在异常的情况下，可以直接在设备中查找或者通过向服务器发送请求而获取网络信号弱对应的解决方案(例如，使用静态IP、重新设置登录密码等)，然后再利用这些解决方案解决连接异常。

在实施例中，可以存储历史运行日志中离线恢复时间较长或离线恢复时间所占比率较高的异常连接情况对应的解决方案。

例如，在一个周期(例如，24小时)内，经常发生网络信号弱而导致离线，这些离线恢复时长达到设定值(例如，2小时、3小时等)，此时可以将信号弱对应的解决方案存储到设备或服务器。

可选地，离线恢复时长可以基于一个周期内的某些时间段。例如，在一个周期(例如，24小时)内，在“9：00至10：00”、“13：00至14：00”、“19：00至21：00”期间，经常发生网络信号弱而导致离线，这些离线恢复时长达到设定值(例如，20分钟、30分钟等)，此时可以将信号弱对应的解决方案存储到设备或服务器。

例如，在一个周期(例如，24小时，由T表示)内，经常发生网络信号弱而导致离线，这些离线恢复时长与一个周期时间的比率达到设定比率(例如，1％、2％等)，此时可以将信号弱对应的解决方案存储到设备或服务器。

可选地，离线恢复时长所占的比率可以基于一个周期内的某些时间段。例如，在一个周期(例如，24小时)内，在“9：00至10：00”、“13：00至14：00”、“19：00至21：00”期间，经常发生网络信号弱而导致离线，这些离线恢复时长与这些时间段的比率达到设定比率(例如，1％、2％等)，此时可以将信号弱对应的解决方案存储到设备或服务器。

由以上可知，本发明实施例提供的方法通过获取设备运行日志中的心跳事件上报时刻与离线原因事件上报时刻来计算设备离线恢复时长，利用设备离线恢复时长与离线恢复阈值之间的大小比较，确定该设备的连接是否异常。

图8是根据本发明实施例的连接异常识别系统的结构示意图。参照图8，该系统800包括：

设备运行日志获取单元801，用于获取设备的运行日志；

离线恢复时长确定单元803，用于根据运行日志，确定离线恢复时长；以及

设备连接异常确定单元805，用于将离线恢复时长与离线恢复阈值进行比较，确定设备的连接是否异常。

由以上可知，本发明实施例提供的系统通过获取设备运行日志中的心跳事件上报时刻与离线原因事件上报时刻来计算设备离线恢复时长，利用设备离线恢复时长与离线恢复阈值之间的大小比较，确定该设备的连接是否异常。

另一方面，本发明提供了一种电子装置。如图9所示，电子装置900包括处理器901、存储器902、通信接口903和通信总线904。

其中，处理器901、存储器902、通信接口903通过通信总线904完成相互间的通信。

处理器901可以调用存储器902中的逻辑指令，处理器901执行逻辑指令时实现如上所述的本发明实施例所提供的设备连接异常识别方法，该方法包括：获取设备的运行日志；根据运行日志，确定离线恢复时长；以及将离线恢复时长与离线恢复阈值进行比较，确定设备的连接是否异常。

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

另一方面，本发明还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，计算机程序可存储在非暂态计算机可读存储介质上，所述计算机程序被处理器执行时，计算机能够执行如上所述的本发明实施例所提供的设备连接异常识别方法，该方法包括：获取设备的运行日志；根据运行日志，确定离线恢复时长；以及将离线恢复时长与离线恢复阈值进行比较，确定设备的连接是否异常。

另一方面，本发明还提供一种非暂态计算机可读存储介质，该非暂态计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时如上所述的本发明实施例所提供的设备连接异常识别方法，该方法包括：获取设备的运行日志；根据运行日志，确定离线恢复时长；以及将离线恢复时长与离线恢复阈值进行比较，确定设备的连接是否异常。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路、具有合适的组合逻辑门电路的专用集成电路、可编程门阵列(PGA)、现场可编程门阵列(FPGA)等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

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

Claims (7)

1.一种设备连接异常识别方法，其特征在于，包括：

获取设备的运行日志；

根据所述运行日志，确定离线恢复时长；

其中，所述根据所述运行日志，确定离线恢复时长的步骤具体包括：

基于所述运行日志，在当前离线原因事件上报之前存在心跳事件的上报，但不存在离线原因事件上报的情况下，基于所述运行日志中的当前离线原因事件的上报时刻，确定上线时刻，并基于所述运行日志中的心跳事件的上报时刻，确定离线时刻；将所述设备的上线时刻与离线时刻之间的差确定为所述离线恢复时长；

所述根据所述运行日志，确定离线恢复时长的步骤具体还包括：

基于所述运行日志，在当前离线原因事件上报之前不存在心跳事件的上报，但存在离线原因事件上报的情况下，基于所述运行日志中的离线原因事件的上报时刻，确定上线时刻，基于所述运行日志中的上一次离线原因事件的上报时刻，确定离线时刻；将所述设备的上线时刻与离线时刻之间的差确定为所述离线恢复时长；

所述根据所述运行日志，确定离线恢复时长的步骤具体还包括：

基于所述运行日志，在当前离线原因事件上报之前不存在心跳事件的上报，但存在至少2次以上离线原因事件上报的情况下，基于所述运行日志中最后一次离线原因事件的上报时刻，确定上线时刻，基于所述运行日志中第一次离线原因事件的上报时刻，确定离线时刻；将所述设备的上线时刻与离线时刻之间的差确定为所述离线恢复时长；

将所述离线恢复时长与离线恢复阈值进行比较，确定所述设备的连接是否异常，所述方法还包括：

按照各个所述设备的设备ID对各自的日志进行分组，再针对各个所述设备计算各自的离线恢复时长。

2.根据权利要求1所述的设备连接异常识别方法，其特征在于，所述离线恢复阈值为基于所述设备的运行日志而获得的平均离线恢复时长，或者基于所述设备的同类型设备的运行日志而获得的平均离线恢复时长。

3.根据权利要求1所述的设备连接异常识别方法，其特征在于，所述将所述离线恢复时长与离线恢复阈值进行比较，确定所述设备的连接是否异常，包括：

当所述离线恢复时长大于所述离线恢复阈值时，确定所述设备连接异常。

4.根据权利要求3所述的设备连接异常识别方法，其特征在于，所述方法还包括：

获取所述设备连接异常对应的解决方案；

利用所述解决方案解决连接异常。

5.一种设备连接异常识别系统，其特征在于，包括：

设备运行日志获取单元，用于获取设备的运行日志；

离线恢复时长确定单元，用于根据所述运行日志，确定离线恢复时长；其中，所述根据所述运行日志，确定离线恢复时长的步骤具体包括：基于所述运行日志，在当前离线原因事件上报之前存在心跳事件的上报，但不存在离线原因事件上报的情况下，基于所述运行日志中的当前离线原因事件的上报时刻，确定上线时刻，并基于所述运行日志中的心跳事件的上报时刻，确定离线时刻；将所述设备的上线时刻与离线时刻之间的差确定为所述离线恢复时长；所述根据所述运行日志，确定离线恢复时长的步骤具体还包括：基于所述运行日志，在当前离线原因事件上报之前不存在心跳事件的上报，但存在离线原因事件上报的情况下，基于所述运行日志中的离线原因事件的上报时刻，确定上线时刻，基于所述运行日志中的上一次离线原因事件的上报时刻，确定离线时刻；将所述设备的上线时刻与离线时刻之间的差确定为所述离线恢复时长；所述根据所述运行日志，确定离线恢复时长的步骤具体还包括：基于所述运行日志，在当前离线原因事件上报之前不存在心跳事件的上报，但存在至少2次以上离线原因事件上报的情况下，基于所述运行日志中最后一次离线原因事件的上报时刻，确定上线时刻，基于所述运行日志中第一次离线原因事件的上报时刻，确定离线时刻；将所述设备的上线时刻与离线时刻之间的差确定为所述离线恢复时长；

设备连接异常确定单元，用于将所述离线恢复时长与离线恢复阈值进行比较，确定所述设备的连接是否异常，所述系统还用于：

按照各个所述设备的设备ID对各自的日志进行分组，再针对各个所述设备计算各自的离线恢复时长。

6.一种电子装置，其特征在于，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1-4中任一项所述设备连接异常识别方法的步骤。

7.一种非暂态计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-4中任一项所述设备连接异常识别方法的步骤。