CN114726752A - 日志信息的处理方法、装置、终端及存储介质 - Google Patents

Abstract

本申请提供了一种日志信息的处理方法、装置、终端及存储介质，适用于数据处理技术领域，该方法包括：向服务端发送包含预设请求头日志参数的请求消息，请求消息用于客户端与服务端的业务交互；接收服务端针对预设请求头日志参数返回的日志信息；日志信息为服务端接收到请求消息后，基于预设请求头日志参数收集到的实时的日志信息。应用本申请提供的日志信息的处理方法，可以监控系统的实时状态，提高查找问题的效率与准确性，精准定位到每一次请求。并且日志信息的处理过程无需登录服务端，避免暴露存储在服务端上的数据，可以降低获取日志信息时存在的数据安全风险。

Description

日志信息的处理方法、装置、终端及存储介质

技术领域

本申请属于数据处理技术领域，尤其涉及一种日志信息的处理方法、装置、终端及存储介质。

背景技术

在包含有客户端和服务端的系统中，客户端可以向服务端发送请求消息，服务端接收到该请求消息后，可以向客户端返回响应消息。在客户端发出请求消息至服务端返回响应消息的这段时间内，系统会产生一些日志文件。当客户端的用户需要使用这些日志文件时，需要登录服务端并调用这些日志文件。但是，登录服务端的操作会导致存储在服务端上的数据存在安全风险，例如泄露风险和篡改风险，因此存在数据安全风险较高的问题。

发明内容

有鉴于此，本申请实施例提供了日志信息的处理方法、装置、终端及存储介质，可以降低获取日志信息时存在的数据安全风险。

本申请实施例的第一方面提供了一种日志信息的处理方法，包括：

在客户端与服务端交互的过程中，向服务端发送包含预设请求头日志参数的请求消息，请求消息用于客户端与服务端的业务交互。

接收服务端针对预设请求头日志参数返回的日志信息。日志信息为服务端接收到请求消息后，基于预设请求头日志参数收集到的实时的日志信息。

在第一方面的第一种可能的实现方式中，向服务端发送包含预设请求头日志参数的请求消息，包括：

拦截客户端发出的请求消息。可以通过设置预设条件，筛选拦截符合该预设条件的请求消息。例如，获取所有类型的请求消息，通过黑名单模式，筛选出需要的请求消息。

在请求消息内插入预设请求头日志参数。还可以在请求消息内插入预设返回参数和预设标识参数。预设标识参数分别与预设请求头日志参数和预设返回参数关联。日志信息可以由预设返回参数带回。

转发包含预设请求头日志参数的请求消息至服务端。

在第一方面的第二种可能的实现方式中，在接收服务端针对预设请求头日志参数返回的日志信息之后，还包括：

对日志信息进行汇总分析，得到汇总分析信息。

基于汇总分析信息，对日志信息进行展示。

在第一方面的第三种可能的实现方式中，在向服务端发送包含预设请求头日志参数的请求消息之后，还包括：

接收服务端针对预设请求头日志参数返回的汇总分析信息。汇总分析信息为服务端对日志信息进行汇总分析的信息。

基于汇总分析信息，对日志信息进行展示。

基于第一方面的第二种可能实现方式或者第三种可能实现方式，在第一方面的第四种可能的实现方式中，对日志信息进行汇总分析，包括：

基于分类信息库，确定日志信息的类别。分类信息库包括类别和归属于类别的日志范围。例如，根据属性不同，日志信息可以包括业务日志、数据库日志和服务器日志等类别。根据重要性程度不同，日志信息可以包括多个不同类别(也可称为级别)。例如Debug(需要在调试过程中输出的信息)、Info(需要持续输出的信息)、Warn(警告级别的信息)、Error(错误信息)和Fatal(严重错误信息)等级别。

因此，可以基于日志信息的属性、重要性程度或者其他衡量标准，对日志信息进行分类。根据日志信息的类别，有选择性地展示日志信息，以及选择展示日志信息的形式。

本申请实施例的第二方面提供了一种日志信息的处理方法，包括：

在客户端与服务端交互的过程中，接收发送端发送的包含预设请求头日志参数的请求消息，请求消息用于客户端与服务端的业务交互。应理解，发送端可以是客户端，也可以是用于转发请求消息的第三终端。

基于预设请求头日志参数，收集实时的日志信息。

向发送端发送日志信息。

在第二方面的第一种可能的实现方式中，在基于预设请求头日志参数，收集实时的日志信息之后，还包括：

对日志信息进行汇总分析，得到汇总分析信息。

向发送端发送汇总分析信息。发送端基于该汇总分析信息，对日志信息进行展示。

基于第二方面的第一种可能实现方式，在第二方面的第二种可能的实现方式中，对日志信息进行汇总分析，包括：

基于分类信息库，确定日志信息的类别。分类信息库包括类别和归属于类别的日志范围。

本申请实施例的第三方面提供了一种日志信息的处理装置，包括：

第一发送模块，用于在客户端与服务端交互的过程中，向服务端发送包含预设请求头日志参数的请求消息，请求消息用于客户端与服务端的业务交互。

第一接收模块，用于接收服务端针对预设请求头日志参数返回的日志信息。日志信息为服务端接收到请求消息后，基于预设请求头日志参数收集到的实时的日志信息。

本申请实施例的第四方面提供了一种日志信息的处理装置，包括：

第二接收模块，用于在客户端与服务端交互的过程中，接收发送端发送的包含预设请求头日志参数的请求消息，请求消息用于客户端与服务端的业务交互。

收集模块，用于基于预设请求头日志参数，收集实时的日志信息。

第二发送模块，用于向发送端发送日志信息。

本申请实施例的第五方面提供了一种终端，终端包括存储器、处理器，存储器上存储有可在处理器上运行的计算机程序，处理器执行该计算机程序时实现上述第一方面所述日志信息的处理方法的步骤，或者实现上述第二方面所述日志信息的处理方法的步骤。

本申请实施例的第六方面提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时实现上述第一方面所述日志信息的处理方法的步骤，或者实现上述第二方面所述日志信息的处理方法的步骤。

本申请实施例的第七方面提供了一种计算机程序产品，当计算机程序产品在终端上运行时，使得终端执行上述第一方面所述日志信息的处理方法的步骤，或者执行上述第二方面所述日志信息的处理方法的步骤。

可以理解的是，上述第二方面至第七方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

本申请实施例与现有技术相比存在的有益效果是：

在客户端与服务端交互的过程中，向服务端发送包含预设请求头日志参数的请求消息。在服务端接收到该请求消息后，服务端基于该预设请求头日志参数收集实时的日志信息。该实时的日志信息可以包括客户端与服务端交互过程中产生的日志信息。由于是实时的日志信息，在获得该日志信息后，可以监控系统的实时状态。例如，监控业务是否正常进行、数据库是否正常以及服务器是否正常，为快速查找、定位系统问题提供基础。应用该日志信息的处理方法，可以提高查找问题的效率与准确性，精准定位到每一次请求。上述日志信息的处理过程，无需登录服务端，避免暴露存储在服务端上的数据，因此可以降低获取日志信息时存在的数据安全风险。

附图说明

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

图1是本申请一实施例提供的日志信息的处理方法的流程示意图；

图2是本申请一实施例提供的日志信息的处理方法的流程示意图；

图3是本申请一实施例提供的日志信息的处理方法的流程示意图；

图4是本申请一实施例提供的日志信息的处理方法的流程示意图；

图5是本申请一实施例提供的日志信息的处理方法的流程示意图；

图6是本申请一实施例提供的日志信息的处理方法的流程示意图；

图7是本申请一实施例提供的日志信息的处理方法的流程示意图；

图8是本申请一实施例提供的日志信息的处理装置的结构示意图；

图9是本申请一实施例提供的日志信息的处理装置的结构示意图；

图10是本申请一实施例提供的终端的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

在包含有客户端和服务端的系统中，客户端可以向服务端发送请求消息，服务端接收到该请求消息后，可以向客户端返回响应消息。在客户端发出请求消息至服务端返回响应消息的这段时间内，系统会产生一些日志文件。日志文件可以存储在服务端上。因此，当客户端的用户需要使用日志文件时，需要登录服务端并调用这些日志文件。其中，登录服务端的操作会导致存储在服务端上的数据存在安全风险，例如泄露风险和篡改风险，因此存在数据安全风险较高的问题。并且，由于日志文件是存储在服务端的，因此客户端登录服务端上调用的日志文件通常属于历史数据，不能反应系统的实时状态，故无法监控系统的实时状态，不利于快速查找、定位系统问题。

有鉴于此，本申请实施例提供了一种日志信息的处理方法，可应用在终端上。该日志信息的处理过程，不仅无需登录服务端，避免暴露存储在服务端上的数据，降低获取日志信息时存在的数据安全风险；而且可以帮助用户监控系统的实时状态。当系统出现问题时，可借此快速查找、定位系统问题。

该日志信息的处理方法的实现过程为：在客户端与服务端交互的过程中，发送端向服务端发生包含预设请求头日志参数的请求消息，该请求消息用于客户端与服务端的业务交互。当服务端接收到该请求消息后，基于该预设请求头日志参数收集实时的日志信息，并将收集到的日志信息返回给发送端。由于该日志信息为实时的，可以包括客户端与服务端交互过程中产生的日志信息。因此该日志信息可以反应系统的实时状态，发送端可以借此监控系统的实时状态，也可以借此快速查找、定位系统问题，且无需登录服务端。

需要说明的是，发送端可以是客户端，也可以是用于转发请求消息的第三终端，本申请实施例对此不作具体限定。

本申请实施例提供的日志信息的处理方法可以应用于手机、平板电脑和可穿戴设备等终端上，此时终端即为本申请实施例提供的日志信息的处理方法的执行主体，本申请实施例对终端的具体类型不作任何限制。

因此，在客户端与服务端进行业务交互的过程中：当发送端为客户端时，发送端(或客户端)发送包含预设请求头日志参数的请求消息。当发送端为第三终端时，客户端发送原始的请求消息，第三终端在该请求消息内插入预设请求头日志参数，并转发包含预设请求头日志参数的请求消息至服务端；或者客户端发送包含预设请求头日志参数的请求消息，第三终端转发该请求消息。应理解，第三终端可以是硬件实体终端，也可以是软件虚拟终端。

为了说明本申请所述的技术方案，下面通过具体实施例来进行说明。

图1示出了本申请一实施例提供的日志信息的处理方法的流程示意图，该日志信息的处理方法的执行主体为发送端，详述如下：

S101、在客户端与服务端交互的过程中，向服务端发送包含预设请求头日志参数的请求消息，请求消息用于客户端与服务端的业务交互。

在一些实施例中，当客户端与服务端进行业务交互时，一般是由客户端发出请求消息，然后服务端返回响应消息。本申请实施例对业务的具体类型不作限定，技术人员可以根据实际需要，设置系统能够实现的业务类型。作为示例而非限定，业务可以包括调试、登录、数据库字段修改等。

应理解，根据传输协议的不同，请求消息的类型存在不同。本申请实施例对请求消息的协议类型不作限定，技术人员可以根据实际需要，设置请求消息的协议类型。作为示例而非限定，在一些实施例中，请求消息为HTTP(Hyper Text Transfer Protocol，超文本传输协议)请求。

应理解，请求消息一般包括有请求头。请求头包含许多有关的客户端环境和请求正文的有用信息。在本申请实施例中，请求头还包含有预设请求头日志参数。设置该预设请求头日志参数的一个目的在于，通知服务端基于该预设请求头日志参数，收集相关的日志信息。

在另一些实施例中，当系统还包含用于转发请求消息的第三终端时，客户端发送的请求消息，可以经由第三终端发送给服务端。因此，客户端发送的请求消息，可以包含预设请求头日志参数，然后经由第三终端转发至服务端；也可以不包含预设请求头日志参数，然后由第三终端将预设请求头日志参数插入请求消息，再将插入有预设请求头日志参数的请求消息转发给服务端。

基于上述描述，图2示出了本申请一实施例提供的日志信息的处理方法的流程示意图。其中，步骤S101可以包括以下步骤：S201至S203。

S201、拦截客户端发出的请求消息。作为示例而非限定，当发送端为客户端时，发送请求消息的执行模块为客户端的发送模块；拦截该请求消息的执行模块为客户端的拦截模块。作为示例而非限定，当发送端为第三终端时，发送请求消息的执行模块为客户端的发送模块；拦截该请求消息的执行模块为第三终端的拦截模块。

S202、在请求消息内插入预设请求头日志参数。作为示例而非限定，当发送端为客户端时，插入该预设请求头日志参数的执行模块为客户端的插入模块。作为示例而非限定，当发送端为第三终端时，插入该预设请求头日志参数的执行模块为第三终端的插入模块。

S203、转发包含预设请求头日志参数的请求消息至服务端。作为示例而非限定，当发送端为客户端时，转发该请求消息的执行模块为客户端的转发模块。作为示例而非限定，当发送端为第三终端时，转发该请求消息的执行模块为第三终端的转发模块。

需要说明的是，设置第三终端的一个好处在于，可以分隔开客户端与服务端之间的直接连接关系，使得客户端与服务端之间通过第三终端实现间接连接。该间接连接有利于提高服务端的数据安全性，降低数据安全风险。

在步骤S201中，可以拦截客户端发出的所有请求消息，也可以拦截客户端发出的部分请求消息，本申请实施例对此不作具体限定。作为示例而非限定，技术人员根据实际需要，可以设置预设条件，筛选拦截符合该预设条件的请求消息。例如，获取所有类型的请求消息，通过黑名单模式，筛选出需要的请求消息。

因此，服务端基于筛选拦截出的请求消息，返回针对预设请求头日志参数的日志信息。通过筛选拦截需要的请求消息，可以避免服务端收集不必要的日志信息，降低系统负担。

在步骤S202中，为了使得返回的日志信息和对应的请求消息一一对应，还可以插入预设返回参数和预设标识参数。预设标识参数分别与预设请求头日志参数和预设返回参数关联。日志信息可以由预设返回参数带回。

继续参阅图1所示。在步骤S101之后，日志信息的处理方法还包括：

S102、接收服务端针对预设请求头日志参数返回的日志信息。该日志信息为服务端接收到请求消息后，基于预设请求头日志参数收集到的实时的日志信息。

当服务端接收到请求消息后，可以基于预设请求头日志参数收集实时的日志信息。

需要说明的是，为了可以监控系统的实时状态，本申请实施例收集的是实时的日志信息。本申请实施例不对“实时的日志信息”作具体限定及定义，技术人员可以根据实际需要，基于监控系统的实时状态的目的，选择收集的日志内容以及产生这些日志内容的时间。

在一些实施例中，“实时的日志信息”针对的是在客户端与服务端交互的过程中，基于请求消息的预设请求头日志参数收集的实时日志信息。该实时的日志信息可以反应在该业务交互过程中系统的实时状态。

作为示例而非限定，对于一次业务交互，“实时的日志信息”的时间范围可以是从服务端接收到该请求消息至针对该请求消息而返回响应消息之间的时间段。

作为示例而非限定，对于一次业务交互，“实时的日志信息”的时间范围可以是从服务端接收到上一个请求消息至服务端接收到当前请求消息之间的时间段。

基于此，当接收到服务端针对预设请求头日志参数返回的实时的日志信息，可以借此监控系统的实时状态，为快速查找、定位系统问题提供基础。

应理解，日志是设备、系统及服务程序等，在运作时产生的事件记录。日志信息可以包含日期、时间、使用者及动作等相关操作的描述。因此，日志信息的具体内容和记载形式，技术人员可以根据实际需要设置，本申请实施例不作具体限定。

作为示例而非限定，日志信息可以包括业务日志、数据库日志和服务器日志。例如，业务日志包括调试日志、数据库字段修改记录、操作人、修改时间、当前站点的在线用户数、业务逻辑判断信息和警告日志等。又例如，数据库日志包括在请求消息进入数据库程序阶段产生的日志，如执行的SQL(Structured Query Language，结构化查询语言)语句、执行时间、输入参数、返回结果等信息。再例如，服务器日志包括CPU(central processingunit，中央处理器)、内存、I/O(input/output，输入输出接口)和网络等信息。

基于上述描述，本申请实施例提供的日志信息的处理方法，可以获得实时的日志信息，该日志信息可以包括客户端与服务端交互过程中产生的日志信息。利用该日志信息，可以监控系统的实时状态。例如，监控业务是否正常进行、数据库是否正常以及服务器是否正常，为快速查找、定位系统问题提供基础。上述日志信息的处理过程，无需登录服务端，避免暴露存储在服务端上的数据，因此可以降低获取日志信息时存在的数据安全风险。

图3示出了本申请一实施例提供的日志信息的处理方法的流程示意图。在接收到服务端针对预设请求头日志参数返回的日志信息之后，日志信息的处理方法还包括：

S301、对日志信息进行汇总分析，得到汇总分析信息。

S302、基于汇总分析信息，对日志信息进行展示。

为了更好地监控系统的状态，可以对日志信息进行汇总分析，然后基于汇总分析信息，对日志信息进行展示。作为示例而非限定，可以根据汇总分析结果，展示全部或者部分日志信息。本申请实施例对展示的形式不作具体限定。例如，可以以图形界面、弹出窗口、短信、语音播报等形式进行展示。

作为示例而非限定，汇总分析可以包括对日志信息的分类。例如，根据属性不同，日志信息可以包括业务日志、数据库日志和服务器日志等类别。根据重要性程度不同，日志信息可以包括多个不同级别，例如Debug、Info、Warn、Error和Fatal等级别。需要说明的是，此处的级别分类(分级)可以看作是一种分类方式。

因此，对日志信息进行汇总分析，可以包括以下步骤：

基于分类信息库，确定日志信息的类别。分类信息库包括类别和归属于类别的日志范围。

基于上述描述，可以基于日志信息的属性、重要性程度或者其他衡量标准，对日志信息进行分类。根据日志信息的类别，有选择性地展示日志信息，以及选择展示日志信息的形式。例如，在步骤S302中，可以有选择性地展示业务日志、数据库日志和服务器日志等类别日志，也可以有选择性地展示Debug、Info、Warn、Error和Fatal等级别日志。

作为示例而非限定，可以根据业务日志的时间和级别，对业务日志进行分类。作为示例而非限定，可以根据数据库日志的时间和返回数据量，对数据库日志进行分类。作为示例而非限定，可以根据服务器的CPU占有率、内存占有率、I/O读写速度和网络输入输出速度，对服务器日志进行分类。

作为示例而非限定，Debug级别日志，是指业务日志中的调试日志，用于调试人员判断业务流程是否正确。

作为示例而非限定，Info级别日志，是指业务逻辑日志(不含警告日志)和数据库日志。

作为示例而非限定，Warn级别日志可以包括：执行时长在第一预设范围内的业务日志；业务日志中的警告日志；触发了补偿机制且补偿次数在预设阈值范围内、但重试成功的业务日志；逻辑读取次数在第二预设范围内的数据库日志；返回数据量在第三预设范围内的数据库日志；CPU平均占有率在第四预设范围内的服务器日志；内存平均占有率在第五预设范围内的服务器日志；磁盘平均读延迟时长在第六预设范围内的服务器日志；以及磁盘平均写延迟时长在第七预设范围内的服务器日志。

作为示例而非限定，Warn级别日志可以包括：执行时长超过第一预设数值的业务日志；触发了补偿机制且补偿次数在预设阈值范围内、但重试不成功的业务日志；逻辑读取次数大于第二预设数值的数据库日志；返回数据量大于第三预设数值的数据库日志；CPU平均占有率大于第四预设数值的服务器日志；内存平均占有率大于第五预设数值的服务器日志；磁盘平均读延迟时长大于第六预设数值的服务器日志；以及磁盘平均写延迟时长大于第七预设数值的服务器日志。

作为示例而非限定，Fatal级别日志可以包括：在客户端与服务端交互的过程中，出现的任何系统性错误、不可预见性错误、代码执行错误等致命性错误。应理解，本申请实施例对致命性错误的具体内容不作限定，上述描述仅作为解释而非对致命性错误的定义，技术人员可以根据实际需要进行设置，以规定哪些错误属于致命性错误。

还应理解，上述出现的第一预设范围、预设阈值范围、第二预设范围、第三预设范围、第四预设范围、第五预设范围、第六预设范围和第七预设范围，它们的具体数值范围可以根据实际需要进行设置，本申请实施例不作具体限定；上述出现的第一预设数值、第二预设数值、第三预设数值、第四预设数值、第五预设数值、第六预设数值和第七预设数值，它们的具体数值可以根据实际需要进行设置，本申请实施例不作具体限定。

在一些实施例中，可以将汇总分析的步骤流程放在服务端进行。图4示出了本申请一实施例提供的日志信息的处理方法的流程示意图。在图4所示实施例中，在步骤S101之后，日志信息的处理方法还包括以下步骤：

401、接收服务端针对预设请求头日志参数返回的日志信息和汇总分析信息。日志信息为服务端接收到请求消息后，基于预设请求头日志参数收集到的实时的日志信息。汇总分析信息为服务端对日志信息进行汇总分析的信息。

402、基于汇总分析信息，对日志信息进行展示。

关于汇总分析的过程、原理以及具体内容可以参考图3所示实施例中步骤S301和S302的说明，此处不再赘述。

基于上述实施例的描述，当服务端收集到实时的日志信息之后，对日志信息进行汇总分析的步骤流程可以放在服务端进行，也可以放在发送端(客户端或者第三终端)进行。将汇总分析的步骤流程放在服务端进行的一个好处在于，可以统一不同发送端的汇总分析信息，方便汇总分析信息的数据管理。将汇总分析的步骤流程放在发送端进行的一个好处在于，可以方便发送端根据实际需要，自行设置汇总分析的内容，实现发送端的个性化配置。

图5示出了本申请一实施例提供的日志信息的处理方法的流程示意图，该日志信息的处理方法的执行主体为服务端，详述如下：

S501、在客户端与服务端交互的过程中，接收发送端发送的包含预设请求头日志参数的请求消息，请求消息用于客户端与服务端的业务交互。应理解，发送端可以是客户端，也可以是用于转发请求消息的第三终端。

S502、基于预设请求头日志参数，收集实时的日志信息。

S503、向发送端发送日志信息。

与图1至图4所示实施例相比，本申请实施例的执行主体为服务端。在服务端接收到发送端发送的包含预设请求头日志参数的请求消息时，服务端基于预设请求头日志参数，收集实时的日志信息，然后向发送端返回日志信息。

由于发送端如何发送请求消息、如何在请求消息中插入预设请求头日志参数以及服务端如何收集日志信息和返回日志信息已经在上述实施例中阐明，具体可参考图1和图2所示实施例中步骤S101、S102、S201、S202和S203的说明，因此此处不再赘述。

本申请实施例提供的日志信息的处理方法，在客户端与服务端交互的过程中，服务端接收包含预设请求头日志参数的请求消息。在服务端接收到该请求消息后，服务端基于该预设请求头日志参数收集实时的日志信息。该日志信息可以包括客户端与服务端交互过程中产生的日志信息。由于是实时的日志信息，在获得该日志信息后，发送端可以监控系统的实时状态，为快速查找、定位系统问题提供基础。应用该日志信息的处理方法，可以提高查找问题的效率与准确性，精准定位到每一次请求。上述日志信息的处理过程，无需登录服务端，避免暴露存储在服务端上的数据，因此可以降低获取日志信息时存在的数据安全风险。

图6示出了本申请一实施例提供的日志信息的处理方法的流程示意图，在步骤S502之后，日志信息的处理方法，还包括：

S601、对日志信息进行汇总分析，得到汇总分析信息。

S602、向发送端发送日志信息和汇总分析信息。发送端基于该汇总分析信息，对日志信息进行展示。

在一些实施例中，对日志信息进行汇总分析，包括以下步骤：

基于分类信息库，确定日志信息的类别。分类信息库包括类别和归属于类别的日志范围。

由于如何进行分类已经在上述实施例中阐明，具体可参考图3和图4所示实施例中步骤S301、S302、S401和S402的说明，因此此处不再赘述。

在本申请的一个具体应用实施例中，提供了一种日志信息的处理方法，其流程示意图如图7所示，包括：

S701、发送端筛选拦截请求消息。发送端为客户端，该请求消息由客户端的发送模块发出，通过客户端的拦截模块筛选拦截需要的请求消息。该请求消息为HTTP请求。

S702、在请求消息内插入预设请求头日志参数、预设返回参数和预设标识参数。通过客户端的插入模块插入上述参数。预设标识参数分别与预设请求头日志参数和预设返回参数关联。预设请求头日志参数包括业务日志参数、数据库日志参数和服务器日志参数。日志信息包括业务日志、数据库日志和服务器日志。日志信息由预设返回参数带回。

S703、转发包含预设请求头日志参数、预设返回参数和预设标识参数的请求消息至服务端。通过客户端的转发模块转发该请求消息。拦截模块、插入模块和转发模块可以集成在一个插件(是一种遵循一定规范的应用程序接口编写出来的程序)中，该插件可以基于协议调试代理工具进行工作。例如，协议调试代理工具为fiddler(一种http协议调试代理工具)工具。

S704、服务端基于预设请求头日志参数，收集实时的日志信息。

S705、服务端对日志信息进行汇总分析，得到汇总分析信息。例如，服务端基于分类信息库，确定日志信息的类别。

S706、服务端封装、加密日志信息和汇总分析信息。

S707、服务端将日志信息和汇总分析信息返回给客户端。

S708、客户端解密日志信息和汇总分析信息。

上述封装、加密和解密的过程可以提高数据传输的安全性。

S709、客户端基于日志信息的类别，对日志信息进行展示。

该实施例提供的日志信息的处理方法，可以快速查找、定位系统问题，提高查找问题的效率与准确性，精准定位到每一次请求。并且，日志信息的处理过程，无需登录服务端，避免暴露存储在服务端上的数据，因此可以降低获取日志信息时存在的数据安全风险。

应当理解地，在无逻辑冲突的前提下，上述各个申请实施例之间可以相互组合实施，以适应实际的应用需求。这些组合后得到的具体实施例或实施方案，仍属于本申请的保护范围内。

对应于上述实施例所述的日志信息的处理方法，图8示出了本申请一实施例提供的日志信息的处理装置的结构示意图，为了便于说明，仅示出了与本申请实施例相关的部分。

请参阅图8所示，该日志信息的处理装置，包括：

第一发送模块81，用于在客户端与服务端交互的过程中，向服务端发送包含预设请求头日志参数的请求消息，请求消息用于客户端与服务端的业务交互。

第一接收模块82，用于接收服务端针对预设请求头日志参数返回的日志信息。日志信息为服务端接收到请求消息后，基于预设请求头日志参数收集到的实时的日志信息。

在一些实施例中，第一发送模块81包括：

拦截单元，用于拦截客户端发出的请求消息。

插入单元，用于在请求消息内插入预设请求头日志参数。

转发单元，用于转发包含预设请求头日志参数的请求消息至服务端。

在一些实施例中，第一接收模块82还用于接收服务端针对预设请求头日志参数返回的汇总分析信息。汇总分析信息为服务端对日志信息进行汇总分析的信息。日志信息的处理装置，还包括：第一展示模块，用于基于汇总分析信息，对日志信息进行展示。在另一些实施例中，日志信息的处理装置，还包括：第一分析模块，用于对日志信息进行汇总分析，得到汇总分析信息。第二展示模块，用于基于汇总分析信息，对日志信息进行展示。作为示例而非限定，第一分析模块包括：第一确定单元，用于基于分类信息库，确定日志信息的类别。分类信息库包括类别和归属于类别的日志范围。

本申请实施例提供的日志信息的处理装置中各模块实现各自功能的过程，具体可参考前述图1所示实施例以及其他相关方法实施例的描述，此处不再赘述。

对应于上述实施例所述的日志信息的处理方法，图9示出了本申请一实施例提供的日志信息的处理装置的结构示意图，为了便于说明，仅示出了与本申请实施例相关的部分。

请参阅图9所示，该日志信息的处理装置，包括：

第二接收模块91，用于在客户端与服务端交互的过程中，接收发送端发送的包含预设请求头日志参数的请求消息，请求消息用于客户端与服务端的业务交互。应理解，发送端可以是客户端，也可以是用于转发请求消息的第三终端。

收集模块92，用于基于预设请求头日志参数，收集实时的日志信息。

第二发送模块93，用于向发送端发送日志信息。

在一些实施例中，该日志信息的处理装置，还包括：

第二分析模块，用于对日志信息进行汇总分析，得到汇总分析信息。

第二发送模块93还用于向发送端发送汇总分析信息。发送端基于该汇总分析信息，对日志信息进行展示。

在一些实施例中，第二分析模块，包括：

第二确定单元，用于基于分类信息库，确定日志信息的类别。分类信息库包括类别和归属于类别的日志范围。

本申请实施例提供的日志信息的处理装置中各模块实现各自功能的过程，具体可参考前述图5所示实施例以及其他相关方法实施例的描述，此处不再赘述。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”、“包含”等指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。还应理解的是，虽然术语“第一”、“第二”等在一些本申请实施例中用来描述各种元素，但是这些元素不应该受到这些术语的限制。这些术语只是用来将一个元素与另一元素区分开。例如，第一表格可以被命名为第二表格，并且类似地，第二表格可以被命名为第一表格，而不背离各种所描述的实施例的范围。第一表格和第二表格都是表格，但是它们不是同一表格。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

本申请实施例提供的日志信息的处理方法可以应用于手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)等终端上，本申请实施例对终端的具体类型不作任何限制。

例如，所述终端可以是WLAN中的站点(STAION，ST)，可以是蜂窝电话、无绳电话、会话启动协议(Session InitiationProtocol，SIP)电话、无线本地环路(Wireless LocalLoop，WLL)站、个人数字处理(Personal Digital Assistant，PDA)设备、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、车联网终端、电脑、膝上型计算机、手持式通信设备、手持式计算设备、卫星无线设备、无线调制解调器卡、电视机顶盒(set top box，STB)、用户驻地设备(customer premise equipment，CPE)和/或用于在无线系统上进行通信的其它设备以及下一代通信系统，例如，5G网络中的终端或者未来演进的公共陆地移动网络(Public Land Mobile Network，PLMN)网络中的终端等。

作为示例而非限定，当所述终端为可穿戴设备时，该可穿戴设备还可以是应用穿戴式技术对日常穿戴进行智能化设计、开发出可以穿戴的设备的总称，如眼镜、手套、手表、服饰及鞋等。可穿戴设备即直接穿在身上，或是整合到用户的衣服或配件的一种便携式设备。可穿戴设备不仅仅是一种硬件设备，更是通过软件支持以及数据交互、云端交互来实现强大的功能。广义穿戴式智能设备包括功能全、尺寸大、可不依赖智能手机实现完整或者部分的功能，如智能手表或智能眼镜等，以及只专注于某一类应用功能，需要和其它设备如智能手机配合使用，如各类进行体征监测的智能手环、智能首饰等。

图10是本申请一实施例提供的终端的结构示意图。如图10所示，该实施例的终端10包括：至少一个处理器100(图10中仅示出一个)、存储器101，存储器101中存储有可在处理器100上运行的计算机程序102。处理器100执行计算机程序102时实现上述各个日志信息的处理方法实施例中的步骤，例如图1所示的步骤101和步骤102；或者图5所示的步骤S501至步骤S503。或者，处理器100执行计算机程序102时实现上述各装置实施例中各模块/单元的功能，例如图8所示模块81和模块82的功能；或者图9所示模块91至模块93的功能。

终端10可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。终端10可包括，但不仅限于：处理器100、存储器101。本领域技术人员可以理解，图10仅仅是终端10的示例，并不构成对终端10的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如终端10还可以包括输入发送设备、网络接入设备、总线等。

处理器100可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器101在一些实施例中可以是终端10的内部存储单元，例如终端10的硬盘或内存。存储器101也可以是终端10的外部存储设备，例如终端10上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。存储器101还可以既包括终端10的内部存储单元，也包括外部存储设备。存储器101用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例如计算机程序102的程序代码等。存储器101还可以用于暂时地存储已经发送或者将要发送的数据。

另外，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

本申请实施例还提供了一种终端，所述终端包括至少一个存储器、至少一个处理器以及存储在所述至少一个存储器中并可在所述至少一个处理器上运行的计算机程序，所述处理器执行所述计算机程序时，使所述终端实现上述各个方法实施例中的步骤。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端上运行时，使得终端执行时可实现上述各个方法实施例中的步骤。

所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一个计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读存储介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

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

Claims (10)

1.日志信息的处理方法，其特征在于，包括：

在客户端与服务端交互的过程中，向所述服务端发送包含预设请求头日志参数的请求消息，所述请求消息用于所述客户端与所述服务端的业务交互；

接收所述服务端针对所述预设请求头日志参数返回的日志信息；所述日志信息为所述服务端接收到所述请求消息后，基于所述预设请求头日志参数收集到的实时的日志信息。

2.根据权利要求1所述的处理方法，其特征在于，所述向所述服务端发送包含预设请求头日志参数的请求消息，包括：

拦截所述客户端发出的请求消息；

在所述请求消息内插入所述预设请求头日志参数；

转发包含所述预设请求头日志参数的所述请求消息至所述服务端。

3.根据权利要求1或2所述的处理方法，其特征在于，在所述接收所述服务端针对所述预设请求头日志参数返回的日志信息之后，还包括：

对所述日志信息进行汇总分析，得到汇总分析信息；

基于所述汇总分析信息，对所述日志信息进行展示。

4.根据权利要求1或2所述的处理方法，其特征在于，在所述向所述服务端发送包含预设请求头日志参数的请求消息之后，还包括：

接收所述服务端针对所述预设请求头日志参数返回的汇总分析信息；所述汇总分析信息为所述服务端对所述日志信息进行汇总分析的信息；

基于所述汇总分析信息，对所述日志信息进行展示。

5.日志信息的处理方法，其特征在于，包括：

在客户端与服务端交互的过程中，接收发送端发送的包含预设请求头日志参数的请求消息，所述请求消息用于所述客户端与所述服务端的业务交互；

基于所述预设请求头日志参数，收集实时的日志信息；

向所述发送端发送所述日志信息。

6.根据权利要求5所述的处理方法，其特征在于，在所述基于所述预设请求头日志参数，收集实时的日志信息之后，还包括：

对所述日志信息进行汇总分析，得到汇总分析信息；

向所述发送端发送所述汇总分析信息；所述发送端基于所述汇总分析信息，对所述日志信息进行展示。

7.根据权利要求6所述的处理方法，其特征在于，所述对所述日志信息进行汇总分析，得到汇总分析信息，包括：

基于分类信息库，确定所述日志信息的类别；所述分类信息库包括类别和归属于所述类别的日志范围。

8.日志信息的处理装置，其特征在于，包括：

第一发送模块，用于在客户端与服务端交互的过程中，向所述服务端发送包含预设请求头日志参数的请求消息，所述请求消息用于所述客户端与所述服务端的业务交互；

第一接收模块，用于接收所述服务端针对所述预设请求头日志参数返回的日志信息；所述日志信息为所述服务端接收到所述请求消息后，基于所述预设请求头日志参数收集到的实时的日志信息。

9.终端，其特征在于，所述终端包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现权利要求1至4任一项所述方法的步骤，或者实现权利要求5至7任一项所述方法的步骤。

10.计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至4任一项所述方法的步骤，或者实现权利要求5至7任一项所述方法的步骤。

Images