系统日志的定位方法及装置、计算机可读存储介质与流程

本发明属于运维技术领域，尤其涉及系统日志的定位方法及装置、计算机可读存储介质。

背景技术：

由于业务系统中业务量的不断增加，为了提高系统吞吐量，业务系统中引入了一系列分布式框架。在引入分布式框架后，通过应用程序编程接口(applicationprogramminginterface，api)发起业务请求时，产生的系统日志会被分散存储在不同的系统子模块或不同的服务器中，针对每个业务请求，系统后台有可能同时调用n个系统子模块或服务器对应进行服务响应，这为系统日志的定位带来了很大困难，降低了系统运维的效率。

技术实现要素：

有鉴于此，本发明实施例提供了系统日志的定位方法及装置、计算机可读存储介质，以解决在分布式框架下，对系统日志进行定位难度大的问题。

本发明实施例的第一方面提供了一种系统日志的定位方法，包括：

接收来自第一应用的第一应用程序编程接口api调用请求，api调用请求用于触发业务请求的响应过程中的一次数据调用；

从所述第一api调用请求中提取会话标识，所述会话标识用于唯一标示所述业务请求，其由所述业务请求的发起方生成并被所述第一应用写入至所述第一api调用请求中；

在输出与所述数据调用相关的日志时一并输出所述会话标识，所述会话标识被用于查找所述业务请求的响应过程中生成的日志。

本发明实施例的第二方面提供了一种系统日志的定位装置，包括：

接收单元，用于接收来自第一应用的第一应用程序编程接口api调用请求，api调用请求用于触发业务请求的响应过程中的一次数据调用；

提取单元，用于从所述第一api调用请求中提取会话标识，所述会话标识用于唯一标示所述业务请求，其由所述业务请求的发起方生成并被所述第一应用写入至所述第一api调用请求中；

日志输出单元，用于在输出与所述数据调用相关的日志时一并输出所述会话标识，所述会话标识被用于查找所述业务请求的响应过程中生成的日志。

本发明实施例的第三方面提供了一种系统日志的定位装置，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如上所述的系统日志的定位方法的步骤。

本发明实施例的第四方面提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的系统日志的定位方法的步骤。

本发明实施例与现有技术相比存在的有益效果是：在本发明实施例中，一旦业务请求发起，会话标识生成，那么该会话标识会在实现该业务请求的每一次数据调用过程中被对应的应用提取出来，并在输出与数据调用相关的日志时一并输出该会话标识，相当于与该业务请求相关的所有日志都会携带有该会话标识。因此，无论业务请求过程中调用到了分布式框架中的多少子模块或服务器，均可以通过该会话标识来进行日志定位，大大缩短了开发、测试、定位问题的时间，提升了系统运维效率。

附图说明

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

图1是本发明实施例提供提系统日志的定位方法的实现流程图；

图2是本发明另一实施例提供提系统日志的定位方法的实现流程图；

图3是本发明实施例提供的系统日志的定位方法的实现原理图图；

图4是本发明实施例提供的系统日志的定位方法的实现场景示例图；

图5是本发明实施例提供的系统日志的定位装置的结构图；

图6是本发明实施例提供的系统日志的定位装置的示意图。

具体实施方式

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

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

图1示出了本发明实施例提供提系统日志的定位方法的实现流程，详述如下：

s101：接收来自第一应用的第一应用程序编程接口api调用请求，api调用请求用于触发业务请求的响应过程中的一次数据调用。

当业务系统中发起业务请求，会通过一个或多个api进行数据调用来完成对该业务请求的响应，即，由一个或多个数据调用过程来完成业务请求过程。数据调用通常在业务系统中的两个应用之间进行，应用a通过向应用b发起api调用请求，来触发实现业务请求过程中的一次数据调用。在此，api调用的方式包括但不限于：http调用、消息队列调用和dubbo调用。

s102：从所述第一api调用请求中提取会话标识，所述会话标识用于唯一标示所述业务请求，其由所述业务请求的发起方生成并被所述第一应用写入至所述第一api调用请求中。

每发起一次业务请求，业务请求的初始发起方会生成一会话标识，该会话标识用于唯一标示该业务请求，其会出现在该业务请求的全过程中，被每一次数据调用过程对应的数据调用方写入至其发起的api调用请求中。在本发明实施例中，应用在接收到api调用请求后，从api调用请求中提取出该会话标识。

进一步地，会话标识由数据调用方在发起api调用请求前写入api调用请求的头信息，而接收到api调用请求的应用可以从api调用请求的头信息中获取到会话标识。

s103：在输出与所述数据调用相关的日志时一并输出所述会话标识，所述会话标识被用于查找所述业务请求的响应过程中生成的日志。

应用在接收到api调用请求后，一方面基于该api调用请求进行数据调用，向数据调用方返回对应的数据，另一方面，在整个数据调用过程中，应用会进行日志输出，在进行日志输出时，会一并输出该会话标识。

作为本发明的一个实施例，可以修改日志组件(例如开源日志组件logback)的配置文件，在日志组件的配置文件中增加预设逻辑，例如，增加表达式“％x{会话标识}”，其中，会话标识作为变量值，这样即可在输出每行日志的同时输出会话标识。

这样一来，实际上，一旦业务请求发起，会话标识生成，那么该会话标识会在实现该业务请求的每一次数据调用过程中被对应的应用提取出来，并在输出与数据调用相关的日志时一并输出该会话标识，相当于与该业务请求相关的所有日志都会携带有该会话标识。因此，无论业务请求过程中调用到了分布式框架中的多少子模块或服务器，均可以通过该会话标识来进行日志定位，大大缩短了开发、测试、定位问题的时间，提升了系统运维效率。通常测试可知，对于分别部署在2台服务器上的2个应用，并发量在1000以上的情况，按照传统技术，查找一个业务请求对应的所有日志，平均需要花费至少20分钟，且容易查找出错，而通过本发明实施例所提供的方案，整个日志定位过程可以缩短至1至2分钟。

进一步地，作为本发明的一个实施例，如图2所示，在本发明图1对应的实施例的基础上，该方法还包括：

s104：若在所述数据调用过程中需要向第二应用发起第二api调用请求，将所述会话标识写入所述第二api调用请求。

在响应第一应用的过程中，若嵌套有另一个数据调用过程，需要通过第二api向第二应用发起第二api调用请求，那么此时，将会话标识写入第二api调用请求，这样一来，第二应用在接收到第二api调用请求后，即可以重复与s101～s103相同的处理过程，最终也输出携带有同一会话标识的相关日志，也即实现了与该业务请求过程相关的所有日志均携带有同一会话标识的目的。

为了方便理解，以下通过实际的应用场景对本发明实施例进行进一步的描述：

对于在业务系统中发起的业务请求，为了完成对该业务请求的响应，需要由a应用调用b应用，b应用调用c应用，……，整个调用过程中，a应用将会话标识传给b应用，b应用在输出日志时，同时把会话标识一并输出至日志。同样，b应用调用c时，b应用会把会话标识传给c应用，c应用在输出日志时，把会话标识一并输出至日志，以此类推，无论该业务请求的响应过程中需要调用多少应用，会话标识都会贯穿整个业务请求的生命周期。当某个业务请求的响应出现问题时，这时往往需要查询出所有相关日志信息，用于定位出问题出现在哪个代码块。当在同一个时间段很多用户在使用业务系统时，每个用户行为都会输出日志信息，这时就很难区分出哪些日志是哪个业务请求产生的(因为在同一个时间段，业务系统中只有一个日志文件，该日志文件中可能包含了不同业务请求对应的日志信息)。若采用本发明实施例所提供的技术方案，在每行日志输出时将对应的会话标识一并输出，这时每行日志都能看出来是对应于哪个业务请求所产生的。

图3示出了本发明实施例的实现原理图，从图3可以看出，当应用之间相互进行数据调用时，调用方应用会将会话标识写入头信息中传给被调用方应用，被调用方从头信息中获取到会话标识。而logback作为业务系统所采用的日志组件，通过修改其配置文件，每个应用在产生系统日志时，都会将对应的会话标识一并输出。

接下来，基于上文所述的实施例，针对不同的api调用的方式，分别对如何进行会话标识的传递以及日志的输出进行说明：

(一)http调用方式

http接口被调用方：

首先在web应用中增加过滤器，在过滤器中获取http请求头信息中的会话标识,通过mdc.put()将会话标识放入logback当前线程上下文中，然后修改logback配置文件，增加表达式，输出会话标识变量值，如：％x{会话标识}，这样就会在每行日志输出时输出会话标识。

http接口调用方：

通过mdc.get()获取logback上下文中的会话标识，发送http请求时，将会话标识放入请求头信息中传给下一个http接口被调用方。

(二)消息队列(messagequeue，mq)调用方式

mq接收方：

首先在接到mq队列消息的message中获取到messageproperties，然后从messageproperties中获取头信息获取出会话标识，同样通过mdc.put()将会话标识放入logback当前线程上下文中，然后修改logback配置文件，增加表达式，输出会话标识变量值。

mq发送方：

通过mdc.get()获取logback上下文中会话标识，发送message时，将会话标识放入message头信息中传给下一个接收者。

(三)dubbo调用方式

dubbo接口提供者：

通过rpccontext.getcontext().getattachments().get(“会话标识”)方法获取到请求上下文中的会话标识，然后同样通过mdc.put()将会话标识放入logback当前线程上下文中，然后修改logback配置文件，增加表达式，输出会话标识变量值。

dubbo接口消费者：

通过mdc.get()获取到logback中会话标识，然后将会话标识通过rpccontext.getcontext().setattachment(“会话标识”,“值”)放入隐式参数集合中，传给下一个接收者。

图4示出了一个具体的应用场景，在该应用场景中，针对同一业务请求，a应用通过http调用方式调用b应用，b应用通过dubbo调用方式调用c应用，c应用通过mq调用方式调用d应用，在上述整个针对该业务请求的响应过程中，所产生的系统日志都会标记有同一会话标识，用于表明是在对该业务请求的响应过程中所产生的系统日志，以便于在运维过程中进行日志定位。

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

对应于上文所述的系统日志的定位方法的实施例，图5示出了本发明实施例提供的系统日志的定位装置的模块框图，该装置可为运行于业务系统中的单个应用的软件模块。为了便于说明，仅示出了与本发明实施例相关的部分。

参照图5，该装置包括：

接收单元51，用于接收来自第一应用的第一应用程序编程接口api调用请求，api调用请求用于触发业务请求的响应过程中的一次数据调用；

提取单元52，用于从所述第一api调用请求中提取会话标识，所述会话标识用于唯一标示所述业务请求，其由所述业务请求的发起方生成并被所述第一应用写入至所述第一api调用请求中；

日志输出单元53，用于在输出与所述数据调用相关的日志时一并输出所述会话标识，所述会话标识被用于查找所述业务请求的响应过程中生成的日志。

可选地，系统日志的定位装置还包括：

写入单元，若在所述数据调用过程中需要向第二应用发起第二api调用请求，写入单元用于将所述会话标识写入所述第二api调用请求。

可选地，所述日志输出单元53具体用于：

在日志组件的配置文件中增加预设逻辑，所述预设逻辑用于在输出每行日志的同时输出所述会话标识。

可选地，所述提取单元52具体用于：

从所述第一api调用请求的头信息中获取到所述会话标识，所述会话标识由所述第一应用在发起所述第一api调用请求前写入所述第一api调用请求的头信息中。

可选地，api调用的方式包括以下任意一项：

http调用、消息队列调用和dubbo调用。

图6是本发明一实施例提供的系统日志的定位装置的示意图，该装置可以安置于业务系统的服务器中。如图6所示，该实施例的系统日志的定位装置6包括：处理器60、存储器61以及存储在所述存储器61中并可在所述处理器60上运行的计算机程序62，例如系统日志的定位程序。所述处理器60执行所述计算机程序62时实现上述各个系统日志的定位方法实施例中的步骤，例如图1所示的步骤101至103。或者，所述处理器60执行所述计算机程序62时实现上述各装置实施例中各模块/单元的功能，例如图5所示模块51至53的功能。

示例性的，所述计算机程序62可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器61中，并由所述处理器60执行，以完成本发明。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序62在所述系统日志的定位装置6中的执行过程。例如，所述计算机程序62可以被分割成接收单元、提取单元和日志输出单元，各模块具体功能如下：

接收单元，用于接收来自第一应用的第一应用程序编程接口api调用请求，api调用请求用于触发业务请求的响应过程中的一次数据调用；

提取单元，用于从所述第一api调用请求中提取会话标识，所述会话标识用于唯一标示所述业务请求，其由所述业务请求的发起方生成并被所述第一应用写入至所述第一api调用请求中；

日志输出单元，用于在输出与所述数据调用相关的日志时一并输出所述会话标识，所述会话标识被用于查找所述业务请求的响应过程中生成的日志。

可选地，还包括：

写入单元，若在所述数据调用过程中需要向第二应用发起第二api调用请求，写入单元用于将所述会话标识写入所述第二api调用请求。

可选地，所述日志输出单元具体用于：

在日志组件的配置文件中增加预设逻辑，所述预设逻辑用于在输出每行日志的同时输出所述会话标识。

可选地，所述提取单元具体用于：

从所述第一api调用请求的头信息中获取到所述会话标识，所述会话标识由所述第一应用在发起所述第一api调用请求前写入所述第一api调用请求的头信息中。

可选地，api调用的方式包括以下任意一项：

http调用、消息队列调用和dubbo调用。

本领域技术人员可以理解，图6仅仅是系统日志的定位装置6的示例，并不构成对系统日志的定位装置6的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述系统日志的定位装置6还可以包括输入输出设备、网络接入设备、总线等。

所称处理器60可以是中央处理单元(centralprocessingunit，cpu)，还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器61可以是所述系统日志的定位装置6的内部存储单元，例如系统日志的定位装置6的硬盘或内存。所述存储器61也可以是所述系统日志的定位装置6的外部存储设备，例如所述系统日志的定位装置6上配备的插接式硬盘，智能存储卡(smartmediacard，smc)，安全数字(securedigital，sd)卡，闪存卡(flashcard)等。进一步地，所述存储器61还可以既包括所述系统日志的定位装置6的内部存储单元也包括外部存储设备。所述存储器61用于存储所述计算机程序以及所述系统日志的定位装置6所需的其他程序和数据。所述存储器61还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

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

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

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

所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

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