CN110888790A - 日志管理方法及装置、电子设备、存储介质 - Google Patents

Abstract

本申请提供一种日志管理方法及装置、电子设备、存储介质；该方法应用于服务端，所述服务端生成的日志被配置有相应的编号信息；所述方法可以包括：接收客户端发送的日志查询请求，所述日志查询请求中包含所述客户端从所述服务端获取到的日志的历史编号信息；将所述历史编号信息与本地生成的日志的编号信息进行比对，以判定出是否存在对应于所述客户端的未获取日志；当判定出存在对应于所述客户端的未获取日志时，向所述客户端返回判定结果。本申请通过将客户端保存的日志的编号信息与服务端生成的日志的编号信息进行比对的方式，判断并是否存在未获取日志，便于管理员及时获取尚未获取的日志，以根据日志信息对系统进行维护。

Description

日志管理方法及装置、电子设备、存储介质

技术领域

本申请涉及网络通信领域，特别涉及一种日志管理方法及装置、电子设备、存储介质。

背景技术

在系统运行的过程中，日志是一种非常关键的文件。日志不仅能够帮助系统的使用者充分了解系统运行的环境，还能在系统出现故障之后，让使用者了解故障前后发生的事件，以便使用者针对系统的状况做出相应的处理。除此之外，在系统遭受到攻击等紧急情况下，还会生成区别于其他日志的紧急日志，以告知使用者遭受攻击的消息以及遭受本次攻击后系统的具体状况。

发明内容

有鉴于此，本申请提供一种日志管理方法及装置、电子设备、存储介质，能够帮助管理员及时获知是否存在尚未获取的日志，以便管理员及时获取尚未获取的日志，并根据获取到的日志信息对系统进行维护。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种日志管理方法，应用于服务端，所述服务端生成的日志被配置有相应的编号信息；所述方法包括：

接收客户端发送的日志查询请求，所述日志查询请求中包含所述客户端从所述服务端获取到的日志的历史编号信息；

将所述历史编号信息与本地生成的日志的编号信息进行比对，以判定出是否存在对应于所述客户端的未获取日志；

当判定出存在所述未获取日志时，向所述客户端返回判定结果。

根据本申请的第二方面，提出了一种日志管理方法，应用于客户端；所述日志由服务端生成，所述服务端生成的日志被配置有相应的编号信息；所述方法包括：

创建日志查询请求，所述日志查询请求中包含所述客户端从所述服务端获取到的日志的历史编号信息；

向所述服务端发送日志查询请求，以使得所述服务端将所述历史编号信息和所述服务端本地生成的日志的编号信息进行比对，以判定出是否存在对应于所述客户端的未获取日志；

接收所述服务端返回的判定结果，所述判定结果由所述服务端在判定出存在所述未获取日志时生成。

根据本申请的第三方面，提出了一种日志管理装置，应用于服务端，所述服务端生成的日志被配置有相应的编号信息；所述装置包括：

接收单元，接收客户端发送的日志查询请求，所述日志查询请求中包含所述客户端从所述服务端获取到的日志的历史编号信息；

比对单元，将所述历史编号信息与本地生成的日志的编号信息进行比对，以判定出是否存在对应于所述客户端的未获取日志；

返回单元，当判定出存在所述未获取日志时，向所述客户端返回判定结果。

根据本申请的第四方面，提出了一种日志管理装置，应用于客户端；所述日志由服务端生成，所述服务端生成的日志被配置有相应的编号信息；所述方法包括：

创建单元，创建日志查询请求，所述日志查询请求中包含所述客户端从所述服务端获取到的日志的历史编号信息；

发送单元，向所述服务端发送日志查询请求，以使得所述服务端将所述历史编号信息和所述服务端本地生成的日志的编号信息进行比对，以判定出是否存在对应于所述客户端的未获取日志；

接收单元，接收所述服务端返回的判定结果，所述判定结果由所述服务端在判定出存在所述未获取日志时生成。

根据本申请的第五方面，提供一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令以实现如上述实施例中任一所述的方法。

根据本申请的第六方面，提供一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如上述实施例中任一所述方法的步骤。

在本申请的技术方案中，服务端针对生成的日志配置编号信息，而客户端在从服务端获取到日志后，记录获取到的日志的编号信息。基于上述针对日志进行编号的机制，当存在获取服务端新生成日志的需求时，可通过客户端向服务端发送包含客户端保存的日志的编号信息的请求，使得服务端通过将客户端保存的日志的编号信息与服务端生成的日志的编号信息进行比对的方式，能够判断是否存在对应于客户端的未获取日志，并将判断的结果返回给客户端，以及时通知管理员存在未获取日志。

进一步的，当存在对应于客户端的未获取日志时，通过比较编号的方式确定未获取日志，以实现已获取日志和未获取日志的区分，便于管理员对两者进行分别管理，避免因无法区分已获取日志和未获取日志造成的工作效率低下，以及错过读取日志等情况。

附图说明

图1是本申请一示例性实施例示出的一种基于服务端的日志管理方法的流程图。

图2是本申请一示例性实施例示出的一种基于客户端的日志管理方法的流程图。

图3是本申请一示例性实施例示出的一种日志管理方法的交互图。

图4是本申请一示例性实施例示出的另一种日志管理方法的交互图。

图5是本申请一示例性实施例示出的一种基于服务端的电子设备的结构示意图。

图6是本申请一示例性实施例示出的一种基于服务端的日志管理装置的框图。

图7是本申请一示例性实施例示出的一种基于客户端的电子设备的结构示意图。

图8是本申请一示例性实施例示出的一种基于客户端的日志管理装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

日志在系统运行过程中扮演着极为重要的角色，它能够帮助管理员了解系统运行的状况，以便实时根据日志反应的信息对系统进行维护。除此之外，在系统遭受外界攻击的情况下，日志系统还能即时生成紧急日志以告知管理员系统遭受攻击的消息，以便管理员尽快对系统遭受攻击的状况进行处理。

为了方便管理员及时审阅日志，相关技术通过将日志消息置于WEB页面置顶的功能栏中，以便管理员能够在想要审阅日志时，只需点击该日志消息即可打开日志显示页面进行审阅。

但是，在相关技术中，客户端无法及时获知服务端是否存在尚未获取的新日志，且在获取新的日志后无法区分获取的日志中的历史未获取日志和历史已获取日志。

为解决上述技术问题，本申请提出了一种日志管理方法。参考图1，图1是本申请一示例性实施例示出的一种基于服务端的日志管理方法的流程图。如图1所示，该方法应用于服务端，所述服务端生成的日志被配置有相应的编号信息；该方法可以包括以下步骤：

步骤S102，接收客户端发送的日志查询请求，所述日志查询请求中包含所述客户端从所述服务端获取到的日志的历史编号信息。

在本实施例中，大多数情况下，一个用于日志管理的服务器可以对应于多个客户端。因此，为了区分多个客户端，给每个客户端配置有相应的管理员标识。在这种情况下，服务端可以给每个客户端分别配置一块存储空间以存储与各个客户端对应的日志。

在这种日志管理系统中，客户端发送的日志查询请求中包含有与客户端对应的管理员标识。当服务器接收到日志查询请求时，会首先读取接收到的日志查询请求中的管理员标识以确定发送日志查询请求的客户端；并从服务器中配置给该客户端的存储空间中获取本地生成的日志的编号信息，用于与从日志查询请求中获取的对应于该管理员标识的历史编号信息进行比较，以确定服务器中是否存在对应于该客户端的未获取日志。

在本步骤中，日志查询请求中包含的历史编号信息可以由客户端检测本地已经从服务端获取过的日志的编号，并在创建日志查询请求时，将检测到的编号写入该日志查询请求的某一字段中，以便服务端在接收到该日志查询请求时读取该字段以获得该历史编号信息。当然，对于客户端如何将历史编号信息写入日志查询请求可由本领域技术人员根据实际情况采用不同的方式，在此不作具体限定。

除此之外，为了能够及时获得是否存在未获取日志的消息，客户端可以定时向服务端发送日志查询请求。当然，定时的操作方式可以由本领域技术人员根据实际情况确定，在此不作限定。其中，定时的时间可以由管理员根据实际需求以及系统所处状况进行设定。

步骤S104，将所述历史编号信息与本地生成的日志的编号信息进行比对，以判定出是否存在对应于所述客户端的未获取日志。

在本申请的实施例中，给服务器生成的日志配置编号信息可以有多种配置方法，针对不同的配置方法，日志查询请求中包含的从服务端获取到的日志的历史编号信息也可以有多种情况。

在一实施例中，服务器将生成的日志按照生成的时间顺序进行排序进而得到各日志的编号。在这种情况下，日志查询请求中包含的历史编号信息可以为客户端从服务端获取到的日志的最大编号。此时，可以通过比较该最大编号与服务端生成的日志的最大编号判断是否存在客户端尚未获取的日志。其中，当判断出该最大编号小于服务端生成的日志的最大编号，则确定存在对应于客户端的未获取日志；否则，确定不存在对应于客户端的未获取日志。

通过生成的时间顺序对日志进行编号的好处在于，客户端在生成日志查询请求时只需写入一个日志编号。其次，在服务端将历史编号信息与本地日志的编号信息进行比较时，只需读取本地的一个编号信息用于与历史编号信息进行比较，而无需获取所有日志的编号信息，减少了对服务端处理资源的占用。

在另一实施例中，日志查询请求中包含的历史编号信息可以为客户端从服务端获取到的日志的所有编号。此时，可以将服务端本地生成的日志的编号与客户端日志的所有编号进行比较，通过判断服务端本地生成的日志的编号中是否有区别于客户端中所有日志编号的编号；若有，则确定存在对应于客户端的未获取日志；否则，确定不存在对应于所述客户端的未获取日志。

将客户端从服务端获取到的日志的所有编号写入日志查询请求的好处在于，对服务端给生成的日志进行编号的方式没有严格的要求，只需日志之间编号不重复即可，使得判断是否存在未获取日志的方式能够适用于更多的场景。

步骤S106，当判定出存在对应于所述客户端的未获取日志时，向所述客户端返回判定结果。

在本实施例中，当通过执行步骤S102和步骤S104得出判定结果时，可以只在判定结果为存在对应于客户端的未获取日志时，才返回判定的结果；也可以只要得出判定结果(无论判定结果为存在未获取日志或不存在未获取日志)，就返回判定结果。

当确定存在对应于客户端的未获取日志时，服务端返回的结果可以只是存在未获取日志的结果；也可以由服务端基于该结果先对服务端内生成的对应于客户端的日志进一步进行区分，以将确定的未获取日志一并返回给客户端。若服务端采用只返回存在未获取日志的结果时，可以在接收到用户发送的未获取请求时，再对服务端内生成的对应于客户端的日志作区分，以确定未获取日志，并返回给客户端。其中，将确定的未获取日志返回给客户端时，可以只返回未获取日志，也可以将确定的未获取日志和其他对应于客户端的日志一并返回。

在本步骤中，当确定存在对应于客户端的未获取日志时，可以进一步确定服务器中对应于所述客户端的未获取日志。

在一实施例中，服务端采用步骤S104中通过生成的时间顺序对日志进行编号的方式，那么，日志查询请求中包含的历史编号信息为客户端从服务端获取到的日志的最大编号。此时，若采用“确定存在未获取日志时，只返回存在未获取日志的结果”的方式，那么当收到客户端发送的针对未获取日志的日志获取请求时，服务端将历史编号信息和本地日志的最大编号进行比较，将编号大于历史编号信息的本地日志确定为未获取日志，并返回给客户端。

同理，若采用将存在未获取日志的结果和未获取日志一并返回的方式时，无需等待客户端发送日志获取请求，直接根据上述方法确定未获取日志，并将未获取日志和判定结果一并返回。当然，由于返回未获取日志已经意味着存在未获取日志，也可以只返回未获取日志。针对返回的内容可由本领域技术人员根据实际情况确定，在此不作具体限定。

在另一实施例中，不对服务端对日志进行编号的方式进行限定，即步骤S104中日志查询请求中包含的历史编号信息为客户端从服务端获取到的日志的所有编号。此时，若采用“确定存在未获取日志时，只返回存在未获取日志的结果”的方式，那么当收到客户端发送的针对未获取日志的日志获取请求时，服务端将历史编号信息和本地生成的所有日志的编号进行比较，将编号区别于历史编号信息的本地日志作为未获取日志，并返回给客户端。

同理，若采用将存在未获取日志的结果和未获取日志一并返回的方式时，除确定未获取日志的方式以外，操作方式同上一实施例，在此不作赘述。

由上述技术方案可知，在本申请的技术方案中，服务端针对生成的日志配置编号信息，而客户端在从服务端获取到日志后，记录获取到的日志的编号信息。基于上述针对日志进行编号的机制，当存在获取服务端新生成日志的需求时，可通过客户端向服务端发送包含客户端保存的日志的编号信息的请求，使得服务端通过将客户端保存的日志的编号信息与服务端生成的日志的编号信息进行比对的方式，能够判断是否存在对应于客户端的未获取日志，并将判断的结果返回给客户端，以及时通知管理员存在未获取日志。

进一步的，当确定服务端存在对应于客户端的未获取日志时，通过比较服务端和客户端各自保存的日志的编号以确定对应于客户端的未获取日志并返回给客户端，以由管理员查看该未获取日志，并根据该未获取日志中的信息对系统进行维护。通过这样的方式，管理者能够区分历史未获取日志和历史已获取日志，进而避免漏看日志，重复看同一日志等问题。

参考图2，图2是本申请一示例性实施例示出的一种基于客户端的日志管理方法的流程图。如图2所示，该方法应用于客户端；在该方法中，日志由服务端生成，所述服务端生成的日志被配置有相应的编号信息；所述方法包括：

步骤S202，创建日志查询请求，所述日志查询请求中包含所述客户端从所述服务端获取到的日志的历史编号信息。

在本实施例中，日志查询请求中包含的内容可参考步骤S102中的介绍，在此不作赘述。

步骤S204，向所述服务端发送日志查询请求，以使得所述服务端将所述历史编号信息和所述服务端本地生成的日志的编号信息进行比对，以判定出是否存在对应于所述客户端的未获取日志。

在本实施例中，历史编号信息的具体内容以及用于比对的本地生成的日志的编号信息的具体内容均可参考步骤S104中的介绍，在此不作赘述。

值得注意的是，发送日志查询请求的动作可由管理员通过客户端主动发送，也可以给客户端设定一定的发送周期，周期性向服务端发送日志查询请求，以及时获取服务端新生成的日志。

步骤S206，接收所述服务端返回的判定结果，所述判定结果由所述服务端在判定出存在所述未获取日志时生成。

在本实施例中，当服务端判定出不存在未获取日志时，也可以返回判定结果，此时客户端接收服务端返回的不存在未获取日志的判定结果。当然服务端返回的具体内容可参考步骤S106中的介绍，在此不作赘述。

值得注意的是，在接收到返回结果后，客户端可以根据返回的结果显示不同的警告信息。例如，点亮对应的警告标识，或者发出提示音以提示管理员存在未获取日志。当返回的结果包括确定的未获取日志时，也可以直接弹出未获取日志。具体的操作方式可以由本领域技术人员根据实际情况设定，在此不作限定。

由上述技术方案可知，客户端可以通过定时发送请求的方式实时获取服务端新生成的日志。进一步的，在接收到返回的结果或者未获取日志时，在客户端发出相应的提示信息，以便管理员及时审阅日志，更好地对系统进行维护。

为了便于理解，下面结合应用场景和举例对本申请提出的日志管理方法进行详细说明。

参考图3，图3为本申请一示例性实施例示出的一种日志管理方法的交互图，在该方法中，服务端按照日志生成的时间顺序对日志进行排序得到编号，该方法可以包括：

步骤S301，创建日志查询请求。

在本实施例中，客户端在创建日志查询请求的过程中，包括检测本地日志并获取本地最大日志编号的步骤。在检测到该最大编号后，将其写入日志查询请求以作为客户端最大日志编号。

步骤S302，客户端向服务端发送日志查询请求。

在本实施例中，客户端可以为管理员终端，日志查询请求由管理员终端发送给服务端，以由服务端查询本地日志，并确定是否存在未获取日志。其中，管理员可以根据自身需求以及系统所处环境给发送日志查询请求的过程设定发送周期。举例而言，若管理员想要及时获得是否存在未获取日志的消息，或者系统当前所处环境不稳定(即需要时刻监控系统状况)，则可以将该发送周期设定地较短，例如，2秒、5秒等；若管理员不着急获得是否存在未获取日志地消息，或者系统当前所处环境较为稳定，则可以将该发送周期设定地较长，例如，10秒、15秒等。

步骤S303，服务端读取日志查询请求中包含的客户端最大编号。

在本步骤中，由于服务端通常对应于多个客户端，该步骤还可以包括读取管理员终端标识的过程。当然，相应的在步骤S301创建日志查询请求的过程中需要将管理员标识写入日志查询请求。在包含多个客户端的日志管理系统中，后续步骤都针对管理员标识对应的客户端或者管理员标识对应的日志执行。

步骤S304，服务端读取本地日志的最大编号。

若该步骤在包含多个客户端的日志管理系统中执行，服务端读取的为本地保存的与管理员标识对应的日志的最大编号。

步骤S305，服务端将客户端最大编号和本地日志的最大编号进行比较，以得出是否存在未获取日志的结果。

在本实施例中，当确定客户端日志的最大编号小于服务端本地日志的最大编号时，则证明服务端本地生成的日志中存在编号大于客户端保存的日志的最大编号的日志，此时，确定存在未获取日志；反之，则确定不存在未获取日志。在本实施例中，无论是否存在未获取日志均将结果返回给客户端。

举例而言，假设客户端从服务端获取的所有日志的编号有1、2、3、4，服务端生成的所有日志的编号为1、2、3、4、5、6。那么，服务端从日志查询请求中读取的最大日志编号为4，读取的本地日志的最大编号为6。此时，将两者比较后发现客户端中保存的日志的最大编号小于本地日志的最大编号(4小于6)，则确定存在未获取日志。若在该举例中，本地日志的最大编号也为4，则确定不存在未获取日志。

步骤S306，服务端向客户端返回判定的结果。

若该步骤在包含多个客户端的日志管理系统中执行，则服务端向管理员标识对应的客户端返回判定结果。

步骤S307，客户端接收返回的判定结果。

在本实施例中，可以设置自动获取开关。自动获取开关的作用在于，当管理员想在存在未获取日志的情况下立刻获取尚未获取的日志时，只要打开该自动获取开关，客户端就会在接收到存在未获取日志的返回结果时，主动向服务端发起日志获取请求，而不需要管理员手动发起请求。反之，当自动获取开关关闭时，即使客户端接收到存在未获取日志的返回结果，也不会主动发起日志获取请求，需要管理员手动发起日志获取请求。

步骤S308，客户端判断返回的判定结果是否为存在未获取日志。

在本实施例中，当确定返回的结果为存在未获取日志时，进一步创建日志获取请求以获取服务端存在的未获取日志(即执行步骤S309)；当确定返回的结果为不存在未获取日志时，结束本次交互。

除此之外，当确定返回的结果为存在未获取日志时，可在客户端的特定界面(如WEB界面)点亮相应的警告标识，以告知管理员存在未获取日志；当然，在确定不存在未获取日志时，可以点亮另一警告标识以告知管理员不存在未获取日志。

在本实施例中，在确定接收到的判定结果为存在未获取日志的情况下，客户端会主动向服务端发送日志获取请求以获取尚未获取日志。之所以需要由客户端主动发起获取请求，而不是在第一次交互中由服务端主动确定未获取日志，并将未获取日志和判定结果一并返回，是由于在实际操作中，当客户端接收到存在未获取日志的消息时，管理员并不一定想立刻查看未获取日志(比如，当前较忙，没有时间看新日志)。此时，由服务器主动确定未获取日志并将确定的未获取日志返回给客户端容易造成服务端负担过大。换言之，当管理员得知存在未获取日志的消息但不想立刻查看未获取日志时，一并返回的做法很可能给服务端造成没必要的负担。

步骤S309，创建日志获取请求。

步骤S310，客户端向服务端发送日志获取请求。

步骤S311，服务端读取本地保存的所有日志的编号。

若该步骤在包含多个客户端的日志管理系统中执行，需要读取存储在服务端中与管理员标识对应的所有日志的编号，以用于判断这些编号对应的日志是否为未获取日志。

步骤S312，服务端将客户端日志的最大编号与本地所有日志的编号比较，以确定未获取日志。

在本实施例中，用于比较的客户端日志的最大编号可以为第一次交互中从日志查询请求中读取到的编号；若第一次交互中读取的最大编号已被删除，也可以从日志获取请求中读取，当然，相应的需要在创建日志获取请求时将该最大编号写入该日志获取请求中。具体的，可由本领域技术人员根据实际情况采用不同的操作方式，在此不作具体限定。

在本步骤中，将编号大于客户端日志最大编号的日志确定为未获取日志的同时，也可以将编号不大于客户端日志最大编号的日志确定为已获取日志。其中，确定未获取日志的方式可以为给确定的日志作上未获取的标记；将其余日志作上已获取的标记。当然，为了便于管理员理解标记的意思，也可以给将未获取日志标记为未读日志，将其余日志标记为已读日志。

承接步骤S305中的举例，当服务端生成的所有日志的编号为1、2、3、4、5、6时，编号5和6对应的日志为编号大于客户端日志最大编号的日志，此时将编号5和6对应的日志确定为未获取日志，将编号为1、2、3、4的日志确定为未获取日志以外的其他日志。

步骤S313，服务端向客户端返回确定的未获取日志。

若该步骤在包含多个客户端的日志管理系统中执行，则向管理员标识对应的客户端返回未获取日志。

在本实施例中，服务端可以只向客户端返回未获取日志，也可以将未获取日志和其他日志一并返回。但是，在实际应用中，为了避免客户端在接收到未获取日志时，再将接收到的新日志与已经获取过的日志作区分，服务端通常会将确定的日志(即已获取日志和未获取日志，或已读日志和未读日志)全部返回给客户端。在客户端接收到服务端返回的所有日志时，会清空原先保存的所有日志，并将接收到的全部日志存储进存储空间。这样便可避免客户端再对新获取日志和历史获取日志做区分。除此之外，将大多数步骤集中到服务端，便于对该方法的执行步骤进行管理。

步骤S314，客户端接收确定的未获取日志。

在本实施例中，客户端在接收到未获取日志时，可以直接弹出获取的未获取日志；也可以将该未获取日志以新日志消息的形式显示在显示页面置顶的功能栏(如WEB页面的功能栏)中，只有当管理员点击该新日志消息时，才弹出对应的未获取日志以供管理员审阅。

具体的，可以在客户端上设置特定的自动弹出开关。当打开该开关时，只要接收到服务端返回的未获取日志，立刻弹出获取到的日志；当开关关闭时，则只有当管理员主动点击新日志消息时才弹出相应的日志信息。

由上述技术方案可知，本申请的技术方案通过将客户端保存的日志的最大编号与服务端生成的日志的最大编号进行比较，以确定是否存在对应于客户端的未获取日志。当存在未获取日志时，客户端进一步向服务端获取确定的未获取日志，使得管理员能够及时获取服务端新生成的日志，并根据获取的日志进行相应的维护工作。

这种方式的好处在于，在确定是否存在未获取日志的阶段，无需获取所有日志的编号信息，仅需获取客户端和服务端各一个最大编号，即可确定是否存在对应于客户端的未获取日志；即使在确定未获取日志阶段，也无需获取客户端所有日志的编号，即可确定出未获取日志，减少了对服务端处理资源的占用，进而提高了服务端的性能。

参考图4，图4为本申请一示例性实施例示出的另一种日志管理方法的交互图，在该方法中，服务端生成的日志被配置有相应的编号信息，该方法可以包括：

步骤S401，创建日志查询请求。

在本实施例中，客户端创建日志查询请求的过程中，包括检测本地日志并获取本地所有日志编号的步骤。在检测到所有日志的编号后，将其写入日志查询请求以作为客户端的日志编号信息。

步骤S402，客户端向服务端发送日志查询请求。

在本实施例中，与步骤S302类似，客户端可以为管理员终端，也可以给发送日志查询请求的过程设定发送周期，具体的可以参考步骤S302，在此不作赘述。

步骤S403，服务端读取日志查询请求中包含的客户端所有日志的编号。

在本实施例中，对于服务端通常对应多个客户端的情况，可参考上一实施例的内容，在本实施例中不作赘述。

步骤S404，服务端读取本地所有日志的编号。

步骤S405，服务端判断本地是否存在编号区别于客户端所有日志编号的日志，以得出是否存在未获取日志的结果。

在本实施例中，当服务端确定本地存在编号区别于客户端所有日志编号的日志时，确定存在未获取日志；反之，确定不存在未获取日志。在本实施例中，无论确定是否存在未获取日志均将结果返回给客户端。

沿用上一实施例中的例子，即假设客户端从服务端获取的所有日志的编号有1、2、3、4，服务端生成的所有日志的编号为1、2、3、4、5、6。那么，服务端从日志查询请求中读取的所有日志的编号为1、2、3、4，读取的本地日志的所有编号为1、2、3、4、5、6。不难看出，服务端中存在编号5和6区别于客户端所有日志的编号，确定存在对应于客户端的未获取日志。当然，若服务端保存的日志的编号为1、2、3、4，则服务端中不存在区别于客户端所有日志的编号，即确定不存在对应于客户端的未获取日志。

步骤S406，服务端向客户端返回判定的结果。

步骤S407，客户端接收返回的判定结果。

步骤S408，客户端判断返回的判定结果是否为存在未获取日志。

在本实施例中，当确定返回的结果为存在未获取日志时，进一步创建日志获取请求以获取服务端存在的未获取日志(即执行步骤S409)；当确定返回的结果为不存在未获取日志时，结束本次交互。

除此之外，当确定返回的结果为存在未获取日志时，可在客户端的特定界面(如WEB界面)点亮相应的警告标识，以告知管理员存在未获取日志；当然，在确定不存在未获取日志时，也可以点亮另一警告标识以告知管理员不存在未获取日志。

步骤S409，创建日志获取请求。

在本实施例中，客户端创建日志获取请求以主动向服务端请求获取未获取日志的过程可参考步骤S309，在此不作赘述。

步骤S410，客户端向服务端发送日志获取请求。

步骤S411，服务端将客户端所有日志的编号与本地所有日志的编号进行比较，以确定未获取日志。

在本实施例中，由于在第一次交互中(即判断是否存在未获取日志的过程中)已经读取过客户端所有日志的编号以及服务端本地所有日志的编号，所以无需再读取一次。直接将第一次交互中读取的本地所有日志的编号与客户端所有日志的编号进行比较即可。其中，将服务端中编号区别于客户端所有日志的编号的日志确定为未获取日志。

承接步骤S405中的例子，当服务端生成的所有日志的编号为1、2、3、4、5、6时，编号5和6对应的日志为服务端中编号区别于客户端所有日志编号的日志，则将编号5和6对应的日志确定为未获取日志。

当然，在第一次交互中读取的客户端所有日志编号已被删除的情况下，可参考步骤S312中最大编号被删除的情况下的操作方式，在此不作赘述。可以理解的是，在第一次读取的本地所有日志的编号被删除的情况下，只需在执行比对的步骤之间，先读取一次即可。具体的，是否在第一次交互结束后删除读取的数据可由本领域技术人员根据实际情况决定，在此不作限定。

相应的如何区分未获取日志和其他日志，也可参考步骤S312中的执行方式，在此不作赘述。

步骤S412，服务端向客户端返回确定的未获取日志。

在本步骤中，关于返回的具体内容可参考步骤S313的内容，在此不作赘述。

步骤S413，客户端接收确定的未获取日志。

由上述技术方案可知，本申请的技术方案通过将客户端保存的所有日志的编号与服务端生成的所有日志的编号进行比较，以确定是否存在对应于客户端的未获取日志。当存在未获取日志时，客户端进一步向服务端获取确定的未获取日志，使得管理员能够及时获取服务端新生成的日志，并根据获取的日志进行相应的维护工作。

这种方式的好处在于，对服务器给生成的日志配置编号的方式没有严格的要求，只需日志之间的编号不重复即可，使得该日志管理方法能够适用于更多的场景。

图5为本申请的一示例性实施例示出一种基于服务端的电子设备的示意结构图。请参考图5，在硬件层面，该电子设备包括处理器502、内部总线504、网络接口506、内存508以及非易失性存储器510，当然还可能包括其他业务所需要的硬件。处理器502从非易失性存储器510中读取对应的计算机程序到内存508中然后运行，在逻辑层面上形成日志管理装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图6，在软件实施方式中，该日志管理装置可以包括：

接收单元601，接收客户端发送的日志查询请求，所述日志查询请求中包含所述客户端从所述服务端获取到的日志的历史编号信息；

比对单元602，将所述历史编号信息与本地生成的日志的编号信息进行比对，以判定出是否存在对应于所述客户端的未获取日志；

返回单元603，当判定出存在所述未获取日志时，向所述客户端返回判定结果。

可选的，所述日志查询请求中还包含与所述客户端对应的管理员标识；

所述比对单元602，进一步用于获取对应于所述管理员标识的历史编号信息，将获取到的历史编号信息与本地生成的日志的编号信息进行比对。

可选的，所述编号信息包括按照日志生成的时间顺序进行排序得到的编号；所述历史编号信息为所述客户端从所述服务端获取到的日志的最大编号；

所述比对单元602，进一步用于判断所述历史编号信息是否小于本地生成的日志的最大编号；若是，则确定存在对应于所述客户端的未获取日志；否则，确定不存在对应于所述客户端的未获取日志。

可选的，还包括：

确定单元604，当接收到所述客户端发送的针对所述未获取日志的日志获取请求时，将编号大于所述历史编号信息的本地日志作为未获取日志；

所述返回单元603，进一步用于向所述客户端返回所述未获取日志和/或本地日志中区别于所述未获取日志的其他日志。

可选的，所述历史编号信息为所述客户端从所述服务端获取到的所有日志的编号；

所述比对单元602，进一步用于判断本地生成的日志的编号中是否有区别于所述历史编号信息的编号；若是，则确定存在对应于所述客户端的未获取日志；否则，确定不存在对应于所述客户端的未获取日志。

可选的，还包括：

所述确定单元604，进一步用于当接收到所述客户端发送的针对所述未获取日志的日志获取请求时，将编号区别于所述历史编号信息的本地日志作为未获取日志；

所述返回单元603，进一步用于向所述客户端返回所述未获取日志和/或本地日志中区别于所述未获取日志的其他日志。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

图7为本申请的一示例性实施例示出一种基于客户端的电子设备的示意结构图。请参考图7，在硬件层面，该电子设备包括处理器702、内部总线704、网络接口706、内存708以及非易失性存储器710，当然还可能包括其他业务所需要的硬件。处理器702从非易失性存储器710中读取对应的计算机程序到内存708中然后运行，在逻辑层面上形成日志管理装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图8，在软件实施方式中，该日志管理装置可以包括：

创建单元801，创建日志查询请求，所述日志查询请求中包含所述客户端从所述服务端获取到的日志的历史编号信息；

发送单元802，向所述服务端发送日志查询请求，以使得所述服务端将所述历史编号信息和所述服务端本地生成的日志的编号信息进行比对，以判定出是否存在对应于所述客户端的未获取日志；

接收单元803，接收所述服务端返回的判定结果，所述判定结果由所述服务端在判定出存在所述未获取日志时生成。

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

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器，上述指令可由日志管理装置的处理器执行以实现如上述实施例中任一所述的方法，比如该方法可以包括：接收客户端发送的日志查询请求，所述日志查询请求中包含所述客户端从所述服务端获取到的日志的历史编号信息；将所述历史编号信息与本地生成的日志的编号信息进行比对，以判定出是否存在对应于所述客户端的未获取日志；当判定出存在所述未获取日志时，向所述客户端返回判定结果。

其中，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等，本申请并不对此进行限制。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种日志管理方法，其特征在于，应用于服务端，所述服务端生成的日志被配置有相应的编号信息；所述方法包括：

接收客户端发送的日志查询请求，所述日志查询请求中包含所述客户端从所述服务端获取到的日志的历史编号信息；

将所述历史编号信息与本地生成的日志的编号信息进行比对，以判定出是否存在对应于所述客户端的未获取日志；

当判定出存在对应于所述客户端的未获取日志时，向所述客户端返回判定结果。

2.根据权利要求1所述的方法，其特征在于，所述日志查询请求中还包含与所述客户端对应的管理员标识；

所述将所述历史编号信息与本地生成的日志的编号信息进行比对，包括：获取对应于所述管理员标识的历史编号信息，将获取到的历史编号信息与本地生成的日志的编号信息进行比对。

3.根据权利要求1所述的方法，其特征在于，所述编号信息包括按照日志生成的时间顺序进行排序得到的编号；所述历史编号信息为所述客户端从所述服务端获取到的日志的最大编号；所述将所述历史编号信息与本地生成的日志的编号信息进行比对，包括：

判断所述历史编号信息是否小于本地生成的日志的最大编号；

若是，则确定存在对应于所述客户端的未获取日志；否则，确定不存在对应于所述客户端的未获取日志。

4.根据权利要求3所述的方法，其特征在于，还包括：

当接收到所述客户端发送的针对所述未获取日志的日志获取请求时，将编号大于所述历史编号信息的本地日志作为未获取日志；

向所述客户端端返回所述未获取日志和/或本地日志中区别于所述未获取日志的其他日志。

5.根据权利要求1所述的方法，其特征在于，所述历史编号信息为所述客户端从所述服务端获取到的所有日志的编号；将所述历史编号信息与本地生成的日志的编号信息进行比对，包括：

判断本地生成的日志的编号中是否有区别于所述历史编号信息的编号；

若是，则确定存在对应于所述客户端的未获取日志；否则，确定不存在对应于所述客户端的未获取日志。

6.根据权利要求5所述的方法，其特征在于，还包括：

当接收到所述客户端发送的针对所述未获取日志的日志获取请求时，将编号区别于所述历史编号信息的本地日志作为未获取日志；

向所述客户端返回所述未获取日志和/或本地日志中区别于所述未获取日志的其他日志。

7.一种日志管理方法，其特征在于，应用于客户端；所述日志由服务端生成，所述服务端生成的日志被配置有相应的编号信息；所述方法包括：

创建日志查询请求，所述日志查询请求中包含所述客户端从所述服务端获取到的日志的历史编号信息；

向所述服务端发送日志查询请求，以使得所述服务端将所述历史编号信息和所述服务端本地生成的日志的编号信息进行比对，以判定出是否存在对应于所述客户端的未获取日志；

接收所述服务端返回的判定结果，所述判定结果由所述服务端在判定出存在所述未获取日志时生成。

8.一种日志管理装置，其特征在于，应用于服务端，所述服务端生成的日志被配置有相应的编号信息；所述装置包括：

接收单元，接收客户端发送的日志查询请求，所述日志查询请求中包含所述客户端从所述服务端获取到的日志的历史编号信息；

比对单元，将所述历史编号信息与本地生成的日志的编号信息进行比对，以判定出是否存在对应于所述客户端的未获取日志；

返回单元，当判定出存在所述未获取日志时，向所述客户端返回判定结果。

9.一种电子设备，其特征在于，包括：

处理器；

用于存储处理器可执行任务的存储器；

其中，所述处理器通过运行所述可执行指令以实现如权利要求1-7中任一项所述的方法。

10.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，该指令被处理器执行时实现如权利要求1-7中任一项所述方法的步骤。

Images