CN110764980A - 日志处理方法和装置 - Google Patents

Abstract

本申请提供一种日志处理方法和装置，根据日志的日志行中设置的跟踪标识，对日志进行事务上下文提取，其中，跟踪标识通过日志打印函数设置在日志行中，属于同一事务的同一调用链的日志事件具有相同的跟踪标识，进一步根据日志行的日志行采集时间对提取的事务上下文进行排序，确定日志中的事务上下文，从而，能够实现日志上下文的快速提取，方便相关人员基于日志上下文进行问题定位、分析等。而且能够根据日志的日志行中设置的日志事件标识，获取预设时间段内同一目标日志事件标识的日志事件的发生频次，根据该发生频次对日志进行分析检测，例如日志异常事件检测，主动发现问题，及时解决安全隐患，避免事故发生后再去寻找原因，降低损失。

Description

日志处理方法和装置

技术领域

本申请涉及日志技术领域，尤其涉及一种日志处理方法和装置。

背景技术

日志，在当今软件开发过程中扮演了十分重要的作用。日志，是指在软件源代码中加入了一些特定的语句，可以将软件运行的实时状态记录在文本文件中。软件开发者(或运维工作人员)可以通过阅读日志，掌握软件运行的实时情况，从而用于软件调试，性能优化，业务分析等场景。

如果日志出错，通常采用关键字查询错误的日志行。示例性的，首先，采集用户的日志，并做统一存储。然后对这些文本数据(非结构化数据)建立索引(例如使用lucene)。基于索引表，通过关键字在日志中查找相关内容。举例来说，用户发现某个时间段应用发生了错误，可以定位相应时间段的日志，并查找关键字“ERROR”，来查找错误的日志行。因为，错误的日志行中通常会带有ERROR这样的关键字。

然而，即使采用关键字查询到了错误的日志行，也很难判断导致问题发生的原因。因为单条日志包含的信息量太少，定位问题不准确。用户需要通过日志的上下文来判断是什么原因导致了问题，因此需要对日志业务上下文进行提取。其中，日志业务上下文包括事务上下文。这里，事务可以理解为系统提供的功能，例如支付。示例性的，以事务为微服务框架下支付的事务为例进行说明，该事务由多个相互通信的微服务共同完成，每个微服务中包括多个线程上下文，每个微服务中的线程上下文相互交织，不同微服务的日志打印在不同的日志文件中，每个日志文件中多线程上下文相互交织。如果某一微服务出现错误，不确定该错误是该微服务内部问题，还是调用微服务时出现的问题。这时，如果需要定位问题，就需要看这些服务相关的日志，即需要提取日志业务上下文。通常用户必须手动登录到每个微服务的虚机上查看相关日志，手动完成事务上下文的提取，显然，这个处理过程效率很低。

发明内容

本申请提供一种日志处理方法和装置，以提高日志上下文提取效率。

本申请第一方面提供一种日志处理方法，根据待处理日志的日志行中设置的跟踪标识，对待处理日志进行事务上下文提取，其中，日志行中设置的跟踪标识通过日志打印函数设置在日志行中，属于同一事务的同一调用链的日志事件具有相同的跟踪标识，进一步根据上述日志行的日志行采集时间对提取的事务上下文进行排序，确定待处理日志中的事务上下文，从而，能够实现日志上下文的快速提取，方便相关人员基于日志上下文进行问题定位、分析等。

一种可能设计，在所述根据待处理日志的日志行中设置的跟踪标识，对所述待处理日志进行事务上下文提取之前，该日志处理方法还包括：

通过所述日志打印函数在将所述日志行写入所述待处理日志时，确定待写入日志行的日志事件的所属事务的调用链；

根据所述待写入日志行的日志事件的所属事务的调用链，确定所述待写入日志行的日志事件的跟踪标识；

将确定的跟踪标识设置在所述待写入日志行的第一预设位置。

其中，每个调用链代表对事务的一次执行，每个调用链都有一个跟踪标识。在通过日志打印函数在将日志行写入待处理日志时，确定待写入日志行的日志事件的所属事务的调用链，根据该调用链的跟踪标识，确定待写入日志行的日志事件的跟踪标识，将确定的跟踪标识设置在待写入日志行的第一预设位置，进一步根据日志行中设置的跟踪标识，快速提取待处理日志中的事务上下文，解决日志上下文提取效率低的问题。

一种可能设计，在所述确定所述待处理日志中的事务上下文之后，该日志处理方法还包括：

根据确定的目标事务上下文，确定所述目标事务对应的每一调用链中的事务上下文；

根据所述目标事务对应的每一调用链中的事务上下文，进行日志异常执行路径检测。

这里，可以根据提取的日志上下文实现对日志的上层分析，例如上述日志异常执行路径检测，及时发现问题，解决安全隐患。

一种可能设计，所述根据待处理日志的日志行中设置的跟踪标识，对所述待处理日志进行事务上下文提取，该日志处理方法包括：

根据所述日志行中设置的跟踪标识，以及目标事务对应的调用链中日志事件的跟踪标识，对所述待处理日志进行目标事务上下文提取。

示例性的，以目标事务为上述登录事务为例，在某一时间段，例如过去2分钟有4次登录，产生4条调用链，每条调用链都有一个跟踪标识：trace01、trace02、trace03、trace04。如果需要提取这2分钟中的事务上下文，可以根据日志行中设置的跟踪标识，以及目标事务对应的调用链中日志事件的跟踪标识，即上述trace01、trace02、trace03、trace04，对待处理日志进行目标事务上下文提取，满足多种应用场景对事务上下文的提取要求。

一种可能设计，该日志处理方法还包括：

根据所述待处理日志的日志行中设置的日志事件标识，获取预设时间段内同一目标日志事件标识的日志事件的发生频次，其中，所述日志行中设置的日志事件标识通过所述日志打印函数设置在所述日志行中，用于标定全局唯一的日志事件。

这里，根据待处理日志的日志行中设置的日志事件标识，获取预设时间段内同一目标日志事件标识的日志事件的发生频次，根据该发生频次可以对日志进行分析检测，例如进行日志异常事件检测，主动发现问题，及时解决安全隐患，避免事故发生后再去寻找原因，降低损失，满足应用需要。

一种可能设计，在所述获取预设时间段内同一目标日志事件标识的日志事件的发生频次之后，该日志处理方法还包括：

根据所述发生频次，进行日志异常事件检测。

示例性的，可以根据上述发生频次，基于时序异常检测方法，例如3σ准则，确定日志事件发生频次范围，根据该日志事件发生频次范围进行日志异常事件检测，并可以基于发现的异常事件向用户发送告警，以便用户及时发现并进行相应处理。

一种可能设计，在所述根据所述待处理日志的日志行中设置的日志事件标识，获取预设时间段内同一目标日志事件标识的日志事件的发生频次之前，该日志处理方法还包括：

通过所述日志打印函数在将所述日志行写入所述待处理日志时，确定待写入日志行的日志事件的日志事件标识；

将确定的日志事件标识设置在所述待写入日志行的第二预设位置。

一种可能设计，所述确定待写入日志行的日志事件的日志事件标识，该日志处理方法包括：

根据所述待写入日志行的日志事件对应的打印日志的语句的位置，确定所述待写入日志行的日志事件的文件名和行号；

根据所述文件名和所述行号，获得所述待写入日志行的日志事件的日志事件标识。

这里，每一行日志都是由打印日志的语句生成。上述文件名和行号可以通过打印日志的语句的位置确定。进一步地，可以按照预设格式将相应的文件名和行号进行组合，获得待写入日志行的日志事件的日志事件标识，并将该日志事件标识设置在待写入日志行的第二预设位置，以便后续根据待处理日志的日志行中设置的日志事件标识，获取预设时间段内同一目标日志事件标识的日志事件的发生频次，根据该发生频次，进行日志异常事件检测等。

本申请第二方面提供一种日志处理装置，该日志处理装置包括：

提取模块，用于根据待处理日志的日志行中设置的跟踪标识，对所述待处理日志进行事务上下文提取，其中，所述日志行中设置的跟踪标识通过日志打印函数设置在所述日志行中，属于同一事务的同一调用链的日志事件具有相同的跟踪标识；

排序模块，用于根据所述日志行的日志行采集时间对提取的事务上下文进行排序，确定所述待处理日志中的事务上下文。

一种可能设计，该日志处理装置还包括：

第一确定模块，用于在所述提取模块根据待处理日志的日志行中设置的跟踪标识，对所述待处理日志进行事务上下文提取之前，通过所述日志打印函数在将所述日志行写入所述待处理日志时，确定待写入日志行的日志事件的所属事务的调用链；

第二确定模块，用于根据所述待写入日志行的日志事件的所属事务的调用链，确定所述待写入日志行的日志事件的跟踪标识；

第一设置模块，用于将确定的跟踪标识设置在所述待写入日志行的第一预设位置。

一种可能设计，该日志处理装置还包括：

第三确定模块，用于在所述排序模块确定所述待处理日志中的事务上下文之后，根据确定的目标事务上下文，确定所述目标事务对应的每一调用链中的事务上下文；

第一检测模块，用于根据所述目标事务对应的每一调用链中的事务上下文，进行日志异常执行路径检测。

一种可能设计，所述提取模块具体用于：

根据所述日志行中设置的跟踪标识，以及目标事务对应的调用链中日志事件的跟踪标识，对所述待处理日志进行目标事务上下文提取。

一种可能设计，该日志处理装置还包括：

获取模块，用于根据所述待处理日志的日志行中设置的日志事件标识，获取预设时间段内同一目标日志事件标识的日志事件的发生频次，其中，所述日志行中设置的日志事件标识通过所述日志打印函数设置在所述日志行中，用于标定全局唯一的日志事件。

一种可能设计，该日志处理装置还包括：

第二检测模块，用于在所述获取模块获取预设时间段内同一目标日志事件标识的日志事件的发生频次之后，根据所述发生频次，进行日志异常事件检测。

一种可能设计，该日志处理装置还包括：

第四确定模块，用于在所述获取模块根据所述待处理日志的日志行中设置的日志事件标识，获取预设时间段内同一目标日志事件标识的日志事件的发生频次之前，通过所述日志打印函数在将所述日志行写入所述待处理日志时，确定待写入日志行的日志事件的日志事件标识；

第二设置模块，用于将确定的日志事件标识设置在所述待写入日志行的第二预设位置。

一种可能设计，所述第四确定模块具体用于：

根据所述待写入日志行的日志事件对应的打印日志的语句的位置，确定所述待写入日志行的日志事件的文件名和行号；

根据所述文件名和所述行号，获得所述待写入日志行的日志事件的日志事件标识。

第三方面，本申请提供一种计算设备，该计算设备包括处理器和存储器。该存储器存储计算机指令；该处理器执行该存储器存储的计算机指令，使得该计算设备执行上述第一方面或者第一方面的各种可能设计提供的方法，使得该计算设备部署上述第二方面或者第二方面的各种可能设计提供该日志处理装置。

第四方面，本申请提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，该计算机指令指示该计算设备执行上述第一方面或者第一方面的各种可能设计提供的方法，或者该计算机指令指示该计算设备部署上述第二方面或者第二方面的各种可能设计提供该日志处理装置。

第五方面，本申请提供一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算设备的处理器可以从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算设备执行上述第一方面或者第一方面的各种可能设计提供的方法，使得该计算设备部署上述第二方面或者第二方面的各种可能设计提供该日志处理装置。

附图说明

图1为本申请实施例提供的一种日志处理系统的架构示意图；

图2为本申请实施例提供的一种分布式跟踪的实现示意图；

图3为本申请实施例提供的一种分布式服务器系统的架构示意图；

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

图5为本申请实施例提供的另一种日志处理方法的流程示意图；

图6为本申请实施例提供的再一种日志处理方法的流程示意图；

图7为本申请提供的一种日志处理装置的结构示意图；

图8为本申请提供的另一种日志处理装置的结构示意图；

图9为本申请提供的再一种日志处理装置的结构示意图；

图10为本申请提供的一种计算设备的基本硬件架构示意图。

具体实施方式

本申请实施例描述的网络架构以及业务场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

图1为本申请实施例提供的一种日志处理系统的架构示意图，如图1所示，本申请实施例提供日志处理系统11包括至少一台服务器110，该至少一台服务器110组成的日志处理系统可以是一个分布式服务器系统，也可以是集中的服务器集群，该日志处理系统中的不同服务器110之间可以通过网络互连。

该日志处理系统11中的任意一台服务器110均可以执行日志处理任务。

如，服务器110可以接收客户端发送的日志业务上下文提取请求，基于该日志业务上下文提取请求进行日志业务上下文提取，并基于提取的日志业务上下文进行日志异常执行路径检测。

其中，日志，是指在软件源代码中加入了一些特定的语句，可以将软件运行的实时状态记录在文本文件中。在开发过程中，日志能很方便的提供系统收到的数据，反映运行情况，内存中的数据的值，为调试提供很大的便利。利用日志，可以高效追踪排查一些错误，特别是偶然性错误，大大改善了开发效率。在系统开发完成，正式运营的过程中，通过查看日志，可以了解系统的整体运行情况，为系统及业务提供参考。

在日志出错时，需要通过日志的上下文来确定问题发生原因，因此需要对日志业务上下文进行提取。

具体地，日志业务上下文包含：事务上下文。其中，事务可以理解为系统提供的功能，例如支付、登录、注册等，这个功能可以是用户在前端的某个操作，也可以是后端开放API接口由用户调用。例如，在微服务框架下，一个支付事务的执行是由多个相互通信的微服务共同完成。在这个执行过程中，这些微服务都会往不同的日志文件中打印日志。每个日志文件可能会有多线程上下文相互交织。其中，一个微服务中的线程上下文可以理解为调用链在该服务的执行片段，一个调用链表示对事务的一次执行。

示例性的，以一个log4j的Java日志文件为例对线程上下文进行说明。如下述，许多线程交织打印日志在这个文件中：

2008-09-10 14:55:57,022 INFO[pool-7-thread-45][ROOT][class name A-55]indexName is ais_podindex,info is{“projectld”:“……

2008-09-10 14:55:57,020 INFO[pool-8-thread-34][ROOT][classname A-53]SelfContainerInfoHandle Task task end,cost time is 14

2008-09-10 14:55:57,023 INFO[pool-7-thread-45][ROOT][classname A-52]SelfPodlnfoHandle Task end,cost time is 13

即线程pool-7-thread-45、pool-8-thread-34交织打印日志在这个文件中。通常，在发现问题后，运维人员需要看线程的上下文来做问题定位，只有相同线程的信息才能提供上下文的信息。但是每一行日志前后的日志行可能和本行日志没有关系，例如上述线程pool-7-thread-45、pool-8-thread-34所示。因此，运维人员通常需要手动选择线程来阅读线程上下文信息，效率很低。

进一步地，还以上述微服务框架下支付的事务为例，该事务由多个相互通信的微服务共同完成，如果某一微服务出现错误，不确定该错误是该微服务内部问题，还是调用微服务时出现的问题。这时，如果需要定位问题，就需要看这些服务相关的日志。通常日志工具不支持事务，而且，如果线程pool-7-thread-45、pool-8-thread-34为某一微服务中的线程，在获取该服务时，可以通过线程号把线程日志上下文提取出来。例如上述线程号pool-7-thread-45，通过该线程号把相应的线程日志上下文提取出来。但是如果一个事务包含多个微服务，通过上述方法只能提取每个微服务中的线程上下文，而微服务间的线程上下文无法提取。这样，用户必须手动登录到每个服务的虚机上查看相关日志，通过时间过滤，并定位相关问题，处理速度慢，效率低。

因此，目前需要做的是如何高效地提取事务上下文。这里，可以借助Dapper框架，如图2所示，某应用包括一个前端服务(A)，两个中间层服务(B和C)，以及两个后端服务(D和E)。首先，客户端对某个业务类型(例如登录)发起请求(RequestX)，请求到达前端服务A，然后A发送两个调用请求到微服务B和C。B会马上做出反应，但是C需要和后端的微服务D和E交互之后再返还给A，由A来响应最初的请求。对于这样一个请求，通过分布式跟踪的实现，就是为服务器上每一次发送和接收动作来收集跟踪标识符(message identifiers)和时间戳(timestamped events)。对于业务链条中的每一次请求调用，划分为clientSend(客户端发送请求)、clientRecv(客户端收到响应)、serverRecv(服务端收到请求)、serverSend(服务端发送响应)等四个事件或动作(包含跟踪标识符和时间戳)。

具体地，参照上述图2所述的分布式跟踪的实现方法，在日志行中设置跟踪标识，其中，属于同一事务的同一调用链的日志事件具有相同的跟踪标识。示例性的，以登录事务为例，在某一时间段，例如过去2分钟有4次登录，产生4条调用链，每条调用链都有一个全局唯一的id，将该全局唯一的id设置为trace_id，作为上述跟踪标识。其中，以第一条调用链的id为例，调用链的id可以为trace01、login-01、随机数(例如01b2)、hash值(调用链中日志事件的hash值)等，本申请对此不作特别限制，只要每条调用链都有一个全局唯一的id即可。根据上述跟踪标识把属于同一事务的同一调用链的日志事件放在一起，再根据日志行的日志行采集时间，把放在一起的日志行按执行顺序排列，最终实现了微服务间的事务上下文提取，可以进行多个微服务的联合查看。在某一微服务出现错误，能够及时确定该错误是该微服务内部问题，还是调用微服务时出现的问题

另外，上述客户端可以与服务器110相互独立设计，例如，客户端通过网络与服务器110连接。同时，上述客户端还可以与服务器110一体设计，例如，每台服务器110上设置一个客户端。

这里，以分布式服务器系统，且客户端与服务器一体设计为例，对本申请日志处理系统进行介绍，图3为本申请实施例提供的一种分布式服务器系统的架构示意图，这里，该分布式服务器系统300中仅作为示例而非限制，给出了三个服务器301、302、303(系统能够按照自身的实际需要灵活调整服务器的数量)，每个服务器上可以部署有客户端，分别为客户端311、312、313。不同服务器之间可以通过网络互连，该网络可以是互联网、因特网协议存储区域网络(internet protocol storage area network，IP SAN)、内联网以及私有网络等等。需要注意的是，上述说明性论述并不打算穷举或将本申请局限于图3所示的系统架构形式，在具体实现过程中，分布式服务器系统300的众多修改和变形都是可行的，例如该系统300还包括三个存储节点322、323、324，用于存储数据。上述三个服务器301、302、303通过例如计算网络、转换线缆InfiniBand或以太网光纤通道FCoF等与三个存储节点322、323、324实现互联。

示例性的，服务器301可以接收客户端311发送的日志业务上下文提取请求，基于该日志业务上下文提取请求进行日志业务上下文提取，并基于提取的日志业务上下文进行日志异常执行路径检测。进一步地，还可以将提取的日志业务上下文以及日志异常执行路径检测结果存储在存储节点322。

下面以几个实施例为例对本申请的技术方案进行描述，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图4为本申请实施例提出的一种日志处理方法的流程示意图，本实施例的执行主体可以为图1所示实施例中的服务器110，也可以为图3所示实施例的服务器301，本实施例此处不做特别限制。如图4所示，该方法包括：

S401：根据待处理日志的日志行中设置的跟踪标识，对所述待处理日志进行事务上下文提取，其中，所述日志行中设置的跟踪标识通过日志打印函数设置在所述日志行中，属于同一事务的同一调用链的日志事件具有相同的跟踪标识。

这里，上述待处理日志可以通过以下方式获取：

接收客户端发送的待处理日志；或者，从存储器获取待处理日志。

这里，服务器可以接收客户端发送的待处理日志，并对待处理日志进行相应处理。如果客户端没有发送待处理日志到服务器，服务器还可以从存储器获取待处理日志，对待处理日志进行相应处理。其中，存储器可以预存多个待处理日志，并可以保存多个待处理日志的处理顺序。服务器可以根据该处理顺序依次从存储器获取待处理日志进行相应处理。

其中，上述日志行中设置跟踪标识的方式采用下述具体地实施方式进行说明：

通过所述日志打印函数在将所述日志行写入所述待处理日志时，确定待写入日志行的日志事件的所属事务的调用链；

根据所述待写入日志行的日志事件的所属事务的调用链，确定所述待写入日志行的日志事件的跟踪标识；

将确定的跟踪标识设置在所述待写入日志行的第一预设位置。

由上述可知，每个调用链代表对事务的一次执行，事务和调用链是一对多的对应关系，每个调用链都有一个全局唯一的id，作为上述跟踪标识。因此，在通过日志打印函数在将日志行写入待处理日志时，确定待写入日志行的日志事件的所属事务的调用链，例如待写入日志行的日志事件属于上述登录事务在过去2分钟的4次登录产生的第一条调用链，根据待写入日志行的日志事件的所属事务的调用链，确定待写入日志行的日志事件的跟踪标识，例如上述第一条调用链的跟踪标识为trace01，则确定待写入日志行的日志事件的跟踪标识为trace01，将确定的跟踪标识设置在待写入日志行的第一预设位置。即上述登录事务，多个微服务的日志打印在不同的日志文件时，可以通过日志打印函数，在原来日志行的第一预设位置加入相应的跟踪标识。其中，第一预设位置可以为日志行的头部、尾部等，本申请对此不作特别限制。

具体地，在对待处理日志进行上下文提取之前，利用上述日志打印函数在将日志行写入待处理日志时，在待写入日志行的第一预设位置设置跟踪标识，即在每一个日志行中多放入一个信息：trace_id。然后根据日志行中设置的跟踪标识，提取待处理日志中的事务上下文；再根据日志行的日志行采集时间，对提取的各个事务上下文进行排序，最终确定相应的事务上下文。

其中，上述日志打印函数用于将日志数据传递给自身内部的函数，利用内部的函数完成相应数据处理。示例性的，通过日志打印函数在将待处理日志行写入日志时，利用内部的函数修改日志的参数，在日志中加入上述跟踪标识。

为了更好地理解上述日志打印函数，这里以Java语言为例，对方案进行介绍。

假设有一个Java类Test，这个类定义了一个函数testme()，这个函数里有一个打印日志的语句

logger.info("The order info has been updated.")

这里使用Java log4j框架打印日志，调用了org.apache.log4j.Logger类中的info方法，其中，logger.info为日志打印函数。该函数可以执行下述操作：

1、调用doRender()方法给原始日志加头(rendering)；

这个函数会根据用户的配置，加入时间，日志级别，线程名，文件名等信息。例如，上面的原始日志经过doRender()函数后，会生成一下字符串：

2018-12-19 17:59:27,073 INFO[Thread-1][Test_110]The order info hasbeen updated.

2、调用callAppenders()方法将加好头的日志写入文件；

这里，在调用callAppenders()方法的时候，通过修改字节码，修改日志的参数，在原来的参数的预设位置，例如原来的参数前，加入需要的信息，例如[trace10]，最后获得：

[trace10]2018-12-19 17:59:27,073 INFO[Thread-1][Test_110]The orderinfo has been updated.

进一步地，可以在上述日志打印函数logger.info调用callAppenders()方法的时候，通过修改字节码，修改日志的参数，在原来的参数的预设位置加入上述跟踪标识。

另外，还可以根据日志行中设置的跟踪标识，以及目标事务对应的调用链中日志事件的跟踪标识，对待处理日志进行目标事务上下文提取。其中，目标事务可以是登录事务、注册事务、支付事务等，本申请对此不做特别限制。示例性的，以目标事务为上述登录事务为例，在某一时间段，例如过去2分钟有4次登录，产生4条调用链，每条调用链都有一个全局唯一的id：trace01、trace02、trace03、trace04。如果需要提取这2分钟中的事务上下文，可以根据日志行中设置的跟踪标识，以及目标事务对应的调用链中日志事件的跟踪标识，即上述trace01、trace02、trace03、trace04，对待处理日志进行目标事务上下文提取，满足多种应用场景对事务上下文的提取要求。

S402：根据所述日志行的日志行采集时间对提取的事务上下文进行排序，确定所述待处理日志中的事务上下文。

这里，可以参照上述图2所述的分布式跟踪的实现方法，在日志行中设置跟踪标识，然后根据该跟踪标识把属于同一事务的同一调用链的日志事件放在一起，再根据日志行的日志行采集时间，把放在一起的日志行按执行顺序排列，最终实现事务上下文提取。

为方便理解上述提取待处理日志的事务上下文，这里，以上述登录事务，在过去2分钟的4次登录为例，有：

上述登录事务由多个相互通信的微服务共同完成，假如多个微服务的日志打印在两个不同的日志文件中，其中，第一个日志文件中有:

[trace03]login start

[trace01]login ready

[trace02]login complete

[trace01]login complete

[trace04]login ready

[trace04]login fail

第二个日志文件中有：

[trace01]login start

[trace02]login start

[trace02]login ready

[trace03]login ready

[trace04]login start

[trace03]login complete

这里，trace01、trace02、trace03、trace04分别为上述登录事务在过去2分钟4次登录产生的4条调用链的全局唯一的id，即跟踪标识。根据跟踪标识把属于同一事务的同一调用链的日志事件放在一起，再根据日志行的日志行采集时间(未示出)，把放在一起的日志行按执行顺序排列，得到：

基于上述跟踪标识能够进行微服务间的事务上下文提取，进行多个微服务的联合查看。在某一微服务出现错误，能够及时确定该错误是该微服务内部问题，还是调用微服务时出现的问题。

本实施例，服务器根据待处理日志的日志行中设置的跟踪标识，对待处理日志进行事务上下文提取，然后根据日志行的日志行采集时间对提取的事务上下文进行排序，确定待处理日志中的事务上下文，其中，上述日志行中设置的跟踪标识通过日志打印函数设置在日志行中，属于同一事务的同一调用链的日志事件具有相同的跟踪标识，能够实现日志上下文的快速提取，方便运维人员基于日志上下文进行问题定位、分析等。而且把所有相关信息聚合在一起，运维人员不需要逐个登录每个服务查看日志来分析问题，从而大大提高了效率。

另外，本实施例还能够基于提取的日志上下文进行日志异常执行路径检测。图5为本申请实施例提出的另一种日志处理方法的流程示意图，本实施例的执行主体可以为图1所示实施例中的服务器110，也可以为图3所示实施例的服务器301，本实施例此处不做特别限制。如图5所示，该方法包括：

S501：根据待处理日志的日志行中设置的跟踪标识，对所述待处理日志进行事务上下文提取，其中，所述日志行中设置的跟踪标识通过日志打印函数设置在所述日志行中，属于同一事务的同一调用链的日志事件具有相同的跟踪标识。

S502：根据所述日志行的日志行采集时间对提取的事务上下文进行排序，确定所述待处理日志中的事务上下文。

其中，步骤S501-S502与上述步骤S401-S402的实现方式相同，此处不再赘述。

S503：根据确定的目标事务上下文，确定所述目标事务对应的每一调用链中的事务上下文。

这里，目标事务可以为登录事务、注册事务、支付事务等，本实施例对此不做特别限制。

假如目标事务为上述登录事务，在过去2分钟有4次登录，产生4条调用链，确定该事务对应的每一调用链中的事务上下文，如上述：

S504：根据所述目标事务对应的每一调用链中的事务上下文，进行日志异常执行路径检测。

具体地，可以通过目标事务对应的每一调用链中的事务上下文，还原该事务不同调用的日志序列。例如，上述登录事务第一次调用的日志序列为：login start->loginready->login

complete；第二次调用的日志序列为：login start->login ready->logincomplete；第三次调用的日志序列为：login start->login ready->login complete；第四次调用的日志序列为：login start->login ready->login fail。

进一步地，可以通过机器学习技术，训练一个序列模型，代表了正常执行的日志序列。例如，正常的登录事务一次调用的日志序列为：login start->login ready->logincomplete。如果发现登录事务某次调用的日志序列是login start->login ready->loginfail，例如上述第四次调用的日志序列，与正常登录事务一次调用的日志序列不同，此时可以会向用户发送告警。即基于事务对应的每一调用链中的事务上下文，进行日志异常执行路径检测，能够及时发现系统异常，并提醒用户。

本实施例，服务器在基于日志行中设置的跟踪标识进行日志业务上下文提取后，可以根据提取的日志业务上下文提取实现对日志的上层分析，例如上述日志异常执行路径检测，及时发现问题，解决安全隐患。

图6为本申请提供的再一种日志处理方法的流程示意图，本实施例的执行主体可以为图1所示实施例中的服务器110，也可以为图3所示实施例的服务器301，本实施例此处不做特别限制。如图6所示，该方法包括：

S601：根据所述待处理日志的日志行中设置的日志事件标识，获取预设时间段内同一目标日志事件标识的日志事件的发生频次，其中，所述日志行中设置的日志事件标识通过所述日志打印函数设置在所述日志行中，用于标定全局唯一的日志事件。

这里，上述日志事件标识用于标定全局唯一的日志事件，即日志事件标识为一个日志事件的全局唯一日志事件id，例如E1、E2等，本申请对比不做特别限制。其中，一个日志事件，可以视为一个日志模式(pattern)，或者一个日志模板。

为了方便理解上述日志事件标识，以日志A.java class和B.java class为例进行说明。其中，日志A.java class有一个E1的打印日志的语句，日志B.java class中有一个E2的打印日志的语句：

[E1]:verification code 0342 sent to user 13888888888

[E2]:wrong verification code

其中，E1和E2可以视为日志事件标识。

上述同一目标日志事件标识可以E1、E2等，本实施例对此不做特别限制。上述预设时间段可以根据实际情况设置，例如，5分钟、10分钟等，本实施例对此不做特别限制。具体地，可以通过时间窗对同一目标日志事件标识的日志事件的发生频次进行统计。

在一种可能的实现方式，在所述根据所述待处理日志的日志行中设置的日志事件标识，获取预设时间段内同一目标日志事件标识的日志事件的发生频次之前，还包括：

通过所述日志打印函数在将所述日志行写入所述待处理日志时，确定待写入日志行的日志事件的日志事件标识；

将确定的日志事件标识设置在所述待写入日志行的第二预设位置。

这里，第二预设位置可以为日志行的头部、尾部等，本申请对此不作特别限制。

其中，确定待写入日志行的日志事件的日志事件标识的方式可以包括：根据所述待写入日志行的日志事件对应的打印日志的语句的位置，确定所述待写入日志行的日志事件的文件名和行号；根据所述文件名和所述行号，获得所述待写入日志行的日志事件的日志事件标识。

这里，每一行日志都是由打印日志的语句生成。上述文件名和行号可以通过打印日志的语句的位置确定，例如通过打印日志的语句的位置确定文件名为iam.java，行号为28。

进一步地，可以按照预设格式将相应的文件名和行号进行组合，获得待写入日志行的日志事件的日志事件标识。其中，预设格式可以根据实际需要设置，例如预设格式为[文件名-行号]。

示例性的，为了方便理解上述文件名和行号，这里采用如下日志进行说明：

假如一个打印日志的语句为：logger.info('User％d profile modified',$uid)

这行日志记录了用户修改资料的动作，有一个变量，用户的id(uid)。

实际应用过程中，可能有成百上千条不同的日志相互交织打印在一个文件里。下面，给出了这条日志语句运行的一个可能的输出：

[iam.java-28]User 025862 login at 2018-12-03 02:03:00

[user.java-90]User 025862 profile modified

[iam.java-28]User 045210 login at 2018-12-03 02:03:15

[user.java-90]User 045210 profile modified

[iam.java-28]User 033658 login at 2018-12-03 02:03:38

[iam.java-28]User 010100 login at 2018-12-03 02:04:06

其中，[iam.java-28]和[user.java-90]为日志事件标识，iam.java和user.java为文件名，28和90为行号。上述文件名和行号通过打印日志的语句的位置确定。

S602：根据所述发生频次，进行日志异常事件检测。

这里，可以根据上述发生频次，基于时序异常检测方法，例如3σ准则，确定日志事件发生频次范围，根据该日志事件发生频次范围进行日志异常事件检测。其中，3σ准则又称为拉依达准则，其先假设一组检测数据只含有随机误差，对其进行计算处理得到标准偏差，按一定概率确定一个区间，认为凡超过这个区间的误差，就不属于随机误差而是粗大误差，含有该误差的数据应予以剔除。

具体地，3σ原则为

数值分布在(μ-σ,μ+σ)中的概率为0.6827

数值分布在(μ-2σ,μ+2σ)中的概率为0.9545

数值分布在(μ-3σ,μ+3σ)中的概率为0.9973

可知，数值基本集中在(μ-3σ,μ+3σ)区间内，超出这个范围的可能性仅占不到0.3％，因此，确定超过(μ-3σ,μ+3σ)这个区间的数据，其误差不属于随机误差而是粗大误差，含有该误差的数据应予以剔除。

示例性的，本申请实施例的一种可能的应用场景如下所述：

以登录事务为例，其中，每一个登录的执行，后台都是有一系列服务间的调用实现的，因此，每个登录的执行，通常会产生多条日志。这里，假如一个登录的执行如下所述：

用户登录，首先调用SMSSrv，发送短信验证码给用户，打印一条E1日志事件；

然后用户输入验证码。如果用户输入错误，则打印一条E2日志事件；

如果验证码正确，并且用户名和密码匹配，则打印一条E3日志事件；

如果验证码正确，但是用户名和密码不匹配，则打印一条E4日志事件。

这里，上述E1，E2，E3，E4分别视为日志事件标识。

下面，例举一个实际的例子。如果原始日志为：

2019-06-09 17:29:30 verification code 0342 sent to user 13888888888

2019-06-09 17:29:30 wrong verification code

2019-06-09 17:29:30 verification code 0987 sent to user 13999999999

2019-06-09 17:30:00 User 13888888888 successfully login at 2019-06-0917:30:00

2019-06-09 17:30:01 verification code 0638 sent to user 13666666666

2019-06-09 17:30:30 Login Failed:user 13999999999

2019-06-09 17:30:30 User 13888888888 successfully login at 2019-06-0917:30:30

2019-06-09 17:31:20 Login Failed:user 13666666666

加入上述日志事件标识E1，E2，E3，E4后，获得：

[E1]:verification code 0342 sent to user 13888888888

[E2]:wrong verification code

[E1]:verification code 0987 sent to user 13999999999

[E3]:User 13888888888 successfully login at 2019-06-19 17:30:00

[E1]:verification code 0638 sent to user 13666666666

[E4]:Login Failed:user 13999999999

[E3]:User 13888888888 successfully login at 2019-06-19 17:30:01

[E4]:Login Failed:user 13666666666

然后，由上述日志可以获得一个日志pattern，也可以理解成一个日志模板，即：

[E1]:verification code[*]sent to user[*]

[E2]:wrong verification code

[E3]:User[*]successfully login at[*]

[E4]:Login Failed:[*]

再由上述日志pattern可知，原始日志中同一目标日志事件标识的日志事件的发生频次

进一步地，针对同一目标日志事件标识的日志事件，可以通过时间窗对该日志事件标识的日志事件的发生频次进行统计，示例性的，通过固定时间窗进行频次统计，或者通过滑动时间窗进行频次统计。其中，固定时间窗是大小固定且不能随着时间而变化的。滑动时间窗将固定时间窗再等分为多个小的窗口，可以对数据进行更细粒度地统计，例如上述固定时间窗大小为5分钟，滑动时间窗可以将该窗口等分为5个小窗口，每个小窗口大小为1分钟。在上述通过时间窗对同一目标日志事件标识的日志事件的发生频次进行统计后，基于时序异常检测方法，例如3σ准则，生成相应指标(日志事件发生频次范围)，再通过生成的指标进行日志异常事件检测。例如日志事件标识为E1的日志事件。假设有5个时间窗，第一个时间窗统计的日志事件发生次数为62，第二个时间窗统计的日志事件发生次数为58，第三个时间窗统计的日志事件发生次数为66，第四个时间窗统计的日志事件发生次数为52，第五个时间窗统计的日志事件发生次数为62。由此可知，日志事件发生平均次数为60，标准差为5.3。根据3σ方法，可以得到日志事件发生频次范围：60±3*5.3(44.1-75.9)。如果通过第六个时间窗统计的日志事件发生次数为76，超出上述日志事件发生频次范围，这种发生频次高于预期的事件称之为热事件。如果通过第七个时间窗统计的日志事件发生次数为30，低于上述日志事件发生频次范围，这种发生频次低于预期的事件称之为冷事件。另外，如果通过时间窗对同一目标日志事件标识(上述E1、E2、E3或E4)的日志事件的发生频次进行统计时，统计得到的日志事件标识E5的日志事件发生次数，E5日志事件以前没有出现过，这种以前没有出现过的事件称之为未知事件。

这里，基于上述日志行中的日志事件标识，通过时间窗的方法对每个时间日志事件的发生频次进行统计，生成相应指标。最后可以通过生成的指标检测事件异常，例如：冷事件(发生频次低于预期)，热事件(发生频次高于预期)，未知事件(以前没有出现过的事件)等，实现日志异常事件的主动发现，能够及时解决安全隐患，而且还可以基于发现的异常事件向用户发送告警，以便用户及时发现并进行相应处理。

本实施例，服务器根据待处理日志的日志行中设置的日志事件标识，获取预设时间段内同一目标日志事件标识的日志事件的发生频次，根据该发生频次，进行日志异常事件检测，其中，日志行中设置的日志事件标识通过所述日志打印函数设置在所述日志行中，用于标定全局唯一的日志事件，可以根据获取的日志事件的发生频次实现对日志的上层分析，例如上述冷事件、热事件、未知事件等检测，主动发现问题，及时解决安全隐患，避免事故发生后再去寻找原因，降低损失，满足应用需要。

另外，为方便理解上述通过日志打印函数在将日志行写入待处理日志时，在日志行中设置跟踪标识，以及通过日志打印函数在将日志行写入待处理日志时，在日志行中设置日志事件标识。这里，还是以Java语言为例进行说明，需要注意的是在Java语言中上述根据待写入日志行的日志事件对应的打印日志的语句的位置，确定待写入日志行的日志事件的文件名为：根据待写入日志行的日志事件对应的打印日志的语句的位置，确定待写入日志行的日志事件的类名。这里以在日志行的头部设置跟踪标识和日志事件标识，以及日志事件标识为[类名-行号]为例进行说明。

包括：

1.在Java虚拟机(java virtual machine，JVM)加载到类文件之后，解析类文件并查找日志输出方法(callAppenders)的指令

2.定义一个Java指令结构列表，方法局部变量指令生成器

3.获取拦截器的before方法描述

4.使用方法局部变量指令生成器生成初始化拦截器为方法局部变量的指令，添加到Java指令结构列表

5.生成拦截器的before方法调用指令，添加到Java指令结构列表

6.将生成的拦截器初始化和before方法调用指令插入日志输出方法的开始执行指令之前

具体地，定义一个拦截器(Interceptor接口)，其实例代码如下所示。

之后，定义一个LogInterceptor类，来实现Interceptor接口。即定义before方法和after方法具体做什么。其实例代码如下所示。

由上可知，在before方法中，首先是获取所有栈(stack)，然后获取当前线程调用栈(currentStack)。当前线程调用栈为栈顶的第四个栈帧，例如：

com.A.interceptor.LoggerInterceptor.before

com.log4j.Logger.callAppenders

com.log4j.Logger.info

com.A.service.ManagementService.check

如上所示的一个线程调用栈，应用在com.A.service.ManagementService.check方法中调用Logger.info方法输出日志，可是当执行到拦截器中获取线程调用栈时，会获得如上所示线程栈；在日志输出内部调用拦截器的深度是固定不变的，所以仅需要获取栈顶的第四个元素，即可获取真实的调用位置。

之后，构建日志需要加入的信息(appendingLog)，即在原始日志的预设位置加入，例如在原始日志前加入：

[trace_id-类名-行号]原始日志

其中，从traceContext中获取到trace_id信息，在栈里获取类名和行号信息。

进一步地，在应用中使用上述拦截器在打印日志的时候加入相应信息，其实例代码如下。

图7为本申请提供的一种日志处理装置的结构示意图，该装置包括：提取模块701和排序模块702。

其中，提取模块701，用于根据待处理日志的日志行中设置的跟踪标识，对所述待处理日志进行事务上下文提取，其中，所述日志行中设置的跟踪标识通过日志打印函数设置在所述日志行中，属于同一事务的同一调用链的日志事件具有相同的跟踪标识。

排序模块702，用于根据所述日志行的日志行采集时间对提取的事务上下文进行排序，确定所述待处理日志中的事务上下文。

可选地，上述装置还包括：第一确定模块703、第二确定模块704和第一设置模块705。

其中，第一确定模块703，用于在所述提取模块701根据待处理日志的日志行中设置的跟踪标识，对所述待处理日志进行事务上下文提取之前，通过所述日志打印函数在将所述日志行写入所述待处理日志时，确定待写入日志行的日志事件的所属事务的调用链。

第二确定模块704，用于根据所述待写入日志行的日志事件的所属事务的调用链，确定所述待写入日志行的日志事件的跟踪标识。

第一设置模块705，用于将确定的跟踪标识设置在所述待写入日志行的第一预设位置。

可选地，所述提取模块701具体用于：

根据所述日志行中设置的跟踪标识，以及目标事务对应的调用链中日志事件的跟踪标识，对所述待处理日志进行目标事务上下文提取。

本实施例的装置，对应地可用于执行图4所示实施例中的技术方案，其实现原理和技术效果类似，此处不再赘述。

图8为本申请提供的另一种日志处理装置的结构示意图，该装置包括：提取模块701、排序模块702、第三确定模块706和第一检测模块707。

其中，提取模块701和排序模块702与图7中的实现方式相同，此处不再赘述。

第三确定模块706，用于在所述排序模块702确定所述待处理日志中的事务上下文之后，根据确定的目标事务上下文，确定所述目标事务对应的每一调用链中的事务上下文。

第一检测模块707，用于根据所述目标事务对应的每一调用链中的事务上下文，进行日志异常执行路径检测。

本实施例的装置，对应地可用于执行图5所示实施例中的技术方案，其实现原理和技术效果类似，此处不再赘述。

图9为本申请提供的再一种日志处理装置的结构示意图，该装置包括：获取模块708和第二检测模块709。

其中，获取模块708，用于根据所述待处理日志的日志行中设置的日志事件标识，获取预设时间段内同一目标日志事件标识的日志事件的发生频次，其中，所述日志行中设置的日志事件标识通过所述日志打印函数设置在所述日志行中，用于标定全局唯一的日志事件。

第二检测模块709，用于在所述获取模块708获取预设时间段内同一目标日志事件标识的日志事件的发生频次之后，根据所述发生频次，进行日志异常事件检测。

可选地，上述装置还包括：第四确定模块710和第二设置模块711。

其中，第四确定模块710，用于在所述获取模块708根据所述待处理日志的日志行中设置的日志事件标识，获取预设时间段内同一目标日志事件标识的日志事件的发生频次之前，通过所述日志打印函数在将所述日志行写入所述待处理日志时，确定待写入日志行的日志事件的日志事件标识。

第二设置模块711，用于将确定的日志事件标识设置在所述待写入日志行的第二预设位置。

可选地，所述第四确定模块710具体用于：

根据所述待写入日志行的日志事件对应的打印日志的语句的位置，确定所述待写入日志行的日志事件的文件名和行号；

根据所述文件名和所述行号，获得所述待写入日志行的日志事件的日志事件标识。

本实施例的装置，对应地可用于执行图6所示实施例中的技术方案，其实现原理和技术效果类似，此处不再赘述。

可选地，图10示意性地提供本申请所述计算设备的一种可能的基本硬件架构。

参见图10，计算设备1000包括处理器1001、存储器1002、通信接口1003和总线1004。

其中，计算设备1000可以是计算机或服务器，本申请对此不作特别限制。计算设备1000中，处理器1001的数量可以是一个或多个，图10仅示意了其中一个处理器1001。可选地，处理器1001，可以是中央处理器(central processing unit，CPU)。如果计算设备1000具有多个处理器1001，多个处理器1001的类型可以不同，或者可以相同。可选地，计算设备1000的多个处理器1001还可以集成为多核处理器。

存储器1002存储计算机指令和数据；存储器1002可以存储实现本申请提供的日志处理方法所需的计算机指令和数据，例如，存储器1002存储用于实现日志处理方法的步骤的指令。存储器1002可以是以下存储介质的任一种或任一种组合：非易失性存储器(例如只读存储器(ROM)、固态硬盘(SSD)、硬盘(HDD)、光盘)，易失性存储器。

通信接口1003可以是以下器件的任一种或任一种组合：网络接口(例如以太网接口)、无线网卡等具有网络接入功能的器件。

通信接口1003用于计算设备1000与其它计算设备或者终端进行数据通信。

图10用一条粗线表示总线1004。总线1004可以将处理器1001与存储器1002和通信接口1003连接。这样，通过总线1004，处理器1001可以访问存储器1002，还可以利用通信接口1003与其它计算设备或者终端进行数据交互。

在本申请中，计算设备1000执行存储器1002中的计算机指令，使得计算设备1000实现本申请提供的日志处理方法，或者使得计算设备1000部署日志处理装置。

本申请还提供一种计算机可读存储介质，所述计算机程序产品包括计算机指令，所述计算机指令指示计算设备执行本申请提供的日志处理方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

Claims (18)

1.一种日志处理方法，其特征在于，包括：

根据待处理日志的日志行中设置的跟踪标识，对所述待处理日志进行事务上下文提取，其中，所述日志行中设置的跟踪标识通过日志打印函数设置在所述日志行中，属于同一事务的同一调用链的日志事件具有相同的跟踪标识；

根据所述日志行的日志行采集时间对提取的事务上下文进行排序，确定所述待处理日志中的事务上下文。

2.根据权利要求1所述的日志处理方法，其特征在于，在所述根据待处理日志的日志行中设置的跟踪标识，对所述待处理日志进行事务上下文提取之前，还包括：

通过所述日志打印函数在将所述日志行写入所述待处理日志时，确定待写入日志行的日志事件的所属事务的调用链；

根据所述待写入日志行的日志事件的所属事务的调用链，确定所述待写入日志行的日志事件的跟踪标识；

将确定的跟踪标识设置在所述待写入日志行的第一预设位置。

3.根据权利要求1或2所述的日志处理方法，其特征在于，在所述确定所述待处理日志中的事务上下文之后，还包括：

根据确定的目标事务上下文，确定所述目标事务对应的每一调用链中的事务上下文；

根据所述目标事务对应的每一调用链中的事务上下文，进行日志异常执行路径检测。

4.根据权利要求1至3中任一项所述的日志处理方法，其特征在于，所述根据待处理日志的日志行中设置的跟踪标识，对所述待处理日志进行事务上下文提取，包括：

根据所述日志行中设置的跟踪标识，以及目标事务对应的调用链中日志事件的跟踪标识，对所述待处理日志进行目标事务上下文提取。

5.根据权利要求1至4中任一项所述的日志处理方法，其特征在于，还包括：

根据所述待处理日志的日志行中设置的日志事件标识，获取预设时间段内同一目标日志事件标识的日志事件的发生频次，其中，所述日志行中设置的日志事件标识通过所述日志打印函数设置在所述日志行中，用于标定全局唯一的日志事件。

6.根据权利要求5所述的日志处理方法，其特征在于，在所述获取预设时间段内同一目标日志事件标识的日志事件的发生频次之后，还包括：

根据所述发生频次，进行日志异常事件检测。

7.根据权利要求5或6所述的日志处理方法，其特征在于，在所述根据所述待处理日志的日志行中设置的日志事件标识，获取预设时间段内同一目标日志事件标识的日志事件的发生频次之前，还包括：

通过所述日志打印函数在将所述日志行写入所述待处理日志时，确定待写入日志行的日志事件的日志事件标识；

将确定的日志事件标识设置在所述待写入日志行的第二预设位置。

8.根据权利要求7所述的日志处理方法，其特征在于，所述确定待写入日志行的日志事件的日志事件标识，包括：

根据所述待写入日志行的日志事件对应的打印日志的语句的位置，确定所述待写入日志行的日志事件的文件名和行号；

根据所述文件名和所述行号，获得所述待写入日志行的日志事件的日志事件标识。

9.一种日志处理装置，其特征在于，包括：

提取模块，用于根据待处理日志的日志行中设置的跟踪标识，对所述待处理日志进行事务上下文提取，其中，所述日志行中设置的跟踪标识通过日志打印函数设置在所述日志行中，属于同一事务的同一调用链的日志事件具有相同的跟踪标识；

排序模块，用于根据所述日志行的日志行采集时间对提取的事务上下文进行排序，确定所述待处理日志中的事务上下文。

10.根据权利要求9所述的日志处理装置，其特征在于，还包括：

第一确定模块，用于在所述提取模块根据待处理日志的日志行中设置的跟踪标识，对所述待处理日志进行事务上下文提取之前，通过所述日志打印函数在将所述日志行写入所述待处理日志时，确定待写入日志行的日志事件的所属事务的调用链；

第二确定模块，用于根据所述待写入日志行的日志事件的所属事务的调用链，确定所述待写入日志行的日志事件的跟踪标识；

第一设置模块，用于将确定的跟踪标识设置在所述待写入日志行的第一预设位置。

11.根据权利要求9或10所述的日志处理装置，其特征在于，还包括：

第三确定模块，用于在所述排序模块确定所述待处理日志中的事务上下文之后，根据确定的目标事务上下文，确定所述目标事务对应的每一调用链中的事务上下文；

第一检测模块，用于根据所述目标事务对应的每一调用链中的事务上下文，进行日志异常执行路径检测。

12.根据权利要求9至11中任一项所述的日志处理装置，其特征在于，所述提取模块具体用于：

根据所述日志行中设置的跟踪标识，以及目标事务对应的调用链中日志事件的跟踪标识，对所述待处理日志进行目标事务上下文提取。

13.根据权利要求9至12中任一项所述的日志处理装置，其特征在于，还包括：

获取模块，用于根据所述待处理日志的日志行中设置的日志事件标识，获取预设时间段内同一目标日志事件标识的日志事件的发生频次，其中，所述日志行中设置的日志事件标识通过所述日志打印函数设置在所述日志行中，用于标定全局唯一的日志事件。

14.根据权利要求13所述的日志处理装置，其特征在于，还包括：

第二检测模块，用于在所述获取模块获取预设时间段内同一目标日志事件标识的日志事件的发生频次之后，根据所述发生频次，进行日志异常事件检测。

15.根据权利要求13或14所述的日志处理装置，其特征在于，还包括：

第四确定模块，用于在所述获取模块根据所述待处理日志的日志行中设置的日志事件标识，获取预设时间段内同一目标日志事件标识的日志事件的发生频次之前，通过所述日志打印函数在将所述日志行写入所述待处理日志时，确定待写入日志行的日志事件的日志事件标识；

第二设置模块，用于将确定的日志事件标识设置在所述待写入日志行的第二预设位置。

16.根据权利要求15所述的日志处理装置，其特征在于，所述第四确定模块具体用于：

根据所述待写入日志行的日志事件对应的打印日志的语句的位置，确定所述待写入日志行的日志事件的文件名和行号；

根据所述文件名和所述行号，获得所述待写入日志行的日志事件的日志事件标识。

17.一种计算设备，其特征在于，包括：

包括处理器和存储器；

所述存储器，用于存储计算机指令；

所述处理器，用于执行所述存储器存储的计算机指令，使得所述计算设备执行权利要求1至8任一项所述的日志处理方法。

18.一种计算机可读存储介质，其特征在于，所述计算机程序产品包括计算机指令，所述计算机指令指示计算设备执行权利要求1至8任一项所述的日志处理方法。

Images