一种日志收集方法及装置与流程

本发明实施例涉及互联网技术领域，具体涉及一种日志收集方法及装置。

背景技术：

随着智能机器人的功能不断完善，其智能化程度不断提高，越来越多的智能机器人开始进入普通家庭，例如，扫地机器人、看家机器人等等，大大方便了人们的生活。然而，为了了解智能机器人的运行状态，及时发现运行过程中存在的故障和问题，需要收集智能机器人运行过程中的日志信息，帮助分析智能机器人的功能是否正确完成，以及各种参数指标的情况。

目前的智能机器人无法向手机，平板等具有显示屏幕的智能终端一样方便触摸，或者像穿戴型智能设备一样，用户可以直接触发日志的收集。目前市面上的智能机器人触发逻辑单一，日志收集不全，结果不稳定，从而导致无法有效地通过日志对功能进行诊断。同时，只能被动的等程序崩溃，才提交该段异常信息，而一旦程序奔溃后系统都会自动清理，启动操作，程序能完成日志收集工作的概率很低。

在实现本发明实施例的过程中，发明人发现现有的智能机器人的日志收集方法仅在程序奔溃后触发日志收集，导致日志收集不全，同时无法按需主动收集日志。

技术实现要素：

由于现有的智能机器人的日志收集方法仅在程序奔溃后触发日志收集，导致日志收集不全，同时无法按需主动收集日志的问题，本发明提出一种日志收集方法及装置。

第一方面，本发明实施例提出一种日志收集方法，包括：

判断是否对终端应用服务的对应日志进行收集；

若需要进行收集，则确定进行收集的目标应用服务分别对应日志收集的输出级别；

向终端发送收集预设输出级别对应的日志收集指令；

分别接收所述终端发送的所述目标应用服务的所述预设输出级别的对应日志。

优选地，所述判断是否对终端应用服务的对应日志进行收集，进一步包括：

所述服务器根据当前时间、当前地点、当前网络情况和服务器内存情况，判断是否对终端所安装的应用服务的对应日志进行收集。

优选地，所述确定进行收集的目标应用服务分别对应日志收集的输出级别，进一步包括：

根据日志状态和故障修复状态，确定目标应用服务分别对应的日志收集的输出级别。

优选地，所述分别接收所述终端发送的所述目标应用服务的所述预设输出级别的对应日志，进一步包括：

分片接收所述终端发送的所述目标应用服务的所述预设输出级别的对应日志。

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

根据预设文件地址，将所述预设输出级别对应的日志存储至所述预设文件中。

优选地，根据预设文件地址，所述方法还包括：

对所述预设文件中存储的日志进行分析，生成分析结果并显示。

由上述技术方案可知，本发明实施例提供的日志收集方法通过服务器判断确定是否进行日志收集，能够实现服务器的主动收集，避免了日志收集触发单一的问题；通过输出级别收集不同的日志，能够满足用户按需收集的要求，同时避免了日志收集不全的问题。

第二方面，本发明实施例还提出一种日志收集装置，包括：

日志收集确定模块，用于判断是否对终端应用服务的对应日志进行收集；

输出级别确定模块，用于若需要进行收集，则确定进行收集的目标应用服务分别对应日志收集的输出级别；

指令发送模块，用于向终端发送收集预设输出级别对应的日志收集指令；

日志接收模块，用于分别接收所述终端发送的所述目标应用服务的所述预设输出级别的对应日志。

优选地，所述日志收集确定模块进一步用于根据当前时间、当前地点、当前网络情况和服务器内存情况，判断是否对终端所安装的应用服务的对应日志进行收集。

优选地，所述输出级别确定模块进一步用于根据日志状态和故障修复状态，确定目标应用服务分别对应的日志收集的输出级别。

优选地，所述日志接收模块进一步用于分片接收所述终端发送的所述目标应用服务的所述预设输出级别的对应日志。

优选地，所述装置还包括：

存储模块，用于根据预设文件地址，将所述预设输出级别对应的日志存储至所述预设文件中。

优选地，所述装置还包括：

日志分析模块，用于对所述预设文件中存储的日志进行分析，生成分析结果并显示。

由上述技术方案可知，本发明实施例提供的日志收集装置通过服务器判断确定是否进行日志收集，能够实现服务器的主动收集，避免了日志收集触发单一的问题；通过输出级别收集不同的日志，能够满足用户按需收集的要求，同时避免了日志收集不全的问题。

附图说明

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

图1为本发明一实施例提供的一种日志收集方法的流程示意图；

图2为本发明另一实施例提供的一种日志收集方法的流程示意图；

图3为本发明另一实施例提供的一种日志收集方法的流程示意图；

图4为本发明一实施例提供的一种日志收集装置的结构示意图。

具体实施方式

下面结合附图，对发明的具体实施方式作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本发明的保护范围。

图1示出了本发明一实施例提供的一种日志收集方法的流程示意图，包括：

S101、判断是否对终端应用服务的对应日志进行收集；

其中，服务器可根据判定规则，主动对终端应用服务的对应日志进行日志收集；所述判定规则可以为：根据智能机器人的日常工作时间表，选择其空闲时间进行日志收集，以不影响智能机器人的日常工作效率；或者，根据服务器当前的网络情况，当网络速度较快时进行日志收集；或者，根据服务器当前的内存情况，当空闲内存大于阈值时，进行日志收集。

或者，服务器也可以根据终端发送的监控文件确定是否对终端各个应用服务的日志进行收集。具体地，在终端一侧，包括对各个应用服务状态进行监控的监测服务；所述监控服务获取各个应用服务的状态，并根据预设时间间隔向服务器上传监控文件，所述监控文件中包括各个应用服务的运行状态。具体地，在终端一侧，包括多个应用服务，每个应用服务都对应一个或多个日志文件。

通过判断确定是否对终端应用服务的对应日志进行日志收集，能够对日志收集的开关进行动态控制。这样可以灵活的控制日志的输出与关闭，使得在没有额外性能消耗的同时，可以收集完整的日志数据，以供后续进行分析；同时通过服务端主动发起收集指令，智能分析判断收集，打破传统被动崩溃收集的模式，使得收集方式灵活多变，同时对智能机器人的故障诊断更全面。

S102、若需要进行收集，则确定进行收集的目标应用服务分别对应日志收集的输出级别；

具体地，根据预设规则判断并确定各个应用服务对应的日志收集的输出级别。

举例来说，所述预设规则可以为故障的严重程度，例如轻度故障、中度故障和重度故障；或者，故障的修复时间，例如1分钟、10分钟、30分钟、3小时和2天；或者，可根据用户的具体要求预先设定。

其中，所述输出级别为每个日志文件对应的不同输出要求，表示了对应应用服务运行时产生的异常级别。

举例来说，可以将输出级别从低到高分别设置为：i(infor，通知)、v(verbose，显示详细信息)、d(debug，可修复的)、w(warn，警告)和e(error，故障)。其中，i表示仅通知用户发生错误的日志，异常级别最低，v表示向用户发送错误的详细信息日志，d表示告知用户为可修复的错误日志，w表示警告用户需注意的错误日志，e表示向用户发送故障日志，异常级别最高。

或者，所述输出级别可用1级-5级表示，输出级别为1级表示重要功能模块的日志和出现故障的功能模块的日志，需实时上传的日志；输出级别为2级表示次要功能模块的日志，根据服务器的指令进行上传；输出级别为3级表示普通功能模块的日志，根据服务器的指令进行上传。当日志文件M的输出级别为2级，且日志文件M对应的功能模块未出现故障，则当服务器向智能机器人发送上传2级日志时，才向服务器上传该日志文件M。

或者，可根据用户的具体要求定义所述输出级别。

具体地，在智能机器人端，需要进行如下步骤：

A1、在智能机器人端创建安装于终端的监测服务对象，每个应用服务在各应用服务的主入口处，根据监测服务对象分别获取到监测服务对象的实例，进而判断是否对该应用服务进行日志收集；

A2、对象初始化，各应用服务分别获取到该监测服务对象实例之后各自调用初始化方法进行初始化；

其中，步骤A2中各应用服务分别接收了一个监测服务对象实例，根据检测服务对象实例中定义的允许收集开关LOG_ENABLED和调试标记DEBUG属性，控制自身记录的日志是否应该输出到终端的控制台。所述允许收集开关和所述调试标记均为boolean型数据，所述允许收集开关LOG_ENABLED表示智能机器人端是否允许服务器收集日志的开关，默认情况下为关闭状态，以防止恶意程序的非法收集；当服务器判断确定需要进行日志收集时，所述允许收集开关将更改为打开状态；所述调试标记为调试过程中为了方便调试接入更为便利而设置的标记。同时检测服务对象实例还注册了一个自定义的广播接收器，该广播接收器负责响应命令，控制日志开关，并打开收集日志信息的服务，用于对日志收集和上传。

A3、日志输出，各应用服务用初始化后的监测服务对象实例调用输出级别方法，往控制台输出不同级别的日志信息；其中，输出级别方法可由用户根据具体要求自定义。

其中，步骤A3增加了新的功能封装，增强了原生系统的方案，使其使用时更加便利，但是却没有改变原Google的代码设计风格，让程序调用时无障碍。而且步骤A3中的定义有一个操作的日志级别，分别为最小级别minLevel和最大级别maxLevel，还有一个强制输出参数，可突破步骤A2中的限制。具体地，当步骤A3中设置强制输出时，则无论步骤A2的限制条件如何，均按照步骤A3中最小级别和最大级别进行输出。举例来说，当强制输出最小级别为2，最大级别为4时，则将输出级别为2、3、4的日志上传至服务器。

举例来说，

B1、应用服务在主入口处，通过LogCat.getInstance(String tag)获取到该监测服务对象的实例，日志收集必须放在入口处，最佳的实现方案是放在自定义的Application中，该监测服务对象的实例化尽可能的靠前运行。每一个LogCat实例化时有指定的tag便于区分过滤日志；

B2、获取到该监测服务对象实例之后调用init(Context context)方法对该对象实例进行初始化。这步的初始化是为了对创建的LogCat对象做默认配置，内部还有控制和反控制机制，这样的封装让内部复杂的机制调用起来变得简单简洁。

B3、调用logCat.i(String className,String msg)和logCat.i(String className,String msg,boolean isOut,String fileName)等，对应相应的日志级别，符合Android本身定义的日志级别规则，isOut参数可突破整体日志开关机制，fileName指定保存的日志的本地文件，灵活多变。

通过对日志收集进行级别控制，能够解决庞大的日志造成的分析困难；通过指定级别的范围进行上传，能够只分析用户关心的日志，减少分析时间，快速定位故障和问题。

S103、向终端发送收集预设输出级别对应的日志收集指令；

其中，所述预设输出级别可以根据用户的要求预先设置。

具体地，服务器可以通过预留的后台端口，主动控制开启收集服务；开启收集服务后，服务器向终端发送收集预设输出级别对应的日志的收集指令。

其中，所述收集指令中包括日志的预设输出级别。

举例来说，服务器向终端发送收集输出级别小于3的日志，则终端需要将输出级别为1和2的日志上传至服务器。其中，所述终端可以为智能机器人。

S104、分别接收所述终端发送的所述目标应用服务的所述预设输出级别的对应日志。

具体地，服务器向终端发送收集所述预设输出级别的对应日志的收集指令后，在终端一侧，具体的步骤包括：

首先打开允许收集开关；

然后根据收集指令中的日志的输出级别，查找所述输出级别对应的日志；

最后将所述输出级别对应的日志打包上传至所述服务器。

在服务器一侧，终端将打包的日志上传后，接收所述预设输出级别对应的日志。

本实施例通过服务器判断确定是否进行日志收集，能够实现服务器的主动收集，避免了日志收集触发单一的问题；通过输出级别收集不同的日志，能够满足用户按需收集的要求，同时避免了日志收集不全的问题。

进一步地，在上述方法实施例的基础上，S101进一步包括：

所述服务器根据当前时间、当前地点、当前网络情况和服务器内存情况，判断是否对终端所安装的应用服务的对应日志进行收集。

具体地，可采用网络长链接保活技术、心跳发送检测技术以及综合系统情况分析决策，确定是否对终端所安装的应用服务的日志进行收集。其中，所述网络长链接保活技术表示维持网络长久而稳定的连接；所述心跳发送检测技术表示间隔预设时间后向服务器发送通知，告知正在运行；所述综合系统情况分析决策表示总和考虑多个因素进行分析，例如根据当前的时间、当前地点、当前网络情况、当前交互情况、服务器内存情况、整体系统运行情况等各种因素结合判断是否需要开始智能收集日志。

举例来说，服务器选择一种收集的触发方式，如：调用startSave方法，服务端发送指令开启诊断功能，具体收集命令的服务在另一个独立进程中，该进程负责日志收集和打包上传，不参与其他的业务，保证安全性。

通过当前具体参数判断是否进行日志收集，能够结合当前的具体情况进行日志收集，以不影响智能机器人的日常工作，且提高日志收集的效率。

进一步地，在上述方法实施例的基础上，S102进一步包括：

根据日志状态和故障修复状态，确定目标应用服务分别对应的日志收集的输出级别。

具体地，所述日志状态是指日志当前的操作状态，例如是否正在更新；所述故障修改状态是指日志记录的应用程序发生故障后的状态，例如是否已修复。

当日志处于更新状态时，可将其输出级别设置为较低级别，以防止日志更新过程中上传日志导致的数据不全问题。

当日志记录的应用程序发生故障后已经修复，则可将该日志设置为次高级别，以尽早上传服务器；当日志记录的应用程序发生故障后未修复，则可将该日志设置为最高级别，以及时上传服务器。

进一步地，在上述方法实施例的基础上，S104进一步包括：

分片接收所述终端发送的所述目标应用服务的所述预设输出级别的对应日志。

采用日志分片技术，能够提高日志上传的成功率，减少带宽消耗，同时减少网络传输的压力。

具体地，智能机器人在日志上传时可压缩后再分片上传。

进一步地，在上述方法实施例的基础上，如图2所示，所述方法包括：

S201、判断是否对终端应用服务的对应日志进行收集；

S202、若需要进行收集，则确定进行收集的目标应用服务分别对应日志收集的输出级别；

S203、向终端发送收集预设输出级别对应的日志收集指令；

S204、分别接收所述终端发送的所述目标应用服务的所述预设输出级别的对应日志。

S205、根据预设文件地址，将所述预设输出级别对应的日志存储至所述预设文件中。

其中，S201-S204与图1对应的实施例中的S101-S104对应。

所述预设文件地址可根据用户的具体要求预先设置。

具体地，S205中通过设置线程池和文件安全锁控制，保证文件正确、安全并高效的写入预设文件中。

更进一步地，在上述方法实施例的基础上，如图3所示，所述方法包括：

S301、判断是否对终端应用服务的对应日志进行收集；

S402、若需要进行收集，则确定进行收集的目标应用服务分别对应日志收集的输出级别；

S303、向终端发送收集预设输出级别对应的日志收集指令；

S304、分别接收所述终端发送的所述目标应用服务的所述预设输出级别的对应日志。

S305、根据预设文件地址，将所述预设输出级别对应的日志存储至所述预设文件中。

S306、对所述预设文件中存储的日志进行分析，生成分析结果并显示。

其中，S301-S205与图2对应的实施例中的S201-S205对应。

具体地，S306中经过服务器的分析，会生成不同的错误代码，并做出标识，以供用户在后台清晰的预览该数据的集合。

举例来说，问题标识可以包括：不解决，无关紧要，已解决，当前无法解决，推迟解决，专项处理。

通过对日志进行分析，能够生成完整而直观的功能诊断结果，对于开发者可以按需进行响应应用服务的管理。

本实施例对整体的结构框架进行职责划分，采用动态方式控制日志开关，并用独立进程Service logcat命令收集日志信息分析诊断功能。即由终端监控各系统服务的工作状态，一旦检测到有异常状态时上报给服务器，则服务器主动开始统计该终端相应的异常模块对应的异常日志，并统一将异常日志转发到日志服务器生成错误码，供开发者进行功能诊断。

本实施例可采用google Android系统的Logcat命令集，通过结合java线程池、多线程技术、多进程文件安全写入技术、文件分片、和合成技术，使得程序日志收集和上传形成了一个完美的闭环，具有信息收集全、程序运行稳定、性能消耗低和智能收集的优势，而且还支持响应远端收集指令，具有安全性高、扩展性强、操作性简单的优势和技术拓展，以及不断创新的进步性意义。

图2示出了本发明一实施例提供的一种日志收集装置的结构示意图，所述装置包括：日志收集确定模块21、输出级别确定模块22、指令发送模块23和日志接收模块24；其中，

所述日志收集确定模块21用于判断是否对终端应用服务的对应日志进行收集；

所述输出级别确定模块22用于若需要进行收集，则确定进行收集的目标应用服务分别对应日志收集的输出级别；

所述指令发送模块23用于向终端发送收集预设输出级别对应的日志收集指令；

所述日志接收模块24用于分别接收所述终端发送的所述目标应用服务的所述预设输出级别的对应日志。

具体地，所述日志收集确定模块21判断是否对终端应用服务的对应日志进行收集；所述输出级别确定模块22若需要进行收集，则确定进行收集的目标应用服务分别对应日志收集的输出级别；所述指令发送模块23向终端发送收集预设输出级别对应的日志收集指令；所述日志接收模块24分别接收所述终端发送的所述目标应用服务的所述预设输出级别的对应日志。。

本实施例通过服务器判断确定是否进行日志收集，能够实现服务器的主动收集，避免了日志收集触发单一的问题；通过输出级别收集不同的日志，能够满足用户按需收集的要求，同时避免了日志收集不全的问题。

进一步地，在上述装置实施例的基础上，所述日志收集确定模块21进一步用于根据当前时间、当前地点、当前网络情况和服务器内存情况，判断是否对终端所安装的应用服务的对应日志进行收集。

进一步地，在上述装置实施例的基础上，所述输出级别确定模块22进一步用于根据日志状态和故障修复状态，确定目标应用服务分别对应的日志收集的输出级别。

进一步地，在上述装置实施例的基础上，所述日志接收模块24进一步用于分片接收所述终端发送的所述目标应用服务的所述预设输出级别的对应日志。

进一步地，在上述装置实施例的基础上，所述装置还包括：

存储模块25，用于根据预设文件地址，将所述输出级别对应的日志存储至所述预设文件中。

进一步地，在上述装置实施例的基础上，所述装置还包括：

日志分析模块26，用于对所述预设文件中存储的日志进行分析，生成分析结果并显示。

本实施例所述的日志收集装置可以用于执行上述方法实施例，其原理和技术效果类似，此处不再赘述。

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

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

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