CN111176968A

CN111176968A - 一种生成日志文件的方法、装置及相关产品

Info

Publication number: CN111176968A
Application number: CN201911403289.0A
Authority: CN
Inventors: 马忠义; 崔朝辉; 赵立军; 张霞
Original assignee: Neusoft Corp
Current assignee: Neusoft Corp
Priority date: 2019-12-30
Filing date: 2019-12-30
Publication date: 2020-05-19
Anticipated expiration: 2039-12-30
Also published as: CN111176968B

Abstract

本申请公开一种生成日志文件的方法、装置及相关产品。对于任一可调度的线程，当调度该线程处理对第一系统的第一访问请求时，线程调用该请求对应的服务功能组件并调用日志记录组件。服务功能组件处理请求时，日志记录组件记录各个服务功能组件的名称及各个服务功能组件处理该请求的输入日志信息和输出日志信息。当该请求结束时，利用日志记录组件中结构化存入的组件名称以及日志信息生成第一日志文件。第一日志文件中日志信息条目以访问请求为界相互隔离存在，避免混叠问题，提升日志信息可用性。日志记录组件将第一访问请求对应的服务功能组件的名称及日志信息结构化地记录下来，第一日志文件具有较好的可读取性，提升了日志信息的可用性。

Description

一种生成日志文件的方法、装置及相关产品

技术领域

本申请涉及数据存储与应用领域，特别是涉及一种生成日志文件的方法、装置及相关产品。

背景技术

系统服务功能的丰富程度通常依赖于服务功能组件的多样性。很多系统的内部都比较复杂，包括若干相互独立的服务功能组件。以知识服务系统为例，知识服务系统可以包括：请求的路由组件、分词组件、搜索组件、情感分析组件和知识图谱推理组件等多个服务功能组件。针对单次的访问请求，系统往往就需要调用自身的多个服务功能组件。

根据访问请求生成日志文件，对于系统的故障排查和功能优化非常重要。按照现有的方法很容易记录下单次访问形成的日志。但是，当系统被并发访问时，形成的日志中不同访问请求的日志信息交互混叠，严重影响了日志信息的可用性。

发明内容

基于上述问题，本申请提供了一种生成日志文件的方法、装置及相关产品，解决系统被并发访问时日志信息交互混叠、难于应用的问题。

本申请实施例公开了如下技术方案：

第一方面，本申请提供一种生成日志文件的方法，应用于第一线程，所述第一线程为第一系统的一个可调度的线程，所述第一系统包括日志记录组件和多个服务功能组件，所述日志记录组件包括记录结构，所述记录结构包括：组件名称填入位置和日志信息文本填入位置；所述方法包括：

所述第一线程根据对所述第一系统的第一访问请求调用所述请求对应的服务功能组件，以使所述服务功能组件处理所述请求；并且，所述第一线程调用所述日志记录组件，以使所述日志记录组件将所述请求对应的服务功能组件的名称填入所述组件名称填入位置，并将所述请求对应的服务功能组件的输入日志信息和输出日志信息填入所述日志信息文本填入位置；

当确定所述请求结束时，利用所述日志记录组件按照所述记录结构填入的所述服务功能组件的名称、输入日志信息和输出日志信息生成一个日志信息条目，将所述条目写入第一日志文件。

可选地，该方法还包括：

获得服务项目信息与服务功能组件的对应关系；

所述根据对所述第一系统的第一访问请求调用所述请求对应的服务功能组件，具体包括：

根据所述对应关系以及所述请求中携带的服务项目信息确定对应的服务功能组件；

调用所述请求中携带的服务项目信息对应的服务功能组件。

可选地，该方法还包括：

获得所述请求对应的日志期待文件，所述日志期待文件包括所述请求对应的各个服务功能组件的期待输出信息；

确定各个服务功能组件对应的输出偏差允许条件；

在所述将所述条目写入第一日志文件后，所述方法还包括：

利用所述第一日志文件、所述日志期待文件和所述各个服务功能组件对应的输出偏差允许条件，确定所述各个服务功能组件中不满足所述输出偏差允许条件的首个服务功能组件；

输出第一反馈消息；所述第一反馈消息用于指示需要对所述首个服务功能组件进行调试。

可选地，该方法还包括：

获得所述请求对应的服务功能组件之中目标组件的期待输出信息；

确定所述目标组件对应的输出偏差允许条件；

在所述将所述条目写入第一日志文件后，所述方法还包括：

判断所述第一日志文件中所述目标组件的输出日志信息与所述期待输出信息的偏差是否满足所述目标组件对应的输出偏差允许条件，如果否，则输出第二反馈消息；所述第二反馈消息用于指示需要对所述目标组件进行调试。

可选地，该方法还包括：

获取第二日志文件中第二访问请求对应的起始输入日志信息和结束输出日志信息；所述第二日志文件为第二系统根据所述第二访问请求生成；所述第二访问请求携带与所述第一访问请求中相同的服务项目信息；

在所述将所述条目写入第一日志文件后，所述方法还包括：

当所述第一日志文件中所述第一访问请求对应的起始输入日志信息和所述第二日志文件中所述第二访问请求对应的起始输入日志信息相同时，判断所述第二日志文件中所述第二访问请求对应的结束输出日志信息是否优于所述第一日志文件中所述第一访问请求对应的结束输出日志信息，如果是，则输出第三反馈消息；所述第三反馈消息用于指示需要对所述第一系统中所述第一访问请求对应的服务功能组件进行调试。

第二方面，本申请提供一种生成日志文件的装置，应用于第一线程，所述第一线程为第一系统的一个可调度的线程，所述第一系统包括日志记录组件和多个服务功能组件，所述日志记录组件包括记录结构，所述记录结构包括：组件名称填入位置和日志信息文本填入位置；所述装置包括：

第一调用模块，用于根据对所述第一系统的第一访问请求调用所述请求对应的服务功能组件，以使所述服务功能组件处理所述请求；

第二调用模块，用于调用所述日志记录组件，以使所述日志记录组件将所述请求对应的服务功能组件的名称填入所述组件名称填入位置，并将所述请求对应的服务功能组件的输入日志信息和输出日志信息填入所述日志信息文本填入位置；

日志文件生成模块，用于当确定所述请求结束时，利用所述日志记录组件按照所述记录结构填入的所述服务功能组件的名称、输入日志信息和输出日志信息生成一个日志信息条目，将所述条目写入第一日志文件。

可选地，该装置还包括：

对应关系获取模块，用于获得服务项目信息与服务功能组件的对应关系；

所述第一调用模块，具体包括：

组件确定单元，用于根据所述对应关系以及所述请求中携带的服务项目信息确定对应的服务功能组件；

组件调用单元，用于调用所述请求中携带的服务项目信息对应的服务功能组件。

可选地，该装置还包括：

日志期待文件获取模块，用于获得所述请求对应的日志期待文件，所述日志期待文件包括所述请求对应的各个服务功能组件的期待输出信息；

条件确定模块，用于确定各个服务功能组件对应的输出偏差允许条件；

组件定位模块，用于利用所述第一日志文件、所述日志期待文件和所述各个服务功能组件对应的输出偏差允许条件，确定所述各个服务功能组件中不满足所述输出偏差允许条件的首个服务功能组件；

反馈模块，用于输出第一反馈消息；所述第一反馈消息用于指示需要对所述首个服务功能组件进行调试。

可选地，该装置中，日志期待文件获取模块还可用于获得所述请求对应的服务功能组件之中目标组件的期待输出信息；

条件确定模块还可以用于确定所述目标组件对应的输出偏差允许条件；

装置还包括：条件第一判断模块，用于判断所述第一日志文件中所述目标组件的输出日志信息与所述期待输出信息的偏差是否满足所述目标组件对应的输出偏差允许条件；

反馈模块还用于当条件第一判断模块判断结果为否时，输出第二反馈消息；所述第二反馈消息用于指示需要对所述目标组件进行调试。

可选地，该装置中，还可以包括：

竞品日志信息获取模块，用于获取第二日志文件中第二访问请求对应的起始输入日志信息和结束输出日志信息；其中，第二日志文件为第二系统根据所述第二访问请求生成；所述第二访问请求携带与所述第一访问请求中相同的服务项目信息；

条件第二判断模块，用于当所述第一日志文件中所述第一访问请求对应的起始输入日志信息和所述第二日志文件中所述第二访问请求对应的起始输入日志信息相同时，判断所述第二日志文件中所述第二访问请求对应的结束输出日志信息是否优于所述第一日志文件中所述第一访问请求对应的结束输出日志信息；

反馈模块还可以用于当条件第二判断模块判断结果为是时，输出第三反馈消息；所述第三反馈消息用于指示需要对所述第一系统中所述第一访问请求对应的服务功能组件进行调试。

第三方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当所述程序被处理器运行时，实现如第一方面提供的生成日志文件的方法。

第四方面，本申请提供一种处理器，其特征在于，用于运行计算机程序，所述程序运行时执行如第一方面提供的生成日志文件的方法。

相较于现有技术，本申请具有以下有益效果：

在本申请中，第一系统的线程之间相互独立，线程不会同时处理多个请求。对于任一可调度的线程，当调度该线程处理对第一系统的第一访问请求时，该线程不但调用该请求对应的服务功能组件，还调用日志记录组件。当服务功能组件处理请求时，日志记录组件记录各个服务功能组件的名称以及各个服务功能组件处理该请求的输入日志信息和输出日志信息。日志记录组件中包括记录结构，记录结构中包括组件名称填入位置，各个服务功能组件的名称填入其中；记录结构还包括日志信息文本填入位置，各个服务功能组件的输入日志信息和输出日志信息填入其中。进而，第一访问请求所对应的服务功能组件的名称、输入日志信息和输出日志信息被结构化地存入日志记录组件中。当该请求结束时，利用日志记录组件中结构化存入的该请求对应的组件名称以及日志信息生成第一日志文件。

同一线程在同一时间仅负责处理一个访问请求，并根据该请求调用相应的服务功能组件，以及调用日志记录组件分别记录不同请求对应的日志信息，生成日志信息条目再写入第一日志文件。第一日志文件中，日志信息条目以访问请求为界相互隔离地存在，避免了交互混叠的问题，提升了日志信息的可用性。并且由于日志记录组件将第一访问请求对应的服务功能组件的名称及日志信息结构化地记录下来，因此线程生成的第一日志文件具有较好的可读取性，进一步地提升了日志信息的可用性。

附图说明

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

图1为本申请实施例提供的一种知识服务系统的结构示意图；

图2为本申请实施例提供的一种生成日志文件的方法流程图；

图3为本申请实施例提供的一种应用日志文件定位需调试的组件的方法流程图；

图4为本申请实施例提供的另一种应用日志文件定位需调试的组件的方法流程图；

图5为本申请实施例提供的一种应用日志文件进行竞品分析的方法流程图；

图6为本申请实施例提供的一种生成日志文件的装置的结构示意图；

图7为本申请实施例提供的一种生成日志文件的设备的硬件结构图。

具体实施方式

为便于理解本申请技术方案的应用场景，下面结合一个具备多服务功能组件的系统进行描述和说明。

参见图1，该图为本申请实施例提供的一种知识服务系统的结构示意图。

如图1所示，该知识服务系统中包括多个独立的服务功能组件，分别是组件A至组件F。其中，组件A表示请求的路由组件，组件B表示分词组件，组件C表示命名实体识别组件，组件D表示搜索组件，组件E表示情感分析组件，组件F表示知识图谱推理组件。图1中，组件之间的连接箭头表示系统根据用户端发起的访问请求可能调用的组件顺序。例如，基于某一访问请求可能调用的组件为：A→B→E、A→C→F或A→D→F。

下面示例性地提供用户端发起访问请求的两种可能实现方式。在一种可能的实现方式中，用户对应的终端设备与该知识服务系统通信连接，该终端设备响应于用户的操作，向知识服务系统发起访问请求。用户对应的终端设备可以是手机、笔记本电脑等便携式可移动终端设备。在另一种可能的实现方式中，用户通过触控、声控或接受扫描等方式与安装有该知识服务系统的终端设备进行交互，进而向知识服务系统发起访问请求。

可以理解的是，图1中包含的六种服务功能组件仅为示例，实际应用中不同的系统包含的组件类型不局限于上述六种。另外，依据系统能够提供的服务和用户发起的访问请求，实际应用中对组件的调用顺序也包含多种可能。因此，本实施例中不以图1所示的组件类型和组件调用顺序为限定。

假设一次访问请求(以Request-1来表示)需要知识服务系统调用组件A→B→E，则根据该次请求生成的日志可能为：

[Request-1]A的输入日志信息；

[Request-1]A的输出日志信息；

[Request-1]B的输入日志信息；

[Request-1]B的输出日志信息；

[Request-1]E的输入日志信息；

[Request-1]E的输出日志信息。

可以理解的是，服务功能丰富的系统通常可以处理并发的访问请求。假设并发的三个访问请求分别为Request-1、Request-2和Request-3，其中，Request-1需要调用组件A→B→E；Request-2需要调用组件A→C→F；Request-3需要调用组件A→D→F。则知识服务系统在对上述三个访问请求并发处理时，生成的日志可能为：

[Request-1]A的输入日志信息；

[Request-2]A的输入日志信息；

[Request-3]A的输入日志信息；

[Request-3]A的输出日志信息；

[Request-1]A的输出日志信息；

[Request-1]B的输入日志信息；

[Request-1]E的输出日志信息；

[Request-3]D的输入日志信息；

[Request-2]A的输出日志信息；

[Request-2]C的输入日志信息；

[Request-2]C的输出日志信息；

[Request-3]D的输出日志信息；

[Request-3]F的输入日志信息；

[Request-2]F的输入日志信息；

[Request-2]F的输出日志信息；

[Request-1]B的输出日志信息；

[Request-1]E的输入日志信息；

[Request-3]F的输出日志信息。

可见，在系统被并发访问的场景下，日志信息存在交互混叠的问题。因此，很难从中提取出有效的日志信息加以分析和应用。例如，对Request-2的处理结果不满意时，需要找到Request-2相关的全部日志信息进行检查，但是在如上交互混叠的日志中很难准确定位Request-2相关的全部日志信息。

针对上述问题，发明人经过研究提供一种生成日志文件的方法、装置及相关产品。在本申请技术方案中，以线程为单位处理单个访问请求，在调用请求相关的服务功能组件的过程中还额外调用系统的日志记录组件，利用该日志记录组件记录请求相关的日志信息。由于日志记录组件的记录结构包括组件名称填入位置以及日志信息文本填入位置，因此，请求相关的日志信息被结构化地记录下来。当请求结束时，线程利用日志记录组件记录的组件名称及日志信息生成日志信息条目，并将此条目写入第一日志文件。该第一日志文件中即包括该访问请求的整个生命周期的日志信息。本申请技术方案中，不同访问请求的日志信息条目相互隔离地存在于日志文件中，避免了交互混叠的现象，便于日志信息的有效提取。可见，该方案提升了日志信息的可用性。

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

方法实施例

参见图2，该图为本申请实施例提供的一种生成日志文件的方法流程图。该方法应用于第一系统的一个可调度的线程。第一系统可以是上文场景描述中提及的知识服务系统，还可以是其他的具备多个服务功能组件的系统，例如故障检测系统、智能语音陪护系统或多媒体教学系统等。

第一系统包括线程池，空闲的线程存放于线程池中，这些空闲的线程属于可调度的线程。另外，在线程池之外还可能包括一些正在执行任务的线程。线程是第一系统调度的最小单位，当第一系统接收到第一访问请求时，可以调度线程池中的空闲线程来处理该访问请求。以下用第一线程指代第一系统接收到第一访问请求时调度的线程。

如图2所示，本实施例提供的生成日志文件的方法包括：

步骤201：第一线程根据对第一系统的第一访问请求调用所述请求对应的服务功能组件；并且，第一线程调用所述日志记录组件。

假设第一系统是知识服务系统，则其包含的服务功能组件可以为图1所示的组件A至组件F。服务功能组件可以理解为算法组件，当服务功能组件被调用工作时，实现算法相应的服务功能。例如，组件B是分词组件，则组件B工作时实现分词算法相应的服务功能，即分词功能。

第一线程可以根据第一访问请求调用该请求对应的服务功能组件。例如，第一访问请求为对文本进行情感分析的请求，则对应的服务功能组件包括：组件A、组件B和组件E。第一线程调用服务功能组件，服务功能组件便可以处理第一访问请求，具体地，服务功能组件响应对自身的调用，实现自身的服务功能。

本实施例中，第一系统除了包含多个服务功能组件(例如组件A至组件F)，还包括日志记录组件。第一线程在调用第一访问请求对应的服务功能组件过程中还调用该日志记录组件。以Java语言实现日志记录组件为例，日志记录组件可以利用面向切面编程(AspectOriented Programming,AOP)技术在每个服务功能组件的输入端和输出端设置切面，从而拦截每个服务功能组件在处理请求时的输入日志信息和输出日志信息。本实施例中实现日志记录组件的编程语言不局限于Java语言。

日志记录组件包括记录结构，记录结构包括：组件名称填入位置和日志信息文本填入位置。日志记录组件被调用时，将第一访问请求对应的服务功能组件的名称填入所述组件名称填入位置，并将第一访问请求对应的服务功能组件的输入日志信息和输出日志信息填入日志信息文本填入位置。

下面示例性地提供日志记录组件的记录结构：

{“组件名称1-in”：“组件名称1的输入日志信息”，

“组件名称1-out”：“组件名称1的输出日志信息”,

“组件名称2-in”：“组件名称2的输入日志信息”,

“组件名称2-out”：“组件名称2的输出日志信息”,

……}

在以上记录结构中，冒号之前的“组件名称1-in”、“组件名称1-out”、“组件名称2-in”、“组件名称2-out”等为组件名称填入位置；冒号之后的“组件名称1的输入日志信息”、“组件名称1的输出日志信息”、“组件名称2的输入日志信息”、“组件名称2的输出日志信息”等为日志信息文本填入位置。

假设对于第一访问请求，第一线程需要调用的服务功能组件依次为组件A、组件B和组件E，则当组件A处理该第一访问请求时，日志记录组件将组件A的名称、输入日志信息和输出日志信息填入上述记录结构中；当组件B处理该第一访问请求时，日志记录组件将组件B的名称、输入日志信息和输出日志信息填入上述记录结构中，以此类推。

步骤202：当确定请求结束时，利用日志记录组件按照记录结构填入的所述服务功能组件的名称、输入日志信息和输出日志信息生成一个日志信息条目，将所述条目写入第一日志文件。

当第一系统对第一访问请求处理完成后即会发出响应(response)。响应发出之时就是请求结束之时。第一线程能够根据该响应确定第一访问请求结束。本申请实施例中，确定第一访问请求结束时，第一线程调用的日志记录组件可以利用之前结构化地填入的服务功能组件的名称、输入日志信息和输出日志信息来生成一个日志信息条目。

假设组件A的输入日志信息为S1，输出日志信息为S2；组件B的输入日志信息为S3，输出日志信息为S4；组件E的输入日志信息为S5，输出日志信息为S6。第一访问请求对应的日志信息条目形式如下：

{“A-in”：“S1”，“A-out”：“S2”，“B-in”：“S3”，“B-out”：“S4”，“E-in”：“S5”，“E-out”：“S6”}

上述日志信息条目可以写入第一日志文件中，即，应用本申请实施例提供的方法，最终生成了包含第一访问请求对应的日志信息条目的第一日志文件。

以上即为本申请实施例提供的一种生成日志文件的方法。在本申请中，第一系统的线程之间相互独立，线程不会同时处理多个请求。对于任一可调度的线程，当调度该线程处理对第一系统的第一访问请求时，该线程不但调用该请求对应的服务功能组件，还调用日志记录组件。当服务功能组件处理请求时，日志记录组件记录各个服务功能组件的名称以及各个服务功能组件处理该请求的输入日志信息和输出日志信息。日志记录组件中包括记录结构，记录结构中包括组件名称填入位置，各个服务功能组件的名称填入其中；记录结构还包括日志信息文本填入位置，各个服务功能组件的输入日志信息和输出日志信息填入其中。进而，第一访问请求所对应的服务功能组件的名称、输入日志信息和输出日志信息被结构化地存入日志记录组件中。当该请求结束时，利用日志记录组件中结构化存入的该请求对应的组件名称以及日志信息生成第一日志文件。

在一种可能的实现方式中，第一线程处理的第一访问请求相关的日志信息以一个条目的形式写入到第一日志文件中，而其他线程分别处理的访问请求相关的日志信息以其他条目的形式附加(append)到该第一日志文件中。另外，日志记录组件可以依照轮训规则生成日志文件，例如，当第一日志文件的大小超出预设数据量时，日志记录组件还可以重新生成第二日志文件。

以下示例性地提供依照前述方法生成的日志文件中的日志信息条目，其中Request-1、Request-2和Request-3分别代表三个由不同线程处理的访问请求：

[Request-1]{“A-in”:“A的输入日志信息”,“A-out”:“A的输出日志信息”,“B-in”:“B的输入日志信息”,“B-out”:“B的输出日志信息”,“E-in”:“E的输入日志信息”,“E-out”:“E的输出日志信息”}

[Request-2]{“A-in”:“A的输入日志信息”,“A-out”:“A的输出日志信息”,“C-in”:“C的输入日志信息”,“C-out”:“C的输出日志信息”,“F-in”:“F的输入日志信息”,“F-out”:“F的输出日志信息”}

[Request-3]{“A-in”:“A的输入日志信息”,“A-out”:“A的输出日志信息”,“D-in”:“D的输入日志信息”,“D-out”:“D的输出日志信息”,“F-in”:“F的输入日志信息”,“F-out”:“F的输出日志信息”}

结合以上示例中日志文件的日志信息可知，由于仅当请求结束时，请求的整个生命周期的日志信息才会统一以条目的形式输出到日志文件中，避免了实时输出日志信息导致的不同请求间交互混杂的问题。各个请求相关的组件的日志信息条目能够以请求为单位相互隔离开，便于日志信息的提取和定位。在具体实现时，可以设置日志记录组件的层级高于服务功能组件，使日志记录组件能够拦截服务功能组件的信息，而对于各个服务功能组件而言，日志记录组件是不可知、不可见的。从而提升日志记录组件获取日志信息的便捷性，并同时避免日志记录组件对服务功能组件处理请求的干扰。

在前述实施例步骤201中，第一线程根据对第一系统的第一访问请求调用该请求对应的服务功能组件。为了提升这一操作的便捷性和执行效率，在具体实现时，步骤201之前该方法还可以进一步包括：

获得服务项目信息与服务功能组件的对应关系。

需要说明的是，用户端向第一系统发起访问请求时，其中可以携带服务项目信息。服务项目信息指示了用户端希望该第一系统提供的服务项目。例如，指示情感分析服务项目的服务项目信息为qgfx；指示搜索推理服务项目的服务项目信息为sstl。本步骤即是在接收访问请求之前预先建立服务项目信息与服务功能组件的对应关系。例如，服务项目信息qgfx对应的服务功能组件为：组件A、组件B和组件E；服务项目信息tl对应的服务功能组件为：组件A、组件D和组件F。

服务项目信息与服务功能组件的对应关系可以以映射表的形式保存在第一系统中。

在预先获得服务项目信息与服务功能组件的对应关系的基础上，步骤201可以具体通过以下方式实现：

根据对应关系以及第一访问请求中携带的服务项目信息确定对应的服务功能组件；调用第一访问请求中携带的服务项目信息对应的服务功能组件。

例如，如果第一访问请求携带的服务项目信息为qgfx，则本步骤中根据预先建立和获取的对应关系以及该服务项目信息qgfx获得qgfx对应的服务项目组件，即组件A、组件B和组件E。由于明确了第一访问请求希望第一系统提供的服务项目与组件A、组件B和组件E，因此，在具体实现时，第一线程调用组件A、组件B和组件E即可。

通过对以上实施例的描述可知，由于第一日志文件中第一访问请求相关的日志信息条目是在该请求结束时(或结束后)生成的，因此该日志信息条目中包含了第一访问请求整个生命周期的相关日志信息，例如第一访问请求对应的某一服务功能组件的输入日志信息和输出日志信息。并且，对于知识服务系统等算法复杂的系统，进行调试的过程中需要获知每一个服务功能组件的输入和输出，即知识服务系统的调试对于日志中每个组件的输入和输出具有较强的依赖。以上方法通过结构化地存入组件的名称、输入日志信息及输出日志信息，降低了定位问题组件的难度，能够为系统的调试环节提供便利。另外，也方便在同类型竞品系统之间进行对照分析。下面结合示例描述应用该日志文件的多种实现方式。

首先，结合图3描述利用日志文件定位需要调试的组件的一种实施例。

参见图3，该图为本申请实施例提供的一种应用日志文件定位需要调试的组件的方法流程图。在图3示意的方法步骤303执行之前，前述实施例中步骤201-202已经执行完毕。

如图3所示，本实施例提供的应用日志文件定位需要调试的组件的方法，包括：

步骤301：获得第一访问请求对应的日志期待文件，日志期待文件包括第一访问请求对应的各个服务功能组件的期待输出信息。

假设日志期待文件中第一访问请求对应的各个服务功能组件(组件A、组件B和组件E)的期待输出信息分别为S2_expect、S4_expect和S6_expect。可以理解的是，每个组件的期待输出信息为：组件在功能实现较为理想的情况下处理第一访问请求的输出日志信息。

步骤302：确定各个服务功能组件对应的输出偏差允许条件。

在本实施例中，各个服务功能组件对应的输出偏差允许条件可以理解为对该组件进行调试的容忍条件。当条件满足时，表示组件实际的输出日志信息与期待输出信息偏差不大，因此无需对组件进行调试；而当条件不满足时，表示组件实际的输出日志信息与期待输出信息偏差较大，因此为了保证组件能够提供较好的服务功能，需要对组件进行调试。

如果组件实际的输出日志信息与期待输出信息是数值形式，则输出偏差允许条件可以是数值差异小于某个预设阈值；如果组件实际的输出日志信息与期待输出信息不是数值形式，并且输出日志信息和期待输出信息都可以通过评分机制进行评分，则输出偏差允许条件可以是二者评分差异小于某个预设阈值。

可以理解的是，由于不同服务功能组件能够提供的服务是不同的，因此第一访问请求对应的各个服务功能组件的输出日志信息通常是不同的，进一步地，各个服务功能组件对应的输出偏差允许条件也可能存在差别。例如，组件B对应的输出偏差允许条件不同于组件E对应的输出偏差允许条件。

步骤303：利用第一日志文件、日志期待文件和各个服务功能组件对应的输出偏差允许条件，确定各个服务功能组件中不满足输出偏差允许条件的首个服务功能组件。

假设第一日志文件中第一访问请求对应的组件A、组件B和组件E的输出日志信息分别为S2、S4和S6；组件A、组件B和组件E对应的输出偏差允许条件分别表示为：condition_A、condition_B和condition_E。

本步骤具体实现时，即是根据S2和S2_expect判断condition_A是否满足，根据S4和S4_expect判断condition_B是否满足，根据S6和S6_expect判断condition_E是否满足。实际应用中，各个组件对应的输出偏差允许条件中可能有一个条件不满足，也可能有多个条件不满足。而对于有多个条件不满足的情况，很可能是在先调用的组件输出的结果不符合期待，进而导致在后调用的组件输出的结果不符合期待。

本实施例中，确定出各个服务功能组件中不满足输出偏差允许条件的首个服务功能组件。例如，condition_B和condition_E均不满足，由于condition_B对应的组件B相对于condition_E对应的组件E被先一步调用和处理该请求，因此，可以确定组件B是不满足输出偏差允许条件的首个服务功能组件。

步骤304：输出第一反馈消息。

在步骤303中已经确定了影响对第一访问请求的处理效果的首个组件，本实施例中，第一线程还输出第一反馈消息，该消息用于指示需要对首个服务功能组件进行调试。

这一消息可以通过多种可能的方式输出。例如，发送邮件或短消息，通过语音播报出来，通过显示屏显示出来等。此处对步骤304的具体实现方式不进行限定。需要说明的是，在实际应用中，输出的第一反馈消息可以提供给技术人员，例如第一系统的研发工程师，以便研发工程师根据第一反馈消息对该组件进行调试和优化。

在上述对日志文件的应用实施例中，因为第一日志文件中包含的日志信息条目是利用结构化的组件的名称、输入日志信息和输出日志信息生成的，因此，第一日志文件具有较高的可读性。具有较高可读性的第一日志文件在进行组件定位和组件调试等方面具有较高的可用性，提升了对组件定位和组件调试的效率和便捷度。

下面结合图4描述利用日志文件定位需要调试的组件的另一种实施例。

参见图4，该图为本申请实施例提供的另一种应用日志文件定位需要调试的组件的方法流程图。在图4示意的方法步骤403执行之前，前述实施例中步骤201-202已经执行完毕。

如图4所示，该实施例提供的应用日志文件定位需要调试的组件的方法，包括：

步骤401：获得第一访问请求对应的服务功能组件之中目标组件的期待输出信息。

假设第一访问请求对应的服务功能组件包括：组件A、组件B和组件E，其中组件B为目标组件。在本实施例中，组件B的期待输出信息为“悟空，调整了，心态”。

步骤402：确定所述目标组件对应的输出偏差允许条件。

组件B对应的偏差允许条件可以是：组件B实际的输出日志信息等同于期待输出信息。也就是说，当第一日志文件中组件B的输出日志信息与期待输出信息一致时，输出偏差允许条件满足，否则便表示组件B的功能效果不佳，需要对组件B进行调试。

步骤403：判断所述第一日志文件中所述目标组件的输出日志信息与所述期待输出信息的偏差是否满足所述目标组件对应的输出偏差允许条件，如果否，则执行步骤404。

例如，第一日志文件中组件B的输出日志信息为“悟，空调，整了，心态”，由于该输出日志信息与期待输出信息不同，因此偏差不满足组件B的输出偏差允许条件，需要执行步骤404。而如果组件B的输出日志信息为“悟空，调整了，心态”，则满足输出偏差允许条件，无需执行步骤404。

步骤404：输出第二反馈消息。

本步骤输出的第二反馈消息用于指示需要对所述目标组件进行调试。这一消息可以通过多种可能的方式输出。例如，发送邮件或短消息，通过语音播报出来，通过显示屏显示出来等。此处对步骤404的具体实现方式不进行限定。需要说明的是，在实际应用中，输出的第二反馈消息可以提供给技术人员，例如第一系统的研发工程师，以便研发工程师根据第二反馈消息对该目标组件进行调试和优化。

在上述对日志文件的应用实施例中，因为第一日志文件中包含的日志信息条目是利用结构化的组件的名称、输入日志信息和输出日志信息生成的，因此，第一日志文件具有较高的可读性。当希望确定目标组件是否需要调试时，可以从第一日志文件中很容易地读取出该目标组件的输出日志信息，提升了读取信息的效率和便捷度。从而提升对组件输出的监测能力和调试效率。

下面结合图5描述利用日志文件进行竞品分析的一种实施例。

参见图5，该图为本申请实施例提供的一种应用日志文件进行竞品分析的方法流程图。在图5示意的方法步骤502执行之前，前述实施例中步骤201-202已经执行完毕。

步骤501：获取第二日志文件中第二访问请求对应的起始输入日志信息和结束输出日志信息。

需要说明的是，本实施例中第二日志文件为第二系统根据第二访问请求生成。第二系统是与第一系统提供的服务相同或相似的系统。例如，第一系统为知识服务系统，第二系统也是能够提供知识服务的竞品系统。

第二访问请求是向第二系统发起的访问请求，其中携带与第一访问请求中相同的服务项目信息，这表明用户端(或系统测试端，可以是测试人员)希望第二系统和第一系统实现相同的服务功能。例如，第二访问请求携带的服务项目信息为qgfx，第一访问请求携带的服务项目信息也为qgfx，因此用户端或测试端希望第二系统和第一系统均提供情感分析功能。

需要说明的是，第二系统的组件结构与第一系统的组件结构可能相同也可能不同。但是在组件功能的具体实现上可能存在差异。例如，对于同样的输入和同类型的请求，第一系统的输出可能优于第二系统的输出，也可能劣于第二系统的输出。为对第一系统和第二系统进行竞品对照分析，本实施例方法还进一步执行以下步骤。

步骤502：判断第一日志文件中所述第一访问请求对应的起始输入日志信息，和第二日志文件中所述第二访问请求对应的起始输入日志信息是否相同，如果是，则执行步骤503。

例如第一系统中与第一访问请求对应的组件包括组件A、组件B和组件E，该第一访问请求对应的起始输入日志信息为组件A的输入日志信息，该第一访问请求对应的结束输出日志信息为组件E的输出日志信息。

本步骤在具体实现时，可以将第一日志文件中针对第一访问请求生成的日志信息{“A-in”:“···”,“A-out”:“···”,“B-in”:“···”,“B-out”:“···”,“E-in”:“···”,“E-out”:“···”}记作L1；将第二日志文件中针对第二访问请求生成的日志信息{“X-in”:“···”,“X-out”:“···”}记作L2。其中，X-in为第二日志文件中第二访问请求对应的起始输入日志信息，X-out为第二日志文件中第二访问请求对应的结束输出日志信息。

作为一种可能的实现方式，将L1和L2进行合并，得到合并后的日志信息L3。L3的格式如下：

{“A-in”:“···”,“A-out”:“···”,“B-in”:“···”,“B-out”:“···”,“E-in”:“···”,“E-out”:“···”,“X-in”:“···”,“X-out”:“···”}

由于L1具备结构化特性和较高的可读性，因此形成的合并后的日志信息L3也具备结构化特性和较高的可读性。将L1和L2合并为L3提升竞品系统对照分析的便捷性。

可以理解的是，如果判断结果为是，表示第一系统在处理第一访问请求的输入和第二系统在处理第二访问请求的输入一致。这样保证了竞品对照分析的输入量一致，进而保证对照分析具有较高的准确性。

步骤503：判断第二日志文件中所述第二访问请求对应的结束输出日志信息是否优于所述第一日志文件中所述第一访问请求对应的结束输出日志信息，如果是，则执行步骤504。

本步骤在具体实现时有多种可能的实现方式，例如，可以采用评分机制对第一访问请求对应的结束输出日志信息和第二访问请求对应的结束输出日志信息分别评分，评分越高表示系统针对访问请求能够提供更好的服务效果。例如，情感分析越准确，评分越高。因此可以利用评分判断第二日志文件中所述第二访问请求对应的结束输出日志信息是否优于所述第一日志文件中所述第一访问请求对应的结束输出日志信息。

显然，如果本步骤判断结果为是，表示第一系统在面对第一访问请求提供的服务效果差于第二系统在面对同样的访问请求提供的服务效果。为保证第一系统相对于第二系统的服务效果优势，有必要对第一访问请求对应的服务功能组件进行调试。为此，执行步骤504。

步骤504：输出第三反馈消息。

本步骤输出的第三反馈消息用于指示需要对所述第一系统中所述第一访问请求对应的服务功能组件进行调试。例如，在第三反馈消息中提示第二日志文件中所述第二访问请求对应的结束输出日志信息X-out，并指示利用X-out对组件A→B→E进行调试。

这一消息可以通过多种可能的方式输出。例如，发送邮件或短消息，通过语音播报出来，通过显示屏显示出来等。此处对步骤504的具体实现方式不进行限定。需要说明的是，在实际应用中，输出的第三反馈消息可以提供给技术人员，例如第一系统的研发工程师，以便研发工程师根据第三反馈消息对该第一访问请求相关的组件进行调试和优化。从而提升第一系统的服务效果和相对于竞品的优势。

在上述对日志文件的应用实施例中，因为第一日志文件中包含的日志信息条目是利用结构化的组件的名称、输入日志信息和输出日志信息生成的，因此，第一日志文件具有较高的可读性。当需要进行竞品系统的分析对照时，能够很容易地从第一日志文件中读取到针对第一访问请求的起始输入日志信息及结束输出日志信息，从而便利地进行对照和分析，迅捷判断是否需要对相关组件进行调试。可见，本实施例方法可以提升竞品系统分析与调试的效率。

在前述方法实施例中，由于日志文件中日志信息的格式具备结构化特征，因此无需再将日志信息向其他介质持久化。例如，无需将这些日志信息写入数据库或特定的文件系统中。从而降低了输入输出成本和存储成本。这也给系统的开发、运维和优化带来了较大的便利。

基于前述实施例提供的生成日志文件的方法，相应地，本申请还提供一种生成日志文件的装置。下面结合实施例和附图对该装置的具体实现进行描述。

装置实施例

参见图6，该图为本申请实施例提供的一种生成日志文件的装置的结构示意图。该装置应用于第一线程，该线程是第一系统的一个可调度的线程。第一系统包括日志记录组件和多个服务功能组件，日志记录组件包括记录结构，记录结构包括：组件名称填入位置和日志信息文本填入位置。

如图6所示，该生成日志文件的装置包括：

第一调用模块601，用于根据对所述第一系统的第一访问请求调用所述请求对应的服务功能组件，以使所述服务功能组件处理所述请求；

第二调用模块602，用于调用所述日志记录组件，以使所述日志记录组件将所述请求对应的服务功能组件的名称填入所述组件名称填入位置，并将所述请求对应的服务功能组件的输入日志信息和输出日志信息填入所述日志信息文本填入位置；

日志文件生成模块603，用于当确定所述请求结束时，利用所述日志记录组件按照所述记录结构填入的所述服务功能组件的名称、输入日志信息和输出日志信息生成一个日志信息条目，将所述条目写入第一日志文件。

在本申请中，第一系统的线程之间相互独立，线程不会同时处理多个请求。对于任一可调度的线程，当调度该线程处理对第一系统的第一访问请求时，应用该装置的线程不但调用该请求对应的服务功能组件，还调用日志记录组件。当服务功能组件处理请求时，日志记录组件记录各个服务功能组件的名称以及各个服务功能组件处理该请求的输入日志信息和输出日志信息。日志记录组件中包括记录结构，记录结构中包括组件名称填入位置，各个服务功能组件的名称填入其中；记录结构还包括日志信息文本填入位置，各个服务功能组件的输入日志信息和输出日志信息填入其中。进而，第一访问请求所对应的服务功能组件的名称、输入日志信息和输出日志信息被结构化地存入日志记录组件中。当该请求结束时，利用日志记录组件中结构化存入的该请求对应的组件名称以及日志信息生成第一日志文件。

作为一种可能的实现方式，装置还包括：

所述第一调用模块601，具体可以包括：

该装置通过调用日志记录组件生成的第一日志文件具有多种应用方式。例如可以应用于定位需要调试的组件，还可以应用于进行竞品系统的对照分析。

作为一种可能的实现方式，上文描述的装置还可以包括：

因为第一日志文件中包含的日志信息条目是利用结构化的组件的名称、输入日志信息和输出日志信息生成的，因此，第一日志文件具有较高的可读性。具有较高可读性的第一日志文件在进行组件定位和组件调试等方面具有较高的可用性，提升了对组件定位和组件调试的效率和便捷度。

作为另一种可能的实现方法，上文描述的装置中，日志期待文件获取模块还可用于获得所述请求对应的服务功能组件之中目标组件的期待输出信息；

因为第一日志文件中包含的日志信息条目是利用结构化的组件的名称、输入日志信息和输出日志信息生成的，因此，第一日志文件具有较高的可读性。当希望确定目标组件是否需要调试时，可以从第一日志文件中很容易地读取出该目标组件的输出日志信息，提升了读取信息的效率和便捷度。从而提升对组件输出的监测能力和调试效率。

作为又一种可能的实现方法，上文描述的装置中，还可以包括：

因为第一日志文件中包含的日志信息条目是利用结构化的组件的名称、输入日志信息和输出日志信息生成的，因此，第一日志文件具有较高的可读性。当需要进行竞品系统的分析对照时，能够很容易地从第一日志文件中读取到针对第一访问请求的起始输入日志信息及结束输出日志信息，从而便利地进行对照和分析，迅捷判断是否需要对相关组件进行调试。可见，本实施例装置可以提升竞品系统分析与调试的效率。

基于前述实施例提供的生成日志文件的方法和装置，本申请实施例还提供了一种计算机可读存储介质。

该存储介质上存储有程序，该程序被处理器执行时实现本申请前述方法实施例保护的生成日志文件的方法中部分或全部步骤。

该存储介质可以是U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

基于前述实施例提供的生成日志文件的方法、装置和存储介质，本申请实施例提供了一种处理器。该处理器用于运行程序，其中，所述程序运行时执行前述方法实施例保护的生成日志文件的方法中部分或全部步骤。

基于前述实施例提供的存储介质和处理器，本申请还提供了一种生成日志文件的设备。

参见图7，该图为本实施例提供的生成日志文件的设备的硬件结构图。

如图7所示，生成日志文件的设备包括：存储器701、处理器702、通信总线703和通信接口704。该设备具体可以为运行第一系统的设备。

其中，存储器701上存储有可在处理器上运行的程序，程序执行时实现本申请前述方法实施例提供的生成日志文件的方法中部分或全部步骤。存储器701可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

该设备中，处理器702与存储器701通过通信总线传输信令、逻辑指令等。该设备能够通过通信接口704与其它设备进行通信交互。

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

以上所述，仅为本申请的一种具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。

Claims

1.一种生成日志文件的方法，其特征在于，应用于第一线程，所述第一线程为第一系统的一个可调度的线程，所述第一系统包括日志记录组件和多个服务功能组件，所述日志记录组件包括记录结构，所述记录结构包括：组件名称填入位置和日志信息文本填入位置；所述方法包括：

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

获得服务项目信息与服务功能组件的对应关系；

调用所述请求中携带的服务项目信息对应的服务功能组件。

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

确定各个服务功能组件对应的输出偏差允许条件；

在所述将所述条目写入第一日志文件后，所述方法还包括：

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

确定所述目标组件对应的输出偏差允许条件；

在所述将所述条目写入第一日志文件后，所述方法还包括：

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

在所述将所述条目写入第一日志文件后，所述方法还包括：

6.一种生成日志文件的装置，其特征在于，应用于第一线程，所述第一线程为第一系统的一个可调度的线程，所述第一系统包括日志记录组件和多个服务功能组件，所述日志记录组件包括记录结构，所述记录结构包括：组件名称填入位置和日志信息文本填入位置；所述装置包括：

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

所述第一调用模块，具体包括：

8.根据权利要求6或7所述的装置，其特征在于，还包括：

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当所述程序被处理器运行时，实现如权利要求1-5任一项所述的生成日志文件的方法。

10.一种处理器，其特征在于，用于运行计算机程序，所述程序运行时执行如权利要求1-5任一项所述的生成日志文件的方法。