日志文件的完整采集确认方法、装置及设备与流程

本说明书实施例涉及信息技术领域，尤其涉及日志文件的完整采集确认方法、装置及设备。

背景技术：

当前，应用程序经常分布式的部署于多台客户端设备上。从而，各客户端设备会各自独立的产生日志文件。

服务端在统计日志文件时，需要将各设备所产生的日志文件进行汇总，以进行进一步的监控或者分析。在这个过程中，需要知道得到的汇总日志文件是不是完整的。例如，应用程序部署在一百台设备上，第三方需要今天10:00至20:00之前的汇总日志文件去做分析，那么至少需要保证在10：00之后，20：00之前这一百台设备所产生的日志记录均已经被服务端收到了，否则分析结果就会不准确。

基于此，需要一种更精确的对日志文件的完整采集的确认方案。

技术实现要素：

针对现有对于日志文件时无法获知日志采集进度的问题，为实现更精确的对日志文件的完整采集的确认，本说明书实施例对于客户端设备方面提供一种日志文件的完整采集确认方法，应用于包括多个客户端设备的系统中，其中，所述多个客户端设备均各自产生同一应用程序的日志文件，所述方法包括：

客户端设备选取本地保存的任一日志文件；

判断被选取的日志文件中是否满足下列条件：不存在新增日志记录，或者，新增日志记录已经被服务端获取；

若满足，确认并发送所述被选取的日志文件所对应的完整性信息和客户端设备标识，以便服务端确认对于多个客户端设备所产生的日志文件的完整采集时刻；

其中，日志文件所对应的完整性信息中包含与日志文件的新增日志记录相关的时间参数，完整采集时刻用于表示所述多个客户端设备在该时间点之前所产生的日志文件已经被服务端完整采集。

同时，本说明书实施例还提供服务端方面的一种日志文件的完整采集确认方法，应用于包括多个客户端设备的系统中，其中，所述多个客户端设备均产生同一应用程序的日志文件，包括：

服务端接收各客户端设备所发送的完整性信息和客户端设备标识，所述完整性信息包括与日志文件的新增日志记录相关的时间参数；

根据所述客户端设备标识和完整性信息中所包含的时间参数，确认各客户端设备的日志文件在服务端的最近更新时刻；

将与当前时刻间隔最大的最近更新时刻，确定为服务端对所述多个客户端设备所产生的日志文件的完整采集时刻。

对应的，本说明书实施例还提供客户端设备方面的一种日志文件的完整采集确认装置，应用于包括多个客户端设备的系统中，其中，所述多个客户端设备均产生同一应用程序的日志文件，包括：

应用于包括多个客户端设备的系统中，其中，所述多个客户端设备均各自产生同一应用程序的日志文件，所述装置包括：

选取模块，客户端设备选取本地保存的任一日志文件；

判断模块，判断被选取的日志文件中是否满足下列条件：不存在新增日志记录，或者，新增日志记录已经被服务端获取；

第一确认模块，若满足，确认所述被选取的日志文件所对应的完整性信息和客户端设备标识，以便服务端确认对于多个客户端设备所产生的日志文件的完整采集时刻；

发送模块，发送所述被选取的日志文件所对应的完整性信息和客户端设备标识；

其中，日志文件所对应的完整性信息中包含与日志文件的新增日志记录相关的时间参数，完整采集时刻用于表示所述多个客户端设备在该时间点之前所产生的日志文件已经被服务端完整采集。

对应的，本说明书实施例还提供服务端方面的一种日志文件的完整采集确认装置，应用于包括多个客户端设备的系统中，其中，所述多个客户端设备均产生同一应用程序的日志文件，包括：

接收模块，服务端接收各客户端设备所发送的完整性信息和客户端设备标识，所述完整性信息包括与日志文件的新增日志记录相关的时间参数；

最近更新时刻确认模块，根据所述客户端设备标识和完整性信息中所包含的时间参数，确认各客户端设备的日志文件在服务端的最近更新时刻；

完整采集时刻确认模块，将与当前时刻间隔最大的最近更新时刻，确定为服务端对所述多个客户端设备所产生的日志文件的完整采集时刻。

本说明书实施例所提供的方案，客户端可以根据本地日志文件的相关状态值进行判断，是否满足下列条件：不存在新增日志记录，或者，新增日志记录已经被服务端获取。在满足条件的时候，发送包含时间参数的完整性信息至服务端。服务端可以根据完整性信息中的时间参数，确认在当前时刻各客户端设备所对应的日志文件分别的最近更新时刻，其中存在这样一个时间点，所有设备所对应的日志文件都已经更新了，进而可以确认出，在所有部署了该应用的客户端设备端上，应用日志文件被完整采集的时刻，即完整采集时刻。并且，可以建立当前时刻和完整采集时刻的对应关系，并根据上述对应关系插入完整采集时刻至汇总了所有设备的日志文件中，起到标记的作用，用于表示在该时间点之前各设备的日志文件已经在其所对应的当前时刻被完整采集了。使得消费方在消费日志文件时可以获知日志采集状态，有助于更精准地分析应用状态，为监控、告警或其它业务指标计算提供支持。

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

此外，本说明书实施例中的任一实施例并不需要达到上述的全部效果。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1是本说明书实施例提供的客户端设备方面的日志文件的完整采集确认方法的流程示意图；

图2为本说明书实施例所提供的完整采集时刻的示意图；

图3为本说明书实施例所提供的服务端方面的日志文件的完整采集确认方法的流程示意图；

图4是本说明书实施例提供的客户端设备方面的日志文件的完整采集确认装置的结构示意图；

图5是本说明书实施例提供的服务端方面的一种日志文件的完整采集确认装置的结构示意图；

图6是用于配置本说明书实施例方法的一种设备的结构示意图。

具体实施方式

为了使本领域技术人员更好地理解本说明书实施例中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于保护的范围。

以下结合附图，详细说明本说明书各实施例提供的技术方案。如图1所示，图1是本说明书实施例提供的客户端设备方面的一种日志文件的完整采集确认方法的流程示意图，该流程具体包括如下步骤：

s101，客户端设备选取本地保存的任一日志文件。

一个应用程序可以通过安装客户端的方式部署在多台客户端设备上。从而，每台客户端设备都会产生对于该应用程序的日志文件，并且保存于客户端设备中。各客户端设备所产生的日志文件通常格式相同，可以被服务端进行汇总。日志文件中一般按照时间顺序，逐条记录了系统操作事件。每条日志记录均会包含对应的产生时刻。

同时，在客户端设备本地，日志文件有可能是多个。每个日志文件中随着时间增长，还会不断的写入新增日志记录。

在本地保存的日志文件有可能是多个的情形下，客户端设备选取日志文件的方式可以是定时遍历的方式，以免遗漏。例如，将日志文件按文件名排序，按照循序每隔3秒钟选取一个日志文件，并进行相应的判断。

s103，判断被选取的日志文件中是否满足下列条件：不存在新增日志记录，或者，新增日志记录已经被服务端获取。

例如，可以预先给每个日志文件附带设定一定的状态标志，状态标志可以有若干取值，分别代表不同的状态，例如取值：a、b以及c，其中，a用于表征日志文件中不存在新增日志记录，b用于表征新增日志记录已经被服务端获取，c表征其它状态。被选中的日志文件的状态标志的取值方式通常是在被选中之前已经被确定，以及，任一日志文件的状态取值还可以随时被客户端设备根据实际情形进行更新。

s105，若满足，确认并发送所述被选取的日志文件所对应的完整性信息和客户端设备标识，以便服务端确认对于多个客户端设备所产生的日志文件的完整采集时刻。

完整性信息是一个包含了时间参数的信息，以及，完整性信息也可以包含状态取值。时间参数与新增日志记录相关，用于反应本地客户端设备中被选中的日志文件中新增日志记录的相关更新时间。

例如，当确定日志文件不存在新增日志记录时，获取日志文件中最后一条日志记录的产生时刻，将其确定为所述时间参数；或者，若解析日志文件的新增日志记录的产生时刻失败，确定完整性信息中的时间参数为默认值，默认值用于表示有新增日志记录，但格式错误，例如，日志时间一般统一使用unixtime表示自1970年1月1日以来经过的秒数，因此，目前的日志时间都不可能是负数，从而可以设置默认值为-1，用来表示新增日志记录格式错误；或者，解析获取日志文件的新增日志记录的产生时刻，将所述新增日志记录的产生时刻确定为时间参数。

在服务端，可以根据客户端设备标识和时间参数对每台客户端设备的日志文件的更新进度进行统计，进而，确定整体的对于多个客户端设备所产生的日志文件的完整采集时刻。

例如，一个应用部署在100台客户端设备上，当服务端统计到当前时刻，在这100个客户端设备上15点以前产生的更新日志记录都已经被服务端全部采集到了，那么该日志文件的完整采集时刻就是15点；如果有99个客户端设备采集到了15点之前的新增日志记录，1个采集到了14点55分之前的新增日志记录，那么该日志文件的完整采集时刻就是14点55分。换言之，完整采集时刻用于表示所述多个客户端设备在该时间点之前所产生的日志文件已经被服务端完整采集。

此外，完整采集时刻是一个动态变化的值。服务端可以根据各设备上报的完整性信息，持续更新各客户端设备的日志更新时间，从而进一步的持续更新完整采集时刻。如果服务端只保留一个完整采集时刻，那么新产生的完整采集时刻会覆盖掉之前的完整采集时刻。在一种实施方式下，服务端在产生完整采集时刻的同时，还记录了此时的当前系统时刻，则可以将完整采集时刻和当前系统时刻建立对应关系，并进行保存，得到一个完整采集时刻和当前系统时刻的数据序列。

例如，在17点24分，完整采集时刻是17点10分，可能到了一小时后18点24分，完整采集时刻是18点15分。如图2所示，图2为本说明书实施例所提供的完整采集时刻的示意图。图2中的实线部分表示某个时刻已经接收到的各设备的日志文件，虚线部分表示在另一时刻，服务端基于新增日志文件对于各设备的日志文件进行了持续性更新，因此产生了另一个完整采集时刻。

由于网络、设备等各种原因，并不是客户端设备每次所发送的日志文件的新增日志记录都会被服务端收到。因此若客户端发送某个新增日志记录失败，还可以再次发送该新增日志记录，直至达到某指定的发送次数，停止发送。例如，客户端在发送某份新增日志记录失败之后，一直没有收到服务端的反馈信息，则认为发送失败，从而再次发送该新增日志记录信息，在发送十次均失败以后，不再发送。新增日志记录没有被服务端也收到可以被记录在完整性信息中。

在一种实施方式下，可以给每个日志文件设置一个发送标志位。发送标志位的取值包括第一标志位值或者第二标志位值。例如，第一标志位值为“t”，第二标志位值为“f”。发送标志位具体的取值方式可以有多种，具体形式此处不做限定。

每当客户端设备中的日志文件更新，产生系统事件时，此时客户端可以读取新增日志记录，并解析新增日志记录的产生时间。在解析新增日志记录的产生时刻成功后，修改所述发送标志位的取值为“f”，用于表示存在新增日志记录，但此时，服务端还未获取所述新增日志记录。然后，发送所述新增日志记录至服务端，当接收到服务端所返回的针对所述新增日志记录的确认信息后，修改所述发送标志位的取值为“t”，用于表示服务端已经获取所述新增日志记录。服务端可以采用回调函数的形式，用来向客户端反馈其已经收到了哪些新增日志记录。

在这种实施方式下，客户端设备对被选取的日志文件进行判断时，可以直接查看对应的发送标志位的取值，若发送标志位的取值为“t”，则可以知道被选取的日志文件中的新增日志记录已经被服务端获取。

进一步地，客户端设备还可以给日志文件的完整性信息进行状态赋值。例如，完整性信息的状态值可以包括第一状态值，用于表示解析失败；第二状态值，用于表示解析成功；以及，第三状态值，用于表示没有新增日志记录。

例如，若客户端设备解析新增日志记录的产生时刻失败，确定所述完整性信息的状态取值为第一状态值，例如，取值为“parsefailed”，用于表示解析失败；若解析新增日志记录的产生时刻成功，定所述完整性信息的状态取值为第二状态值，例如，取值为“ok”，用于表示解析成功。

那么，如果有新增日志记录，即使其没有被服务端收到，其发送标志位的取值应当为“f”；或者，有新增日志记录，而没有被成功解析时，完整性信息的状态取值应当为“parsefailed”。因此，如果客户端设备检测到发送标志位的取值为“t”(代表之前产生的新增日志已经发出去，并且被服务端收到了)，且，所述完整性信息的状态取值为第二状态值(代表之前产生的新增日志确实解析成功了)，那么可以确定在已经被接收的新增日志记录之后，日志文件中不存在其它的新增日志记录。

在客户端设备确定了日志文件中在收到服务端上一次的反馈消息之后，还不存在其它的新增日志记录的情况下，还可以将完整性信息的状态值修改为第三状态值，例如“nonewlog”，代表没有新增日志记录。完整性信息中可以包含完整性信息的状态取值，以便服务端可以更方便的对日志文件的新增日志状态进行确定。例如，服务端在接收到的完整性信息中如果发现有第三状态值，则可以直接确定该客户端设备的日志文件的最近更新时刻保持之前的时刻不变。

此外，在完整性信息中还可以包括，服务端接收到的新增日志记录的记录条数。具体方式即为，服务端将接受到的新增日记记录的条数反馈给客户端设备，客户端设备将上述条数信息写入完整性信息。服务端进而可以根据完整性信息进行相应的统计。

上面部分对本说明书实施例的客户端方面进行了描述，对于服务端方面，本说明书实施例还提供一种日志文件的完整采集确认方法，应用于包括多个客户端设备的系统中，其中，所述多个客户端设备均产生同一应用程序的日志文件，如图3所示，图3为本说明书实施例所提供的服务端方面的日志文件的完整采集确认方法的流程示意图，包括：

s301，服务端接收各客户端设备所发送的完整性信息和客户端设备标识，所述完整性信息包括与日志文件的新增日志记录相关的时间参数。

s303，根据所述客户端设备标识和完整性信息中所包含的时间参数，确认各客户端设备的日志文件在服务端的最近更新时刻。

具体而言，在服务端可以根据客户端设备标识找到，接收到的完整性信息所对应的客户端设备日志文件。然后取出完整性信息中的时间参数，和服务端存储的客户端设备日志文件中的最后一条记录的时间进行对比。

例如，如果完整性信息中的时间参数为默认值(例如，-1)，则，不更新客户端设备日志文件的最近更新时间；如果时间参数和服务端存储的客户端设备日志文件中的最后一条记录的时间相同，也不更新客户端设备日志文件的最近更新时间(此时，可以认为是没有新增日志记录，完整性信息的状态值可以是前述的“nonewlog”)；如果时间参数晚于客户端设备日志文件的最近更新时间，则此时可以将所述时间参数，确认为该客户端设备的日志文件在服务端的最近更新时刻。

在服务端接收到完整性信息之后，还可以对客户端发出反馈信息，通知客户端已经成功接收接收该完整性信息。

s305，将与当前时刻间隔最大的最近更新时刻，确定为服务端对所述多个客户端设备所产生的日志文件的完整采集时刻。

在针对每个客户端设备的日志文件，都有一个对应的最近更新时刻。从而可以知道，在与当前时刻间隔最大的最近更新时刻，所有的客户端都已经完成了新增日志文件的上报。

由于各客户端设备连续不断的上报日志文件的完整性信息(例如，每隔3秒就遍历一次本地的所有日志文件)，服务端可以持续的修正各客户端设备的最近更新时刻，从而动态的得到所有日志文件的完整采集时刻。

本说明书实施例所提供的方案，客户端可以根据本地日志文件的相关状态值进行判断，是否满足下列条件：不存在新增日志记录，或者，新增日志记录已经被服务端获取。在满足条件的时候，发送包含时间参数的完整性信息至服务端。服务端可以根据完整性信息中的时间参数，确认在当前时刻各客户端设备所对应的日志文件分别的最近更新时刻，其中存在这样一个时间点，所有设备所对应的日志文件都已经更新了，进而可以确认出，在所有部署了该应用的客户端设备端上，应用日志文件被完整采集的时刻，即完整采集时刻。使得消费方在消费日志文件时可以获知日志采集状态，有助于更精准地分析应用状态，为监控、告警或其它业务指标计算提供支持。

在一种具体的实施方式，对于步骤s303中的，确认各客户端设备的日志文件在服务端的最近更新时刻，还可以剔除所述多个客户端设备中的异常客户端设备；确认剩余各客户端设备的日志文件在服务端的最近更新时刻。

例如，若某个客户端设备超过30分钟没有上报新的完整性信息，或者上报的完整性信息中的时间参数30分钟没一直不变，认为该客户端设备已经发生故障。或者，从某些其它渠道(例如，系统通知)确认发生故障的客户端设备。那么，可以不再统计异常设备的最近更新时间，在计算完整性时刻时也不再包括这些已经异常的客户端设备。

在一种实施方式下，可以预先设定完整采集条件，例如，在一个指定的最近更新时刻，有90％的客户端设备已经完成了采集，则可以将该最近更新时刻确认为完整采集时刻。在这种情况下，满足条件的最近更新时刻可能会有多个，当前时间间隔最大的最近更新时刻确定为所述日志文件的完整采集时刻，以及，完整采集条件还可以设置多个档次，例如，90％，95％，99％等等若干不同等级。

在确定了完整采集时刻之后，服务端还可以将客户端设备产生的日志文件进行汇总，生成业务日志汇总文件，并且，将完整采集时刻写入所述业务日志汇总文件中，从而可以随时知道该应用程序的所有设备所产生的日志文件所完整采集的时刻。

在一种实施方式下，服务端还可以建立当前时刻与完整采集时刻的对应关系，并存储；汇总各客户端设备产生的日志文件，生成业务日志汇总文件；根据所述当前时刻与完整性时刻的对应关系，在业务日志汇总文件中标记任一时间点所对应的完整采集时刻。从而，可以在以后需要拿去指定时间段的日志文件时，可以知道在该时间段，应用程序相关的日志文件所对应的完整采集时刻。

此外，在完整性信息中还包括服务端接收到的新增日志记录的记录条数时，服务端还可以定时统计新增日志记录的总条数，例如，每分钟统计一次接收到的各客户端设备的新增日志记录的条数，以及，接收到的总条数，以便第三方使用所述业务日志汇总文件时，可以根据上述信息进行核对。容易理解，统计的时间间隔可以是基于需要进行设定的，可以是诸如30秒、1分钟、3分钟等等。

例如，消费方需要在3点08分的时候，统计1点到3点一共有多少条日志，那么首先，可以根据完整采集时刻确认在3点08分这个时刻，1点到3点各设备所产生的日志是否全部发过来了，以及，进一步地，根据完整性信息中的条数记录进行总记录条数的计算，以核对服务端生成的日志汇总文件中，1点到3点的新增日志条数是否正确，以保证在日志文件基础上做出的统计会更准确。

对应的，在客户端方面，本说明书实施例还提供一种日志文件的完整采集确认装置，用于包括多个客户端设备的系统中，其中，所述多个客户端设备均各自产生同一应用程序的日志文件，如图4所示，图4是本说明书实施例提供的客户端设备方面的日志文件的完整采集确认装置的结构示意图，包括：

选取模块401，客户端设备选取本地保存的任一日志文件；

判断模块403，判断被选取的日志文件中是否满足下列条件：不存在新增日志记录，或者，新增日志记录已经被服务端获取；

第一确认模块405，若满足，确认所述被选取的日志文件所对应的完整性信息和客户端设备标识，以便服务端确认对于多个客户端设备所产生的日志文件的完整采集时刻；

发送模块407，发送所述被选取的日志文件所对应的完整性信息和客户端设备标识；

其中，日志文件所对应的完整性信息中包含与日志文件的新增日志记录相关的时间参数，完整采集时刻用于表示所述多个客户端设备在该时间点之前所产生的日志文件已经被服务端完整采集。

进一步地，所述装置还包括第二确认模块409，当确定日志文件不存在新增日志记录时，获取日志文件中最后一条日志记录的产生时刻，将其确定为所述时间参数；或者，若解析日志文件的新增日志记录的产生时刻失败，确定完整性信息中的时间参数为默认值，用于表示有新增日志记录，但格式错误；或者，解析获取日志文件的新增日志记录的产生时刻，将所述新增日志记录的产生时刻确定为时间参数。

进一步地，所述判断模块403，获取所述日志文件的发送标志位的取值；若所述发送标志位的取值为第一标志位值，判断所述日志文件中的新增日志记录已经被服务端获取；

进一步地，所述装置还包括取值模块411，解析新增日志记录的产生时刻，在解析新增日志记录的产生时刻成功后，修改所述发送标志位的取值为第二标志位值，用于表示存在新增日志记录，且服务端还未获取所述新增日志记录；发送所述新增日志记录至服务端，当接收到服务端所返回的针对所述新增日志记录的确认信息后，修改所述发送标志位的取值为第一标志位值，用于表示服务端已经获取所述新增日志记录。

进一步地，所述判断模块403，若所述发送标志位的取值为第一标志位值，且，所述完整性信息的状态取值为第二状态值，确定日志文件中不存在新增日志记录；所述取值模块411还用于，若解析新增日志记录的产生时刻失败，确定所述完整性信息的状态取值为第一状态值，用于表示解析失败；若解析新增日志记录的产生时刻成功，定所述完整性信息的状态取值为第二状态值，用于表示解析成功。

进一步地，所述日志文件对应的完整性信息中还包括服务端接收到的新增日志记录的记录条数。

对应的，在服务端方面，本说明书实施例还提供一种日志文件的完整采集确认装置，用于包括多个客户端设备的系统中，其中，所述多个客户端设备均各自产生同一应用程序的日志文件，如图5所示，图5是本说明书实施例提供的服务端方面的一种日志文件的完整采集确认装置的结构示意图，包括：

接收模块501，服务端接收各客户端设备所发送的完整性信息和客户端设备标识，所述完整性信息包括与日志文件的新增日志记录相关的时间参数；

最近更新时刻确认模块503，根据所述客户端设备标识和完整性信息中所包含的时间参数，确认各客户端设备的日志文件在服务端的最近更新时刻；

完整采集时刻确认模块505，将与当前时刻间隔最大的最近更新时刻，确定为服务端对所述多个客户端设备所产生的日志文件的完整采集时刻。

进一步地，所述最近更新时刻确认模块503，剔除所述多个客户端设备中的异常客户端设备；确认剩余各客户端设备的日志文件在服务端的最近更新时刻。

进一步地，所述最近更新时刻确认模块503，确定满足完整采集条件的多个最近更新时刻；将满足完整采集条件的多个最近更新时刻中，与当前时间间隔最大的最近更新时刻确定为所述日志文件的完整采集时刻；所述完整采集条件包括：在被选中的最近更新时刻，已经在服务端完成日志文件更新的设备的数量或者比例超过阈值。

进一步地，所述装置还包括写入模块507，汇总各客户端设备产生的日志文件，生成业务日志汇总文件；将所述完整采集时刻写入所述业务日志汇总文件中。

进一步地，所述装置还包括标记模块509，建立当前时刻与完整采集时刻的对应关系，并存储；汇总各客户端设备产生的日志文件，生成业务日志汇总文件；根据所述当前时刻与完整性时刻的对应关系，在业务日志汇总文件中标记任一时间点所对应的完整采集时刻。

进一步地，所述装置还包括统计模块511，统计指定时间间隔内新增日志记录的总条数，以便第三方使用所述业务日志汇总文件时进行核对。

本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现图1或者图3所示的日志文件的完整采集确认方法。

图6示出了本说明书实施例所提供的一种更为具体的计算设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。

处理器1010可以采用通用的cpu(centralprocessingunit，中央处理器)、微处理器、应用专用集成电路(applicationspecificintegratedcircuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器1020可以采用rom(readonlymemory，只读存储器)、ram(randomaccessmemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。

输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。

总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现图1或者图3所示的日志文件的完整采集确认方法。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。

上述实施例阐明的系统、方法、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于方法实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的方法实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护范围。