CN113687974A - 客户端日志处理方法、装置及计算机设备 - Google Patents

Abstract

本申请提出了一种客户端日志处理方法、装置及计算机设备，在日志回捞场景下，可以依据应用要求，确定针对目标客户端的设备标识、日志上报时间段及上报日志类型，将包含这些信息的日志上报指令发送至具有该设备标识的目标设备，以使该目标设备的目标客户端响应该日志上报指令，从数据库存储的日志中，筛选与日志上报时间段及上报日志类型相匹配的目标日志，之后，将利用目标日志的生成时间，按照预设单位时长对目标日志进行分割处理，得到多个待上报日志文件后，将这多个待上报日志文件上报至日志服务器，相对于直接上报筛选出的目标日志的处理方式，本申请这种将目标日志分片后再上报的处理方式，提高了日志上报速率和成功率。

Description

客户端日志处理方法、装置及计算机设备

技术领域

本申请主要涉及客户端应用领域，更具体地说是涉及一种客户端日志处理方法、装置及计算机设备。

背景技术

随着互联网通信技术的发展，应用开发商往往会不断更新或维护客户端，以更好地满足用户对客户端的使用需求，然而，在客户端使用过程中，可能会因各种内在和/或外在因素，导致客户端运行出现各种异常问题，甚至会崩溃无法运行，降低用户对客户端的使用体验。

为了排查客户端出现的异常问题，通常是依据客服反馈和用户的页面表现，对逻辑代码进行排查推测，可能还需要用户配合，才能够推测出问题原因，不仅会对用户造成干扰，且整个过程繁琐，降低了问题解决效率和可靠性。

发明内容

有鉴于此，为了解决上述技术问题，本申请提供了以下技术方案：

一方面，本申请提出了一种客户端日志处理方法，所述方法包括：

获取针对目标客户端的日志上报指令；所述日志上报指令包括设备标识、日志上报时间段和上报日志类型；

响应所述日志上报指令，从与所述设备标识关联存储的日志中，筛选与所述日志上报时间段和所述上报日志类型相匹配的目标日志；

若所述日志上报时间段大于预设单位时长，利用所述目标日志的生成时间，按照所述预设单位时长，对所述目标日志进行分割处理，得到多个待上报日志文件；

将所述多个待上报日志文件上报至日志服务器。

可选的，所述将所述多个待上报日志文件上报至日志服务器，包括：

对所述多个待上报日志文件分别进行加密压缩处理，得到相应的日志加密压缩文件；

将得到的多个所述日志加密压缩文件上报至日志服务器；

检测所述日志加密压缩文件是否上报成功；

若存在上报成功的所述日志加密压缩文件，删除本地存储的该日志加密压缩文件对应的日志；

若存在上报失败的所述日志加密压缩文件，检测到该日志加密压缩文件的上报失败次数小于上报次数阈值，重新向所述日志服务器上报该日志加密压缩文件；

检测到该日志加密压缩文件的上报失败次数不小于上报次数阈值，中断对该日志加密压缩文件的上报，输出针对该日志加密压缩文件的上报失败提示信息。

可选的，所述对所述多个待上报日志文件分别进行加密压缩处理，得到相应的日志加密压缩文件，包括：

采用对称加密算法，对每一个所述待上报日志文件进行加密压缩处理，得到相应的日志加密压缩文件。

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

基于WCDB移动数据库架构，将目标客户端运行过程中产生的各种数据，存储为相应类型的日志，并记录所述日志的生成时间；

获取所述日志的生成时间与当前时间之间的时间差，将所述时间差确定为相应所述日志的存储时长；

检测所述日志的存储时长是否超过预设有效时长；

若是，删除超过所述预设有效时长的所述存储时长所对应存储的所述日志。

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

统计已存储日志的数据量；

检测所述数据量是否达到数据量阈值；

若达到，按照所述日志的生成时间从早到晚的顺序，删除超过所述数据量阈值的日志。

又一方面，本申请还提出了一种客户端日志处理方法，所述方法包括：

输出日志回捞页面；

响应于对所述日志回捞页面的输入操作，得到待回捞日志对应的目标客户端的设备标识、待回捞日志的日志上报时间段和上报日志类型；

响应于在所述日志回捞页面输入的确认回捞操作，生成针对所述目标客户端的日志上报指令；所述日志上报指令包含有所述设备标识、所述日志上报时间段和所述上报日志类型；

利用所述设备标识，通过长连接通信方式，将所述日志上报指令下发至运行所述目标客户端的目标设备。

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

在所述日志回捞页面输出多个待上报日志文件各自的日志属性信息；其中，所述多个待上报日志文件是所述目标客户端响应所述日志上报指令得到的；所述日志属性信息包括相应待上报日志文件的用户标识、所包含日志的最新生成时间、文件上报时间、文件名称、所包含日志类型之中的一个或多个；

响应于对输出的任一所述待上报日志文件的确认下载操作，向日志服务器发送针对所确定的目标上报日志文件的查看请求；

接收所述日志服务器响应所述查看请求所反馈的所述目标上报日志文件；

输出所述目标上报日志文件包含的日志。

又一方面，本申请还提出了一种客户端日志处理装置，所述装置包括：

日志上报指令获取模块，用于获取针对目标客户端的日志上报指令；所述日志上报指令包括设备标识、日志上报时间段和上报日志类型；

目标日志筛选模块，用于响应所述日志上报指令，从与所述设备标识关联存储的日志中，筛选与所述日志上报时间段和所述上报日志类型相匹配的目标日志；

目标日志分割处理模块，用于若所述日志上报时间段大于预设单位时长，利用所述目标日志的生成时间，按照所述预设单位时长，对所述目标日志进行分割处理，得到多个待上报日志文件；

日志文件上报模块，用于将所述多个待上报日志文件上报至日志服务器。

又一方面，本申请还提出了一种客户端日志处理装置，所述装置包括：

日志回捞页面输出模块，用于输出日志回捞页面；

信息获得模块，用于响应于对所述日志回捞页面的输入操作，得到待回捞日志对应的目标客户端的设备标识、待回捞日志的日志上报时间段和上报日志类型；

日志上报指令生成模块，用于响应于在所述日志回捞页面输入的确认回捞操作，生成针对所述目标客户端的日志上报指令；所述日志上报指令包含有所述设备标识、所述日志上报时间段和所述上报日志类型；

日志生成指令下发模块，用于利用所述设备标识，通过长连接通信方式，将所述日志上报指令下发至运行所述目标客户端的目标设备。

又一方面，本申请还提出了一种计算机设备，所述计算机设备包括：至少一个存储器和至少一个处理器，其中：

所述存储器，用于存储如上述的客户端日志处理方法的第一程序，或存储如上述的客户端日志处理方法的第二程序；

所述处理器，用于加载并执行所述存储器存储的所述第一程序，以实现上述相应的客户端日志处理方法；或者加载并执行所述存储器存储的所述第二程序，以实现上述相应的客户端日志处理方法。

由此可见，本申请提供了一种客户端日志处理方法、装置及计算机设备，在日志回捞场景下，可以依据应用要求，确定针对目标客户端的设备标识、日志上报时间段及上报日志类型，将包含这些信息的日志上报指令发送至具有该设备标识的目标设备，以使该目标设备的目标客户端响应该日志上报指令，从数据库存储的日志中，筛选与日志上报时间段及上报日志类型相匹配的目标日志，之后，将利用目标日志的生成时间，按照预设单位时长对目标日志进行分割处理，得到多个待上报日志文件后，将这多个待上报日志文件上报至日志服务器，相对于直接上报筛选出的目标日志的处理方式，本申请这种将目标日志分片后再上报的处理方式，提高了日志上报速率和成功率，有助于提高基于日志分析结果定位问题的处理效率。

附图说明

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

图1为适用于本申请提出的客户端日志处理方法的系统架构示意图；

图2为适用于本申请提出的客户端日志处理方法的计算机设备的一可选示例的硬件结构示意图；

图3为适用于本申请提出的客户端日志处理方法的计算机设备的又一可选示例的硬件结构示意图；

图4为本申请提出的客户端日志处理方法的一可选示例的流程示意图；

图5为本申请提出的客户端日志处理方法的又一可选示例的流程示意图；

图6为本申请提出的客户端日志处理方法的又一可选示例的流程示意图；

图7为本申请提出的客户端日志处理方法的又一可选示例的流程示意图；

图8为本申请提出的客户端日志处理方法中，日志回捞页面示意图；

图9为本申请提出的客户端日志处理装置的一可选示例的结构示意图；

图10为本申请提出的客户端日志处理装置的又一可选示例的结构示意图。

具体实施方式

针对背景技术部分描述的内容，本申请希望能够快速有效排查线上问题，由于很多线上问题都是偶然的，技术人员希望可以通过相同操作和设备进行复现，以定位问题，但经过试验得知，在相同的机型、系统、环境下也很难对线上问题复现。对此，本申请提出通过对客户端运行期间产生的日志进行分析，依据日志分析结果来排查问题。而且，日志系统获取日志的过程，对用户来说是无感知的；日志分析过程也不需要用户配合，避免了对用户的干扰。

然而，日志系统通常是实时采集客户端运行产生的数据，以日志方式进行本地存储，或直接上传至服务器侧进行存储，以供后续调用，这样，随着客户端的使用时间增加，所存储的日志数据量会非常庞大，若直接将记录的大量日志直接上报至服务器，往往需要占用较多网络资源，且很容易因网络或其他因素导致日志上传失败，即日志上报成功率较低，影响了后续基于日志进行问题定位的应用需求。

为了进一步改善上述问题，提高日志上传成功率，本申请提出由客户端分片上传日志，即将大量的日志分割成多个日志文件上传至服务器，保证每一次上传的日志文件都不会很大，减少一个日志文件上传过程对网络资源的占用量，提高日志文件上传速度，并保证上传成功率。

而且，为了方便后续精准查询，本申请提出按照预设单位时长，如以天为单位，对采集到的日志进行分割处理，将每一天生成的日志写入一个日志文件中，将该日志文件包含的日志为一个整体上传至服务器，后续可以直接查询某一天或多天的日志文件。

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

参照图1，为适用于本申请提出的客户端日志处理方法的系统架构示意图，该系统可以包括客户端11、日志服务器12以及日志数据库13，其中：

客户端11可以为用户提供业务服务的应用程序，可以是用户的终端设备（如智能手机、笔记本电脑、台式电脑、机器人、车载终端、可穿戴设备等）上独立安装的应用程序，如从应用商店下载安装的某狐的视频播放软件等，也可以是通过浏览器等应用访问的网页应用程序等，如通过浏览器输入视频网站地址，观看/下载各种视频资源等，本申请对客户端11的应用类型不做限制，可视情况而定。

本申请实施例中，为了方便后续定位异常问题，客户端运行过程中，可以从多方面记录所产生的各类型的数据，存储为相应类型的日志，如将业务方面的数据存储为业务日志、将客户端自身方面的数据存储为应用日志、将网络方面的数据存储为网络日志等，本申请对需要记录的日志数据类型不做限制，可以依据实际需求预先定义，实现过程本申请实施例在此不做详述。

日志服务器12可以是支持日志平台的日志查询、分析等功能的服务设备，可以是独立的物理服务器，也可以是多台物理服务器构成的服务集群，还可以是能够实现云计算服务的云服务器等，在实际应用中，日志服务器12可以通过有线网络或无线网络与各种终端通信连接，实现两者之间的数据传输，满足应用需求，本申请对日志服务器12与终端之间的通信方式不做限制，可视情况而定。

在本申请实际应用中，对于如上述客户端11运行过程中产生的日志，可以直接上报至该日志服务器12，以供其他客户端通过该日志服务器12访问该客户端11的某些日志数据。示例的，如客户端后台技术人员得知某用户的客户端（为了方便描述可以将其记为目标客户端）运行异常，可以通过终端设备的浏览器登录日志平台，以使该终端设备输出日志回捞页面，技术人员可以在该日志回捞页面输入目标客户端的设备唯一标识UID（UniqueIdentifier），从而依据该UID向目标设备发送针对目标客户端的日志上报指令，以获取所需的该目标客户端的日志，具体实现过程可以参照下文方法实施例相应部分的描述，本实施例在此不做赘述。

在整个日志回捞实现过程中，日志服务器12可以用于实现不同终端设备之间的数据传输，如日志上报指令、日志文件等数据的传输，实现过程可视情况而定，本申请实施例不做详述。

日志数据库13可以是用于存储日志的数据存储设备，根据实际应用需求，该日志数据库13可以是本地数据库，也可以是云数据库等。对于本地数据库可以直接部署在用户的终端设备中，这种情况下，该本地数据库可以是该终端设备的存储器；根据需要，本地数据库也可以是区别于客户端所在终端设备的独立存储设备，本申请对此不做限制。

为了提高日志读写速度，更好地满足单个日志或批量日志的读写需求，本申请提出该日志数据库13可以采用WCDB移动数据库架构，即一种高效、完整、易用的跨平台移动数据库框架，可以支持多种操作系统，具有多线程高并发、基于SQLCipher的数据库加密、损坏修复等功能，本申请对WCDB的组件结构不做详述。

结合上文对本申请技术构思的描述，对于如视频类等客户端运行过程中产生的各类数据，可以依据不同类型日志对应的宏定义，存储为相应类型的日志，包括但并不局限于上文列举的业务日志、应用日志、网络日志等，可选的，本申请可以按照数据表中的日志字段，实现日志数据的存储，如调用相应类型日志的API（Application Program Interface，应用程序接口）实现日志数据的存储，实现过程本申请不做详述。

在本申请提出的一些实施例中，为了避免本地数据库所存储的日志数据量过大，影响终端设备的工作性能，降低所需目标日志的查询效率，本申请提出的日志数据的淘汰策略，也就是对数据库存储的日志数据配置有效时长，一旦该日志数据的存储时长超过预设有效时长，认为该日志数据失效，可以直接删除这类日志数据，从而减小数据库存储的日志数据量，有助于提高后续日志数据的读写速度。

需要说明，本申请对日志数据的预设有效时长的数值不做限制，可视情况而定。示例性的，该预设有效时长可以是三天，也就是说，对于采集到的日志数据最长可以存储三天，存储时长超过三天的日志数据直接删除。

应该理解的是，图1所示的客户端日志处理系统的结构并不构成对本申请实施例中系统架构的限定，在实际应用中，该系统架构可以包括比图1所示的更多或更少的设备，或者组合某些设备，本申请在此不做一一列举。

参照图2，为适用于本申请提出的客户端日志处理方法的计算机设备的一可选示例的硬件结构示意图，该计算机设备可以是日志服务器或终端设备，可以理解，在实现日志记录、回捞等处理过程中，不同计算机设备侧执行的客户端日志处理方法可能存在差异，实现过程可以参照下文方法实施例相应部分的描述。如图2所示，该计算机设备可以包括至少一个存储器21和至少一个处理器22，其中：

存储器21可以用于存储本申请提出的客户端日志处理方法的程序，处理器22可以用于加载并执行该存储器21存储的程序，以实现本申请提出的客户端日志处理方法，实现过程可以参照下文实施例相应部分的描述。

其中，由于不同身份用户（如普通用户、客户端开发者等）的终端设备执行的客户端日志处理方法的流程不同，对于普通用户使用的终端设备，可以将其包含的存储器记为第一存储器，所包含的处理器记为第一处理器，第一存储器可以存储终端侧能够执行的客户端日志处理方法的第一程序，由第一处理器加载并执行该第一程序，实现终端设备侧执行的客户端日志处理方法。

同理，对于客户端开发者或维护人员使用的终端设备，记为日志分析设备，这种情况下，可以将其包含的存储器记为第二存储器，其包含的处理器记为第二处理器，该第二存储器可以用于存储日志分析设备侧执行的客户端日志处理方法的第二程序；第二处理器可以加载并执行该第二程序，实现日志分析设备侧执行的客户端日志处理方法，实现过程本申请不做详述。

本申请实施例中，上述存储器21可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件或其他易失性固态存储器件。处理器22，可以为中央处理器(Central Processing Unit，CPU)、特定应用集成电路(application-specificintegrated circuit，ASIC)、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件等。

在本申请提出的又一些实施例中，若上述计算机设备为终端设备，如图3所示，其还可以包括如感应触摸显示面板上的触摸事件的触摸感应单元、键盘、鼠标、摄像头、拾音器等至少一个输入设备；如显示器、扬声器、振动机构、灯等至少一个输出设备，图3并未示出终端设备包含的各输入设备、输出设备，可以依据终端设备的功能需求确定；此外，该终端设备还可以包括通信接口，实现与其他设备之间的通信连接，该通信接口可以是如WIFI模块、5G/6G（第五代移动通信网络/第六代移动通信网络）模块、GPRS模块等通信模块的数据接口，也可以包括如USB接口、串/并口等实现终端设备内部组件之间数据传输的接口，本申请不做详述。

另外，如图3所示，终端设备可以包括各种传感器构成的传感器模组，用于检测用户对终端设备的输入操作、终端设备工作参数等；以及电源管理模组、天线等组件，本申请对终端设备包含的组成结构不做限制，可能包括比图3所示的更多或更少的组件，或者组合某些组件，本申请不做一一列举。

参照图4，为本申请提出的客户端日志处理方法的一可选示例的流程示意图，该方法可以由计算机设备执行，该计算机设备可以是普通用户使用客户端的终端设备，本实施例可以对该终端设备如何上报其运行的目标客户端的日志的过程进行描述，但并不局限于本实施例描述的客户端日志上报实现过程。如图4所示，该方法可以包括：

步骤S11，获取针对目标客户端的日志上报指令；

本申请实施例中，该日志上报指令可以包括设备标识UID、日志上报时间段和上报日志类型等内容，本申请对该日志上报指令的生成方式及其内容不做限制，可视情况而定。

在一些实施例中，在目标客户端运行异常的情况下，可以自动上报异常检测请求，以使后台维护人员接收到该异常检测请求后，可以登录日志平台，输入针对该目标客户端的日志上报时间段、上报日志类型等信息，生成包含这些信息的日志上报指令，发送至该目标客户端所运行的目标设备，以请求获取该目标设备的本地数据库记录的相关日志。

在又一些实施例中，用户在使用目标客户端过程中，若出现运行卡顿等问题，也可以主动上报异常，请求后台查询异常原因并解决，以保证目标客户端的运行流畅。关于日志上报指令的获取方式包括但并不局限于上文实施例列举的获取方法。

步骤S12，响应该日志上报指令，从与设备标识关联存储的日志中，筛选与日志上报时间段和上报日志类型相匹配的目标日志；

结合上文对日志上报指令的描述，后台服务器可以依据该日志上报指令包含的设备标识，将该日志上报指令发送至具有该设备标识的目标设备，以使该目标设备中的目标客户端响应该日志上报指令，来筛选需要上报的目标日志。

对于目标客户端运行过程中生成的各类日志，可以存储在本地数据库或云端数据库，为了区别不同设备的日志，可以将生成的日志与设备标识关联存储。进一步，本申请可以获取相应的日志属性信息，如用户标识、日志生成时间等，将其与相应的日志进行关联存储，以便后续通过相应维度信息，从数据库中筛选所需维度下的目标日志，本申请对数据库存储日志的实现方法不做限制。

本申请实施例中，通过解析日志上报指令，得知需要上报哪个客户端在什么时间段内生成的什么类型的目标日志后，可以据此从数据库存储的各类日志中，筛选相匹配的日志为目标日志，也就是说，本申请获取的日志上报指令中包含有日志筛选条件，通过解析该日志上报指令，可以得到针对目标客户端的日志筛选条件，之后，从数据库存储的日志中，筛选符合该日志筛选条件的目标日志，筛选实现过程本申请不做限制。

示例性的，假设针对目标客户端的日志上报时间段是从2021年7月21日19:00，到2021年7月23日21:00，上报日志类型是所有类型，那么，本申请可以在数据库中筛选，这个时间段内生成的各类日志，将筛选出的日志确定为目标日志。

步骤S13，若日志上报时间段大于预设单位时长，利用目标日志的生成时间，按照预设单位时长，对目标日志进行分割处理，得到多个待上报日志文件；

如上文对本申请技术构思的相关描述，为了提高日志上报成功率，对于筛选的目标日志，本申请可以按照预设单位时长进行分片，具体可以利用该目标日志的生成时间，按照该预设单位时长对多个目标日志进行分割处理，将每一个预设单位时长内连续生成的日志写入一个日志文件，记为一个待上报日志文件。本申请对该预设单位时长的数值不做限制，可视情况而定，通常情况下分割后得到的每个待上报日志文件的数据量不会超过某一数量阈值，以保证该待上报日志文件的上报速率。

可选的，以预设单位时长为一天为例，本申请可以将每一天生成的日志写入一个日志文件，因此，对于从2021年7月21日19:00，到2021年7月23日21:00之间生成的日志，可以将2021年7月21日19:00到2021年7月21日24:00之间生成的日志写入第一个日志文件，将2021年7月22日生成的日志写入第二个日志文件；将2021年7月23日0:00至2021年7月23日21:00之间生成的日志写入第三个日志文件，将这三个日志文件作为待上报日志文件。同理，对于其他数值的预设单位时长，对筛选出的日志文件的分割方法类似，本申请不做一一详述。

步骤S14，将多个待上报日志文件上报至日志服务器。

目标客户端按照上述方式，将筛选出的目标日志，以预设单位时长写入不同的待上报日志文件后，可以以每一个待上报日志文件为一个传输包上传至日志服务器，由于每一个待上报日志文件最多包含预设单位时长内生成的目标日志，相对于在整个日志上报时间段内生成的目标日志的数据量是较少的，经过这种分片处理后，能够提高日志上报成功率，提高目标日志上报可靠性。

可选的，为了提高目标日志上报安全性，本申请可以对每一个待上报日志文件进行加密压缩处理后，再上报至日志服务器，具体加密压缩实现方法本申请不作限制，可视情况而定。

综上，在日志回捞场景下，可以依据应用要求，确定针对目标客户端的设备标识、日志上报时间段及上报日志类型，将包含这些信息的日志上报指令发送至具有该设备标识的目标设备，以使该目标设备的目标客户端响应该日志上报指令，从数据库存储的日志中，筛选与日志上报时间段及上报日志类型相匹配的目标日志，之后，将利用目标日志的生成时间，按照预设单位时长对目标日志进行分割处理，得到多个待上报日志文件后，将这多个待上报日志文件上报至日志服务器，相对于直接上报筛选出的目标日志的处理方式，本申请这种将目标日志分片后再上报的处理方式，提高了日志上报速率和成功率，有助于提高基于日志分析结果定位问题的处理效率。

参照图5，为本申请提出的客户端日志处理方法的又一可选示例的流程示意图，该方法可以由终端设备执行，为了区分其他不需要上报日志的客户端的终端设备，本申请实施例将需要上报日志的目标客户端所运行的终端设备记为目标设备，设备类型可视情况而定。本申请实施例可以是上文实施例描述的客户端日志处理方法的一可选细化实现方法，主要是对多个待上报日志文件的上报过程的细化，但并不局限于本实施例描述的细化实现方法，关于待上报日志文件的获取过程，可以参照上文实施例相应部分的描述，本实施例不做赘述。

如图5所示，本实施例提出的客户端日志处理方法可以包括：

步骤S21，对多个待上报日志文件分别进行加密压缩处理，得到相应的日志加密压缩文件；

在需要目标客户端的日志回捞应用场景下，即需要向指定目标设备下发指令，以使其上传目标客户端的目标日志的应用场景下，目标客户端接收到日志上报指令后，可以按照上文描述的方式筛选出满足日志上报要求的目标日志后，为了提高上报成功率和速率，将按照上述方式对其进行分片处理，将筛选出的所有目标日志分割成多个待上报日志文件，实现过程本实施例不做赘述。需要说明，如上文分析，本申请的日志上报要求包括但并不局限于对日志生成时间和日志类型的要求，可依据实际场景要求进行适应性调整。

本申请实施例中，对于分割处理后得到的每一个待上报日志文件，为了避免其传输过程中出现部分数据丢失、被窃取等问题，提高数据传输安全性和可靠性，本申请提出先对每一个待上报日志文件进行加密压缩处理，将每个待上报日志文件处理为500kb以内的压缩文件，但并不局限于500kb这一数据量阈值，可以依据目标客户端类型以及传输网络参数等信息确定，以视频类客户端为例，500kb可以是视频切片上传的经验值，即保证具有较高上传成功率的同时，尽量减少分片数量，实现两者平衡的数值，可以根据实际场景需求进行适应性调整。

而且，在对待上报日志文件进行压缩处理的同时，可以利用合适的加密算法，对压缩文件进行加密，相对于网络传输明文的待上报日志文件的方式，本申请提出的这种加密压缩策略，保证了日志数据的传输安全性。且考虑传输性能的问题，本申请可以选择但并不局限于对称加密算法，来实现对各待上报日志文件的加密压缩处理。

其中，对称加密算法也称为私钥加密算法，即指加密和解密使用相同的密钥的加密算法，本申请实际应用中，目标客户端利用预设密钥，对每个待上报日志文件进行加密压缩处理后上报，对于下载该日志加密压缩文件的设备来说，其仍需要获取该预设密钥对该日志加密压缩文件进行解密解压处理，得到相应的待上报日志文件，本申请对预设密钥的配置和通知方法不做限制，可视情况而定。

在实际应用中，对于上述日志加密压缩文件的命名，可以结合其包含的目标日志的生成时间等时间戳实现，以便后续依据时间进行所需日志的筛选，且，对于下载该日志加密压缩文件的用户来说，可以直接通过文件命名，直观得知其包含的是哪个时间段生成的日志，根据需要，对于日志的生成时间可以精确到分钟，但并不局限于此。

步骤S22，将得到的多个日志加密压缩文件上报至日志服务器；

步骤S23，检测日志加密压缩文件是否上报成功，若是，进入步骤S24；若否，执行步骤S25；

步骤S24，删除本地存储的上报成功的日志加密压缩文件对应的日志；

本申请实施例中，对于上文得到的多个待上报的日志加密压缩文件，可以采用表单的方式进行上报，为了减少对目标设备的存储空间的占用，本申请实施例提出在确定其上报成功后，可以将本地数据库存储的相应目标日志删除，所以，对于上报的每个日志加密压缩文件，均可以检测其是否上报成功，具体检测实现方法不做限制。

可选的，由于本申请可以长连接通信的方式下发日志上报指令，目标客户端所运行的目标设备将某日志加密压缩文件上报至日志服务器，日志服务器成功接收到该日志加密压缩文件，可以反馈接收成功的提示信息，目标客户端依据据此确定是否成功上报日志加密压缩文件，但并不局限于这种检测实现方法。

步骤S25，检测上报失败的日志加密压缩文件的上报失败次数是否小于上报次数阈值，若是，进入步骤S26；若否，执行步骤S27；

步骤S26，重新向日志服务器上报该上报失败的日志加密压缩文件；

步骤S27，中断对该上报失败的日志加密压缩文件的上报，输出针对该日志加密压缩文件的上报失败提示信息。

在一些实施例中，本申请可以预先配置重试策略，即允许每一个日志加密压缩文件上传失败，并设置上报次数阈值，即上报失败的最多次数，一旦某日志加密压缩文件的上报失败次数达到该上报次数阈值，可以暂时中断本次对该日志加密压缩文件的上报，根据需要可以输出相应的上报失败提示信息，以通过目标客户端的用户以及后台维护人员这一结果，以便后续需要时重新上报该日志加密压缩文件，也就是在其他时间重新上报本次上报失败的日志加密压缩文件。

对于日志加密压缩文件的上报失败次数未达到预设的上报次数阈值的情况下，仍允许目标设备重新上报该日志加密压缩文件，本申请对该上报次数阈值的数值不做限制，可视情况而定。

综上，本申请实施例在将筛选出的需要上报的所有目标日志后，为了提高上报成功率，将其分割成多个待上报日志文件，之后，将对每个待上报日志进行加密压缩处理，得到相应的日志加密压缩文件后，再上报至日志服务器，提高了日志数据传输安全性，且通过压缩处理，将每次上传的文件数据量压缩为一定阈值内，进一步提高了日志上报速率和可靠性。

之后，为了提高日志上报可靠性，本申请实施例提出检测每一个日志加密压缩文件是否成功上报，若失败，但上报失败次数小于上报次数阈值，允许其重新上报该日志加密压缩文件。若上报失败次数达到上报次数阈值仍未成功上报，可以暂时中断上报，输出相应的上报失败提示信息，提醒用户或后台维护人员得知这一上报结果，在需要时重新通知目标设备上报该日志加密压缩文件。

参照图6，为本申请提出的客户端日志处理方法的又一可选示例的流程示意图，本申请实施例可以对记录目标客户端的日志过程进行描述，该方法仍可以由终端设备执行，如图6所示，该方法可以包括：

步骤S31，基于WCDB移动数据库架构，将目标客户端运行过程中产生的各种数据，存储为相应类型的日志，并记录日志的生成时间；

本申请实施例中，将采用性能更优的WCDB移动数据库架构，构建日志数据库，在目标客户端运行过程中，可以将采集到的缓存文件以及日志，合并到数据库中存储，使得文件的数据量保持在100MB以下，但并不局限于该数据量，实现过程可以结合WCDB的工作原理确定，本申请实施例不做详述。

为了方便后续查询或筛选所需目标日志，在存储生成的日志过程中，也可以直接按照预设单位时长进行日志分割存储，即按照日志的生成时间，将每一个预设单位时长内的日志写入一个日志文件，以预设单位时长是一天为例进行说明，可以将每天生成的日志写入一个日志文件等，后续可以直接从多个日志文件中，筛选某一天或多天的日志文件为待上报日志文件。

应该理解的是，对于上文基于WCDB移动数据库架构的数据库设计阶段，属于整个客户端日志处理方案的准备阶段，预先设计好数据表结构，创建针对目标客户端的数据库后，可以按照本申请提出的客户端日志处理方法，实现日志采集、回捞等处理，在每一次处理时，不需要重新设计数据库。

步骤S32，获取日志的生成时间与当前时间之间的时间差，将时间差确定为相应所述日志的存储时长；

步骤S33，检测日志的存储时长是否超过预设有效时长，若是，进入步骤S34；若否，可以继续检测。

步骤S34，删除超过预设有效时长的存储时长所对应存储的日志。

可见，本申请实施例对数据库存储的日志配置了淘汰策略，使得存储的日志具有时效性，一旦日志的存储时长超过预设有效时长，可以直接删除该日志，从而节省日志数据对存储空间的占用，也有助于提高后续对目标日志的筛选速度。

需要说明，本申请对上述预设有效时长的数值不做限制，可视情况而定。示例性的，该预设有效时长可以为三天，也就是说，数据库存储的日志最长可以存储三天，意味着数据库存储的是最近三天内的日志数据，实现了对数据库中日志数据量的有限控制，保证了日志读写速度。

在实际应用中，对于本申请实施例提出的数据库的淘汰策略，可以根据场景需求进行触发，清理数据库中过期日志，即存储时长超过预设有效时长的日志，并不需要实时执行，本申请对此不做限制。

在本申请提出的又一些实施例中，为了可靠控制数据库存储的有效的日志数据量，本申请还可以对数据库存储的日志数据量设置一个数据量阈值，如200MB等，本申请对该数据量阈值的数值大小不做限制，可视情况而定。这样，在数据库存储的日志数据量超过该数据量阈值的情况下，可以按照日志的生成时间早晚顺序，删除超过数据量阈值的日志。

基于此，本申请目标客户端可以周期性或实时统计存储日志的数据量，检测该数据量是否达到数据量阈值，若达到，按照日志的生成时间从早到晚的顺序，删除超过数据量阈值的日志，即一日志的生成时间排序，从时间最早开始向后依次删除日志，直至剩余存储的日志数据量小于该数据量阈值，该过程可以在目标客户端运行过程中，调用后台线程执行，本申请不做详述。

参照图7，为本申请提出的客户端日志处理方法的又一可选示例的流程示意图，本实施例可以由后台维护人员即日志分析人员使用的终端设备执行，为了区别上述目标设备，本申请可以将执行本实施例的客户端日志处理方法的终端设备记为日志分析设备，具体设备类型可以依据场景需求确定，如图7所示，该方法可以包括：

步骤S41，输出日志回捞页面；

在实际应用中，日志平台获得针对目标客户端的异常检测请求后，需要获取该目标客户端的相应目标日志，用以分析确定导致目标客户端运行异常的原因，这种情况下，后台维护人员（下文称为技术人员）可以通过日志分析设备，登录日志平台，如启动日志分析设备中的浏览器后，可以输入日志平台的网址，进入日志平台的日志回捞页面，如图8所示，其可以指示技术人员输入相应的信息，如用户的设备标识UID、需要该用户使用的目标客户端上报日志的日志上报时间段，以及上报日志类型等信息，即在该日志回捞页面中输入日志筛选条件，本申请对其内容不做限制，可视情况而定。

结合图8所示的日志回捞页面示意图，对于需要技术人员在日志回捞页面输入的信息，可以通过触发选择按钮，弹出相应信息的多个待选项，以供技术人员依据实际情况下选择目标选项，也可以直接在相应的输入框中输入目标选项内容等，本申请对日志回捞页面的布局内容，以及技术人员如何对日志回捞页面的输入操作方法不做限制。

步骤S42，响应于对日志回捞页面的输入操作，得到待回捞日志对应的目标客户端的设备标识、待回捞日志的日志上报时间段和上报日志类型；

继上文描述，本申请可以通过选择输入操作或编辑输入操作等方式，确定待回捞日志的目标客户端运行的目标设备的设备标识UID，以及需要获取哪个时间区间内生成的什么类型的日志等，即得到待回捞日志的日志上报时间段和上报日志类型，根据需要，该日志上报时间段可以精确到分钟，与存储日志的生成时间的精度相同，本申请对此不做限制。

对于日志类型，结合上文实施例相应部分的分析，可以包括业务日志、应用日志、网络日志等，本申请可以依据目标客户端的异常问题内容，确定其中的一个或多个日志类型为上报日志类型，可视情况而定，并不局限于图8所示的所有日志这一内容的上报日志类型。

步骤S43，响应于在日志回捞页面输入的确认回捞操作，生成针对目标客户端的日志上报指令；

技术人员确定输入的设备标识、日志上报时间段和上报日志类型等信息没有错误后，可以点击如“查询”等功能按钮，完成对输入信息的确认回捞操作，日志分析设备检测到这一操作后，可以生成包含输入的设备标识、日志上报时间段和上报日志类型等信息的日志上报指令。

在一些实施例中，若技术人员并未重新输入待上报日志的相关信息，本申请可以直接结合设备标识，利用默认的日志上报时间段和默认上报日志类型，如图8所示，构成日志上报指令。需要说明，该默认的日志上报时间段和默认上报日志类型包括但并不局限于图8所示的相应内容，可以依据场景需求进行适应性调整。

步骤S44，利用设备标识，通过长连接通信方式，将日志上报指令下发至运行目标客户端的目标设备；

由于设备标识具有唯一特性，因此，日志分析设备可以据此确定从哪个设备获取所需目标日志，之后，可以采用长连接通信方式，建立与具有该设备标识的目标设备之间的长连接通信通道，将生成的日志上报指令发送至该目标设备后，目标设备可以按照上文实施例描述的方式，上报多个待上报日志文件各自的日志加密压缩文件，实现过程本申请不做赘述。其中，为了方便查询日志数据，待上报日志文件可以是文本格式（如txt格式）的文件。

其中，对于日志分析设备生成的日志上报指令，可以采用json格式文件发送至日志服务器，该json格式文件包含上述确定的设备标识、日志上报时间段和上报日志类型这三个参数，当然，根据应用需求，其还可以包括其他字段内容，本申请不做一一举例。日志服务器接收到日志上报指令后，可以依据其包含的设备标识，将其转发至目标设备。

在如上文描述的日志上报指令传输过程中，若日志上报指令发送至目标设备时，该目标设备中的目标客户端处于运行状态，目标客户端可以反馈ack消息（即消息接收确认），通知日志服务器目标客户端成功接收到日志上报指令；若目标客户端未被启动，目标客户端无法接收到该日志上报指令，该日志上报指令可以保留在日志服务器中，这样，在用户启动目标客户端后，与日志服务器建立长连接通信通道后，日志服务器可以重新将该日志上报指令发送至目标设备。

步骤S45，在日志回捞页面输出多个待上报日志文件各自的日志属性信息；

结合上文从目标设备的目标客户端侧描述的客户端日志处理方法，目标客户端响应日志上报指令，可以得到的多个待上报日志文件，并将这多个待上报日志文件上报至日志服务器，等待日志分析设备下载查阅。

其中，为了能够使技术人员了解本次日志回捞进度，日志服务器接收到目标设备上报的多个待上报日志后，可以将多个待上报日志文件各自的日志属性信息，如相应待上报日志文件的用户标识、所包含日志的最新生成时间、文件上报时间、文件名称、所包含日志类型之中的一个或多个，推送至目标分析设备的日志回捞页面展示，以供技术人员查看目标客户端上报的什么日志。

需要说明，本申请对日志属性信息的内容及其输出方式不做限制，包括但并不局限于图8所示的内容，可以依据场景需求进行适应性调整，本申请不做详述。

步骤S46，响应于对输出的任一待上报日志文件的确认下载操作，向日志服务器发送针对所确定的目标上报日志文件的查看请求；

技术人员通过展示的各待上报日志文件的日志属性信息，从中选择当前需要查看哪个日志文件，记为目标上报日志文件，之后，可以点击该目标日志文件对应的“下载”按钮，以使日志分析设备响应技术人员的确认下载操作，生成针对该目标上报日志文件的查看请求，该查看请求可以携带该目标上报日志文件的日志属性信息，以使得日志服务器可以据此筛选相应的日志文件反馈。

步骤S47，接收日志服务器响应查看请求所反馈的目标上报日志文件；

步骤S48，输出目标上报日志文件包含的日志。

结合上文实施例相应部分的描述，日志服务器接收到日志上报时间段内生成的目标日志，其以多个待上报日志文件的形式存在，如目标客户端最近三天生成的日志，每一天生成的日志构成一个日志文件，技术人员需要进行日志分析时，可以直接选择本次查看哪一天的日志文件，下载相应的待上报日志文件进行展示，即输出文本格式的目标上报日志文件，查看其包含的日志数据，结合经验分析定位异常问题原因，日志分析实现过程本申请不做详述。

可见，在需要通过日志分析，确定导致目标客户端运行异常的原因的情况下，技术人员可以通过可视化的网页，直接输入日志筛选条件，依次通知目标客户端上报相应的目标日志，该目标日志上报过程对用户来说是无感知的，并不会对用户造成干扰，且采用分片上报目标日志的方式，提高了日志上报成功率和可靠性。之后，技术人员可以依据日志分析需求，从日志回捞页面中直接选择要查看的日志文件进行下载，无需直接下载全部目标日志，减小了对日志分析设备的存储空间的占用，降低对日志分析设备的性能影响。

参照图9，为本申请提出的客户端日志处理装置的一可选示例的结构示意图，该装置可以从普通用户使用客户端的终端设备侧进行描述，如图9所示，该装置可以包括：日志上报指令获取模块31，用于获取针对目标客户端的日志上报指令；所述日志上报指令包括设备标识、日志上报时间段和上报日志类型；

目标日志筛选模块32，用于响应所述日志上报指令，从与所述设备标识关联存储的日志中，筛选与所述日志上报时间段和所述上报日志类型相匹配的目标日志；

目标日志分割处理模块33，用于若所述日志上报时间段大于预设单位时长，利用所述目标日志的生成时间，按照所述预设单位时长，对所述目标日志进行分割处理，得到多个待上报日志文件；

日志文件上报模块34，用于将所述多个待上报日志文件上报至日志服务器。

可选的，日志文件上报模块34可以包括：

加密压缩单元，用于对所述多个待上报日志文件分别进行加密压缩处理，得到相应的日志加密压缩文件；

上报单元，用于将得到的多个所述日志加密压缩文件上报至日志服务器；

上报检测单元，用于检测所述日志加密压缩文件是否上报成功；

删除单元，用于上报检测单元的检测结果为存在上报成功的所述日志加密压缩文件的情况下，删除本地存储的该日志加密压缩文件对应的日志；

上报次数统计单元，用于上报检测单元的检测结果为存在上报失败的所述日志加密压缩文件的情况下，检测该日志加密压缩文件的上报失败次数小于上报次数阈值，触发加密压缩单元重新向所述日志服务器上报该日志加密压缩文件；

上报失败提示单元，用于检测到该日志加密压缩文件的上报失败次数不小于上报次数阈值，中断对该日志加密压缩文件的上报，输出针对该日志加密压缩文件的上报失败提示信息。

可选的，加密压缩单元可以包括：

对称加密单元，用于采用对称加密算法，对每一个所述待上报日志文件进行加密压缩处理，得到相应的日志加密压缩文件。

在本申请提出的又一些实施例中，上述装置还可以包括：

日志记录模块，用于基于WCDB移动数据库架构，将目标客户端运行过程中产生的各种数据，存储为相应类型的日志，并记录所述日志的生成时间；

存储时长确定模块，用于获取所述日志的生成时间与当前时间之间的时间差，将所述时间差确定为相应所述日志的存储时长；

存储时长检测模块，用于检测所述日志的存储时长是否超过预设有效时长；

第一删除模块，用于在存储时长检测模块的检测结果为是的情况下，删除超过所述预设有效时长的所述存储时长所对应存储的所述日志。

可选的，该装置还可以包括：

日志数据量统计模块，用于统计已存储日志的数据量；

日志数据量检测模块，用于检测所述数据量是否达到数据量阈值；

第二删除模块，用于在日志数据量检测模块的检测结果为达到的情况下，按照所述日志的生成时间从早到晚的顺序，删除超过所述数据量阈值的日志。

参照图10，为本申请提出的客户端日志处理装置的又一可选示例的结构示意图，该装置可以包括：

日志回捞页面输出模块41，用于输出日志回捞页面；

信息获得模块42，用于响应于对所述日志回捞页面的输入操作，得到待回捞日志对应的目标客户端的设备标识、待回捞日志的日志上报时间段和上报日志类型；

日志上报指令生成模块43，用于响应于在所述日志回捞页面输入的确认回捞操作，生成针对所述目标客户端的日志上报指令；所述日志上报指令包含有所述设备标识、所述日志上报时间段和所述上报日志类型；

日志生成指令下发模块44，用于利用所述设备标识，通过长连接通信方式，将所述日志上报指令下发至运行所述目标客户端的目标设备。

可选的，该装置还可以包括：

日志属性信息输出模块，用于在所述日志回捞页面输出多个待上报日志文件各自的日志属性信息；

其中，所述多个待上报日志文件是所述目标客户端响应所述日志上报指令得到的；所述日志属性信息包括相应待上报日志文件的用户标识、所包含日志的最新生成时间、文件上报时间、文件名称、所包含日志类型之中的一个或多个；

查看请求发送模块，用于响应于对输出的任一所述待上报日志文件的确认下载操作，向日志服务器发送针对所确定的目标上报日志文件的查看请求；

目标上报日志文件接收模块，用于接收所述日志服务器响应所述查看请求所反馈的所述目标上报日志文件；

日志输出模块，用于输出所述目标上报日志文件包含的日志。需要说明的是，关于上述各装置实施例中的各种模块、单元等，均可以作为程序模块存储在存储器中，由处理器执行存储在存储器中的上述程序模块，以实现相应的功能，关于各程序模块及其组合所实现的功能，以及达到的技术效果，可以参照上述方法实施例相应部分的描述，本实施例不再赘述。

本申请还提供了一种存储介质，其上可以存储计算机程序，该计算机程序可以被处理器调用并加载，以实现上述实施例描述的客户端日志处理方法的各个步骤。

另外，需要说明的是，关于上述各实施例中，诸如第一、第二等之类的关系术语仅仅用来将一个操作、单元或模块与另一个操作、单元或模块区分开来，而不一定要求或者暗示这些单元、操作或模块之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法或者系统中还存在另外的相同要素。

本说明书中各个实施例采用递进或并列的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置、计算机设备而言，由于其与实施例公开的方法对应，所以描述的比较简单，相关之处参见方法部分说明即可。

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

Claims (10)

1.一种客户端日志处理方法，其特征在于，所述方法包括：

获取针对目标客户端的日志上报指令；所述日志上报指令包括设备标识、日志上报时间段和上报日志类型；

响应所述日志上报指令，从与所述设备标识关联存储的日志中，筛选与所述日志上报时间段和所述上报日志类型相匹配的目标日志；

若所述日志上报时间段大于预设单位时长，利用所述目标日志的生成时间，按照所述预设单位时长，对所述目标日志进行分割处理，得到多个待上报日志文件；

将所述多个待上报日志文件上报至日志服务器。

2.根据权利要求1所述的方法，其特征在于，所述将所述多个待上报日志文件上报至日志服务器，包括：

对所述多个待上报日志文件分别进行加密压缩处理，得到相应的日志加密压缩文件；

将得到的多个所述日志加密压缩文件上报至日志服务器；

检测所述日志加密压缩文件是否上报成功；

若存在上报成功的所述日志加密压缩文件，删除本地存储的该日志加密压缩文件对应的日志；

若存在上报失败的所述日志加密压缩文件，检测到该日志加密压缩文件的上报失败次数小于上报次数阈值，重新向所述日志服务器上报该日志加密压缩文件；

检测到该日志加密压缩文件的上报失败次数不小于上报次数阈值，中断对该日志加密压缩文件的上报，输出针对该日志加密压缩文件的上报失败提示信息。

3.根据权利要求2所述的方法，其特征在于，所述对所述多个待上报日志文件分别进行加密压缩处理，得到相应的日志加密压缩文件，包括：

采用对称加密算法，对每一个所述待上报日志文件进行加密压缩处理，得到相应的日志加密压缩文件。

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

基于WCDB移动数据库架构，将目标客户端运行过程中产生的各种数据，存储为相应类型的日志，并记录所述日志的生成时间；

获取所述日志的生成时间与当前时间之间的时间差，将所述时间差确定为相应所述日志的存储时长；

检测所述日志的存储时长是否超过预设有效时长；

若是，删除超过所述预设有效时长的所述存储时长所对应存储的所述日志。

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

统计已存储日志的数据量；

检测所述数据量是否达到数据量阈值；

若达到，按照所述日志的生成时间从早到晚的顺序，删除超过所述数据量阈值的日志。

6.一种客户端日志处理方法，其特征在于，所述方法包括：

输出日志回捞页面；

响应于对所述日志回捞页面的输入操作，得到待回捞日志对应的目标客户端的设备标识、待回捞日志的日志上报时间段和上报日志类型；

响应于在所述日志回捞页面输入的确认回捞操作，生成针对所述目标客户端的日志上报指令；所述日志上报指令包含有所述设备标识、所述日志上报时间段和所述上报日志类型；

利用所述设备标识，通过长连接通信方式，将所述日志上报指令下发至运行所述目标客户端的目标设备。

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

在所述日志回捞页面输出多个待上报日志文件各自的日志属性信息；其中，所述多个待上报日志文件是所述目标客户端响应所述日志上报指令得到的；所述日志属性信息包括相应待上报日志文件的用户标识、所包含日志的最新生成时间、文件上报时间、文件名称、所包含日志类型之中的一个或多个；

响应于对输出的任一所述待上报日志文件的确认下载操作，向日志服务器发送针对所确定的目标上报日志文件的查看请求；

接收所述日志服务器响应所述查看请求所反馈的所述目标上报日志文件；

输出所述目标上报日志文件包含的日志。

8.一种客户端日志处理装置，其特征在于，所述装置包括：

日志上报指令获取模块，用于获取针对目标客户端的日志上报指令；所述日志上报指令包括设备标识、日志上报时间段和上报日志类型；

目标日志筛选模块，用于响应所述日志上报指令，从与所述设备标识关联存储的日志中，筛选与所述日志上报时间段和所述上报日志类型相匹配的目标日志；

目标日志分割处理模块，用于若所述日志上报时间段大于预设单位时长，利用所述目标日志的生成时间，按照所述预设单位时长，对所述目标日志进行分割处理，得到多个待上报日志文件；

日志文件上报模块，用于将所述多个待上报日志文件上报至日志服务器。

9.一种客户端日志处理装置，其特征在于，所述装置包括：

日志回捞页面输出模块，用于输出日志回捞页面；

信息获得模块，用于响应于对所述日志回捞页面的输入操作，得到待回捞日志对应的目标客户端的设备标识、待回捞日志的日志上报时间段和上报日志类型；

日志上报指令生成模块，用于响应于在所述日志回捞页面输入的确认回捞操作，生成针对所述目标客户端的日志上报指令；所述日志上报指令包含有所述设备标识、所述日志上报时间段和所述上报日志类型；

日志生成指令下发模块，用于利用所述设备标识，通过长连接通信方式，将所述日志上报指令下发至运行所述目标客户端的目标设备。

10.一种计算机设备，其特征在于，所述计算机设备包括：至少一个存储器和至少一个处理器，其中：

所述存储器，用于存储如权利要求1-5任一项所述的客户端日志处理方法的第一程序，或存储如权利要求6或7所述的客户端日志处理方法的第二程序；

所述处理器，用于加载并执行所述存储器存储的所述第一程序，以实现如权利要求1-5任一项所述的客户端日志处理方法；或者加载并执行所述存储器存储的所述第二程序，以实现如权利要求6或7所述的客户端日志处理方法。

Images