日志追踪方法、装置、电子设备及存储介质与流程

本公开涉及计算机应用领域，尤其是一种日志追踪方法、装置、电子设备及存储介质。

背景技术

在互联网开发中，特别是在移动应用程序开发中，经常遇到系统碎片化造成移动应用程序崩溃的严重问题，例如，移动应用程序被系统弹框强制关闭。或者，即使将在模拟器上运行良好的移动应用程序安装到用户的手机上使用时，由于复杂的网络环境也会存在系统崩溃问题，极大影响了移动应用程序的系统稳定性。

相关技术中，移动应用程序在安卓系统正常运行时，都会记录日志信息，如果遇到系统奔溃等异常问题，技术开发人员可以通过分析日志信息，查找和解决安卓系统当前存在的问题。然而，现有的日志信息文件存在大量无用的日志信息，不仅加大了技术开发人员的工作量，而且使得出现的奔溃问题无法得到及时解决，影响移动应用程序在安卓系统中的稳定性，从而影响用户对移动程序的体验感。

技术实现要素：

为克服相关技术中存在的问题，本公开提供一种日志追踪方法、装置、电子设备及存储介质。

根据本公开实施例的第一方面，提供一种日志追踪方法，包括：

在运行状态下获取目标类的原始配置文件；

将所述原始配置文件替换为预设的目标配置文件，其中，所述目标配置文件包括追踪机制，所述追踪机制用于收集所述目标类的运行属性；

根据所述运行属性生成追踪日志。

可选地，所述目标类的原始配置文件包括活动管理类、测试基类、包管理类和视图根。

可选地，在运行状态下获取目标类的原始配置文件包括：

获取目标类的原始配置文件的属性信息；

根据所述属性信息获取所述原始配置文件的路径；

根据所述路径获取所述原始配置文件。

可选地，将所述原始配置文件替换为预设的目标配置文件包括：

获取所述目标配置文件中的组件和代码块；

采用java反射机制将所述活动管理类、所述测试基类和所述包管理类分别对应的数据包替换为所述组件；

对所述视根图注入所述代码块，改变所述视根图的变量。

可选地，根据所述运行属性生成追踪日志包括：

创建追踪日志表格；

扫描并读取所述目标类的运行属性；

将所述目标类的运行属性记录在所述追踪日志表格中，得到所述追踪日志。

可选地，将所述原始配置文件替换为预设的目标配置文件之后，所述日志追踪方法还包括：

在预设的排查信息表检测所述追踪日志是否存在一般报错信息；

若所述追踪日志存在所述一般报错信息，则自动修复所述一般报错信息；

若所述追踪日志不存在所述一般报错信息，则对所述追踪日志作标记处理。

可选地，根据所述运行属性生成追踪日志之后，日志追踪方法还包括：

在预设时间内，将所述标记处理过的所述追踪日志按照预设的通知方式发送给管理员终端。

根据本公开实施例的第二方面，提供一种日志追踪装置，包括：

获取单元，被配置为在运行状态下获取目标类的原始配置文件；

处理单元，被配置为将所述原始配置文件替换为预设的目标配置文件，其中，所述目标配置文件包括追踪机制，所述追踪机制用于收集所述目标类的运行属性；

执行单元，被配置为根据所述运行属性生成追踪日志。

可选地，所述目标类的原始配置文件包括活动管理类、测试基类、包管理类和视图根。

可选地，所述日志追踪装置还包括：

第一获取单元，被配置为获取目标类的原始配置文件的属性信息；

第一处理单元，被配置为根据所述属性信息获取所述原始配置文件的路径；

第一执行单元，被配置为根据所述路径获取所述原始配置文件。

可选地，所述日志追踪装置还包括：

第二获取单元，被配置为获取所述目标配置文件中的组件和代码块；

第二处理单元，被配置为采用java反射机制将所述活动管理类、所述测试基类和所述包管理类分别对应的数据包替换为所述组件；

第二执行单元，被配置为对所述视根图注入所述代码块，改变所述视根图的变量。

可选地，所述日志追踪装置还包括：

创建单元，被配置为创建追踪日志表格；

扫描单元，被配置为扫描并读取所述目标类的运行属性；

记录单元，被配置为将所述目标类的运行属性记录在所述追踪日志表格中，得到所述追踪日志。

可选地，所述日志追踪装置还包括：

检测单元，被配置为在预设的排查信息表检测所述追踪日志是否存在一般报错信息；

修复单元，被配置为若所述追踪日志存在所述一般报错信息，则自动修复所述一般报错信；

标记单元，被配置为若所述追踪日志不存在所述一般报错信息，则对所述追踪日志作标记处理。

可选地，所述日志追踪装置还包括：

发送单元，被配置为在预设时间内，将所述标记处理过的所述追踪日志按照预设的通知方式发送给管理员终端。

根据本公开实施例的第三方面，提供一种电子设备，包括处理器；用于存储处理器可执行指令的存储器；其中，所述处理器被配置为上述日志追踪方法的步骤。

根据本公开实施例的第四方面，提供一种非临时性计算机可读存储介质，当所述存储介质中的指令由移动终端的处理器执行时，使得移动终端能够执行上述日志追踪方法的步骤。

根据本申请公开实施例的第五方面，提供一种计算机程序产品，包括计算机程序代码，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，使所述计算机执行上述日志追踪方法的步骤。

本公开的实施例提供的技术方案可以包括以下有益效果：在运行状态下获取目标类的原始配置文件；将原始配置文件替换为预设的目标配置文件，其中，目标配置文件包括追踪机制，追踪机制用于收集目标类的运行属性；根据运行属性生成追踪日志。本公开通过将目标配置文件替换原始配置文件，使得目标配置文件根据运行属性生成追踪日志，实现了能够精准定位到移动应用系统的运行问题，以使系统管理员能及时发现并解决运行问题，从而提高移动应用系统的稳定性和用户对移动应用程序的体验感。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本公开的原理。

图1是根据一示例性实施例示出的一种日志追踪方法的流程图。

图2是根据一示例性实施例示出的获取原始配置文件的一种实施方式流程图。

图3是根据一示例性实施例示出的原始配置文件替换为预设的目标配置文件的一种实施方式流程图。

图4是根据一示例性实施例示出的生成追踪日志的一种实施方式流程图。

图5是根据一示例性实施例示出的处理追踪日志的的一种实施方式流程图。

图6是根据一示例性实施例示出的一种日志追踪装置框图。

图7是根据一示例性实施例示出的一种移动终端的框图。

图8是根据一示例性实施例示出的一种电子设备的框图。

具体实施方式

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

图1是根据一示例性实施例示出的一种日志追踪方法的流程图，如图1所示，日志追踪方法用于终端中，包括以下步骤：

s100：在运行状态下获取目标类的原始配置文件。

具体地，移动应用程序在安卓系统运行环境下，服务端获取在安卓系统中目标类的原始配置文件，其中，原始配置文件包安卓系统中的各类组件，例如，活动管理类(activitymanagerservice)、测试基类(instrumetation)、包管理类(packagemanage)和视图根(viewrootimpl)。

由于获取的原始配置文件是安卓系统中重要的四大类文件，并且原始配置文件的功能包括有通信、分发和事件传递等，这些功能对安卓系统奔溃问题的追踪具有重大意义，故在更换预设的目标配置文件之前，需要先获取原始配置文件。

s200：将原始配置文件替换为预设的目标配置文件，其中，目标配置文件包括追踪机制，追踪机制用于收集目标类的运行属性。

具体地，追踪机制包括应用程序签名机制、权限声明机制、访问控制机制、进程通信机制和内存管理机制，使得追踪机制能追踪和收集目标类的运行属性。

目标类的运行属性包括应用程序强制关闭、应用程序无响应、严重错误异常、严苛模式异常、低内存异常、系统服务无响应、网络状态异常、电池放电异常、系统异常开机、系统异常重启、内核错误、系统恢复层异常或本地进程异常。

其中，应用程序强制关闭(forceclose，也作crash)，通常出现在当java代码中出现未被捕获的异常；应用程序无响应(applicationnotresponding，anr)，通常出现在应用程序的主线程长时间未能得到响应时；严重错误异常(whataterriblefailure，wtf)，通常出现在当前发现了很严重的问题；严苛模式异常(strictmodeviolation)，通常出现在监测到不应当在主线程中执行的网络、文件时；内存异常(lowmemory，也作lowmem)，通常出现在内存不足时；系统服务无响应，通常出现在watchdog(看门狗)监测到系统服务(system_server)无响应时；网络状态异常(netstats_error)，通常出现在遇到明显的网络状态错误时。

服务端根据获取的原始配置文件对应的路径，将原始配置文件替换为预设的目标配置文件，使得根据目标配置文件能更好地更精准地追踪移动应用程序在安卓系统中的运行状态。

s300：根据运行属性生成追踪日志。

服务端检测目标移动应用程序在安卓系统中的运行状态，根据目标配置文件追踪的运行属性，将运行状态对应的运行属性记录在追踪日志中，追踪日志记录了目标移动应用程序在预设时间段内运行时遇到的奔溃问题。

通过在运行状态下获取目标类的原始配置文件；将原始配置文件替换为预设的目标配置文件，其中，目标配置文件包括追踪机制，追踪机制用于收集目标类的运行属性；根据运行属性生成追踪日志。本公开通过将目标配置文件替换原始配置文件，使得目标配置文件根据运行属性生成追踪日志，实现了能够精准定位到移动应用系统的运行问题，不仅减少技术开发人员的工作量，而且使技术开发人员能及时发现并解决运行问题，从而提高移动应用程序在安卓系统中的稳定性。

在一些实施方式中，目标类的原始配置文件包括活动管理类、测试基类、包管理类和视图根。

具体地，活动管理类是客户端用来管理系统中正在运行的所有活动组件(activity)包括任务(task)、内存(memory)、服务(service)等信息的工具。在活动管理类中有大量的get()方法，能收集各种信息，并将信息提供给应用管理系统，由应用管理系统去完成交互和调度工作；安卓系统中的活动组件中，所有的事件都需要通过中间件测试基类做分发；安卓系统的查询包信息中，都需要通过包管理类作为中间分发者；安卓系统在ui绘制或事件传递过程中，都会涉及到视图根的分发，也就是说所有在界面上显示的都是要经过视图根。

请参阅图2，图2为本实施例示出的获取原始配置文件的一种实施方式流程图。如图2所示，步骤s100包括：

s101：获取目标类的原始配置文件的属性信息。

原始配置文件的属性信息包括配置文件夹名称、访问权限、访问目录层数等。其中，访问权限是根据在各种预定义的组中用户的身份标识及其成员身份，限制访问某些信息项或某些控制的机制，由系统管理员用来控制用户访问网络资源，如服务器、目录和文件等的访问，并且通常通过向用户和组授予访问特定对象的权限来实现。

s102：根据属性信息获取原始配置文件的路径。

服务端根据属性信息中的文件夹名称以及访问目标层数来获取原始配置文件的路径，该路径也就是原始配置文件的存储路径。

s103：根据路径获取原始配置文件。

服务端根据路径定位到原始配置文件的所在位置；根据属性信息中的访问权限打开原始配置文件上的各类文件，并获取活动管理类、测试基类、包管理类和视图根等原始配置文件。

通过获取目标类的原始配置文件的属性信息，根据属性信息得到原始配置文件的路径，根据路径获取原始配置文件，使得能更精准的获取原始配置文件，为之后替换原始配置文件做好准备。

请参阅图3，图3为本实施例示出的原始配置文件替换为预设的目标配置文件的一种实施方式流程图。如图3所示，步骤s200包括：

s201：获取目标配置文件中的组件和代码块。

目标配置文件中的组件和代码块是根据原始配置文件的基础特性改进的配置文件，该配置文件负责监测追踪目标移动应用程序在安卓系统运行出现的奔溃问题。组件包括了预设的类或者对象的属性和方法，代码块包括预设参数值，该预设参数值用于替换当前奔溃问题中涉及到的变量值。

服务端根据目标配置文件的存储路径查找并获取组件和代码块。

具体地，目标配置文件的存储路径是预先在安卓系统上建立的预设路径；将改进的目标配置文按照预设的文件格式拷贝到预设路径的目标配置文件所在文件夹中。预设的文件格式包括：例如，将目标配置文件转换成文档文件jar，镜像文件iso或者可执行文件exe等。

s202：采用java反射机制将活动管理类、测试基类和包管理类分别对应的数据包替换为组件。

java反射机制是在运行状态中，对于任意一个类，都能够获取该类对应的所有属性和方法；对于任意一个对象，都能够调用它的任意方法和属性；这种动态获取信息以及动态调用对象方法的功能称为java语言的反射机制。

数据包包括原始配置文件分别对应的类的属性、类的方法、对象的属性和对象的方法。

服务端通过java反射机制将活动管理类、测试基类和包管理类分别对应的数据包替换为组件，也就是修改了原始配置文件中类的方法、类的属性、对象的方法或者对象的属性等。

s203：对视根图注入代码块，改变视根图的变量。

通过对视图根注入代码块，例如，代码块是修改视图根的id变量值，通过更改id变量值来防止在非移动应用程序退出时，防止视图状态未保存或者视图状态保存异常错误的问题。

通过采用java反射机制，将活动管理类、测试基类和包管理类分别对应的数据包替换为目标配置文件中的组件和代码块，完成对原始配置文件的替换，为追踪奔溃问题提供了基础条件。

请参阅图4，图4为本实施例示出的生成追踪日志的一种实施方式流程图。如图4所示，步骤s300包括：

s301：创建追踪日志表格。

具体地，服务端实时跟踪检测安卓系统中的功能行为，当服务端检测到目标移动应用程序在安卓系统运行下出现奔溃问题时，例如，移动应用程序奔溃导致强制退出、开机后立马打开目标移动应用程序反应迟缓甚至强制关闭或者检测到用户的多次操作行为导致移动应用程序处于卡顿状态等，服务端根据检测到的奔溃问题，自动生成一张追踪日志表格。其中，追踪日志表格上的字段名称包括时间，状态，类名称、预警标签类型以及运行属性等。

s302：扫描并读取目标类的运行属性。

服务端扫描包括活动管理类、测试基类、包管理类和视图根等目标类的运行状态；从运行状态中筛选出目标类的运行属性；读取目标类的运行属性，从而避免读取了目标类的正常运行状态，更有效地捕捉奔溃问题。

具体地，目标类的运行属性携带预警标签，方便了在运行状态中筛选出具备奔溃问题特性的运行属性。不同类型的运行属性携带不同的预警标签，使得服务端根据预警标签对运行属性进行分类汇总。例如，将目标类的运行属性中的程序强制关闭设置为一级预警标签、系统服务无响应为二级预警标签和本地进行异常为三级预警标签等。

s303：将目标类的运行属性记录在追踪日志表格中，得到追踪日志。

读取经过分类汇总的运行属性、状态、产生运行属性时对应的时间、运行属性对应的类等奔溃信息；按照追踪日志表格的字段名称自动写入奔溃信息，最终得到目标移动应用程序的追踪日志。

通过将读取目标类的运行属性记录在创建的追踪日志表格中，得到追踪日志的过程中，能更好地反馈了目标移动应用程序的奔溃问题，利于更好地追踪奔溃问题。

请参阅图5，图5为本实施例示出的处理追踪日志的的一种实施方式流程图。如图5所示，在执行步骤s200之后，日志追踪方法还包括：

s210：在预设的排查信息表检测追踪日志是否存在一般报错信息。

一般报错信息是对频繁出现的奔溃问题的描述，此类奔溃问题一般都有自动修复的解决方案。

具体地，预设的排查信息表记录了一般错误信息和一般错误信息的解决方案。

s220：若追踪日志存在一般报错信息，则自动修复一般报错信息。

若追踪日志存在与一般报错信息相同的运行属性，则根据排查信息表上记录的一般错误信息的解决方案，调用解决方案对应的数据包；通过解析数据包中的程序代码，从而实现自动修复一般错误信息。

s230：若追踪日志不存在一般报错信息，则对追踪日志作标记处理。

具体地，标记处理可以是将非一般错误信息的运行属性进行标记，例如标记的方式包括但不限于设置特殊的预警标签、或者标注待处理的信号信息等。

通过若在预设的排查信息表检测追踪日志存在一般报错信息，则自动修复一般报错信息，否则对追踪日志做标记处理，有利于更快地解决奔溃问题，减少技术开发人员的工作量。

在执行步骤s300之后，日志追踪方法具体还包括：在预设时间内，将标记处理过的追踪日志按照预设的通知方式发送给管理员终端。

具体地，预设时间可以自由设置，例如，每天的工作时间，或者每小时等；预设的通知方式包括但不限于邮件、短信或者管理系统的信息通知等。

通过将识别到的标记处理过的追踪日志发送至管理员的终端有利于对目标移动应用程序的奔溃问题的即时反馈，使得管理员能即及时解决追踪日志上的运行属性，使目标应用程序得到更好地维护。

图6是根据一示例性实施例示出的一种日志追踪装置框图。参照图6，该日志追踪装置包括获取单元110、处理单元120和执行单元130。其中，获取单元110，被配置为在运行状态下获取目标类的原始配置文件；处理单元120，被配置为将原始配置文件替换为预设的目标配置文件，其中，目标配置文件包括追踪机制，追踪机制用于收集目标类的运行属性；执行单元130，被配置为根据运行属性生成追踪日志。

在一些实施方式中，目标类的原始配置文件包括活动管理类、测试基类、包管理类和视图根。

在一些实施方式中，日志追踪装置还包括第一获取单元、第一处理单元和第一执行单元。其中，第一获取单元，被配置为获取目标类的原始配置文件的属性信息；第一处理单元，被配置为根据属性信息获取原始配置文件的路径；第一执行单元，被配置为根据路径获取原始配置文件。

在一些实施方式中，日志追踪装置还包括第二获取单元、第二处理单元和第二执行单元。其中，第二获取单元，被配置为获取目标配置文件中的组件和代码块；第二处理单元，被配置为采用java反射机制将活动管理类、测试基类和包管理类分别对应的数据包替换为组件；第二执行单元，被配置为对视根图注入代码块，改变视根图的变量。

在一些实施方式中，日志追踪装置还包括创建单元、扫描单元和记录单元。其中，创建单元，被配置为创建追踪日志表格；扫描单元，被配置为扫描并读取目标类的运行属性；记录单元，被配置为将目标类的运行属性记录在追踪日志表格中，得到追踪日志。

在一些实施方式中，日志追踪装置还包括：检测单元、修复单元和标记单元。其中，检测单元、，被配置为在预设的排查信息表检测追踪日志是否存在一般报错信息；修复单元，被配置为若追踪日志存在一般报错信息，则自动修复一般报错信；标记单元，被配置为若追踪日志不存在一般报错信息，则对追踪日志作标记处理。

在一些实施方式中，日志追踪装置还包括发送单元，被配置为在预设时间内，将标记处理过的追踪日志按照预设的通知方式发送给管理员终端。

关于上述实施例中的日志追踪装置，其中各个单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图7是根据一示例性实施例示出的一种用于日志追踪的移动终端700的框图。例如，移动终端700可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

参照图7，移动终端700可以包括以下一个或多个组件：处理组件702，存储器704，电力组件706，多媒体组件708，音频组件710，输入/输出(i/o)的接口712，传感器组件714，以及通信组件716。

处理组件702通常控制移动终端700的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件702可以包括一个或多个处理器720来执行指令，以完成上述的日志追踪方法的全部或部分步骤。此外，处理组件702可以包括一个或多个模块，便于处理组件702和其他组件之间的交互。例如，处理组件702可以包括多媒体模块，以方便多媒体组件708和处理组件702之间的交互。

存储器704被配置为存储各种类型的数据以支持在移动终端700的操作。这些数据的示例包括用于在移动终端700上操作的任何应用程序或日志追踪方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器704可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。

电源组件706为移动终端700的各种组件提供电力。电源组件706可以包括电源管理系统，一个或多个电源，及其他与为移动终端700生成、管理和分配电力相关联的组件。

多媒体组件708包括在所述移动终端700和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(lcd)和触摸面板(tp)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件708包括一个前置摄像头和/或后置摄像头。当设备700处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件710被配置为输出和/或输入音频信号。例如，音频组件710包括一个麦克风(mic)，当移动终端700处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器704或经由通信组件716发送。在一些实施例中，音频组件710还包括一个扬声器，用于输出音频信号。

i/o接口712为处理组件702和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件714包括一个或多个传感器，用于为移动终端700提供各个方面的状态评估。例如，传感器组件714可以检测到设备700的打开/关闭状态，组件的相对定位，例如所述组件为移动终端700的显示器和小键盘，传感器组件714还可以检测移动终端700或移动终端700一个组件的位置改变，用户与移动终端700接触的存在或不存在，移动终端700方位或加速/减速和移动终端700的温度变化。传感器组件714可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件714还可以包括光传感器，如cmos或ccd图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件714还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件716被配置为便于移动终端700和其他设备之间有线或无线方式的通信。移动终端700可以接入基于通信标准的无线网络，如wifi，运营商网络(如2g、3g、4g或5g)，或它们的组合。在一个示例性实施例中，通信组件716经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件716还包括近场通信(nfc)模块，以促进短程通信。例如，在nfc模块可基于射频识别(rfid)技术，红外数据协会(irda)技术，超宽带(uwb)技术，蓝牙(bt)技术和其他技术来实现。

在示例性实施例中，移动终端700可以被一个或多个应用专用集成电路(asic)、数字信号处理器(dsp)、数字信号处理设备(dspd)、可编程逻辑器件(pld)、现场可编程门阵列(fpga)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述日志追踪方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器704，上述指令可由移动终端700的处理器720执行以完成上述日志追踪方法。例如，所述非临时性计算机可读存储介质可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等。

图8是根据一示例性实施例示出的一种用于日志追踪的电子设备800的框图。例如，电子设备800可以被提供为一服务器。参照图8，电子设备800包括处理组件822，其进一步包括一个或多个处理器，以及由存储器832所代表的存储器资源，用于存储可由处理组件822的执行的指令，例如应用程序。存储器832中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件822被配置为执行指令，以执行上述日志追踪方法。

电子设备800还可以包括一个电源组件826被配置为执行电子设备800的电源管理，一个有线或无线网络接口850被配置为将电子设备800连接到网络，和一个输入输出(i/o)接口858。电子设备800可以操作基于存储在存储器832的操作系统，例如windowsservertm，macosxtm，unixtm,linuxtm，freebsdtm或类似。

一种计算机程序产品，包括计算机程序代码，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，使所述计算机执行上述日志追踪方法。

本领域技术人员在考虑说明书及实践这里公开后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。