CN108768752B - 故障定位方法、装置以及系统 - Google Patents

Abstract

本申请涉及一种故障定位方法、装置以及系统。所述方法包括：第一业务节点接收业务请求，并获取业务请求的业务标识；第一业务节点根据业务标识生成第一运行日志，其中，第一运行日志记载了业务标识；第一业务节点向日志服务器发送第一运行日志；第一业务节点将业务请求发送至第二业务节点；第二业务节点获取业务标识；第二业务节点根据业务标识生成第二运行日志，其中，第二运行日志记载了业务标识；第二业务节点向日志服务器发送第二运行日志；日志服务器获取业务标识，根据业务标识查询第一运行日志和第二运行日志，以进行故障定位。上述方案能够减少计算资源和存储资源的消耗。

Description

故障定位方法、装置以及系统

技术领域

本发明涉及调用链领域，尤其涉及一种故障定位方法、装置以及系统。

背景技术

调用链技术是现时较为常用的一种故障定位方法。通过调用链技术能够跟踪业务请求，可视化的还原业务请求在业务系统中的执行轨迹和状态，从而对故障和性能瓶颈的快速进行定位。

但是，本领域的技术人员在长期研究中发现，调用链技术需要消耗大量的计算资源和存储资源，导致业务系统的性能严重下降。

发明内容

本申请实施例提供了一种故障定位方法、装置以及系统，能够减少计算资源和存储资源的消耗。

第一方面，提供了一种故障定位方法，包括如下步骤：

第一业务节点接收业务请求，并获取所述业务请求的业务标识；所述第一业务节点根据所述业务标识生成第一运行日志，其中，所述第一运行日志记载了所述业务标识；

所述第一业务节点向日志服务器发送所述第一运行日志；

所述第一业务节点将所述业务请求发送至第二业务节点；

所述第二业务节点获取所述业务标识；

所述第二业务节点根据所述业务标识生成第二运行日志，其中，所述第二运行日志记载了所述业务标识；

第二业务节点向所述日志服务器发送所述第二运行日志；

所述日志服务器获取所述业务标识，根据所述业务标识查询所述第一运行日志和所述第二运行日志，以进行故障定位。

结合第一方面，所述第一业务节点获取调用失败响应，发送所述业务标识至所述日志服务器；所述日志服务器接收所述业务标识。也就是说，在第一业务节点在获取到调用失败响应的情况下，向所述日志服务器发送所述业务标识。相应地，所述日志服务器接收所述第一业务节点发送的所述业务标识。

结合第一方面，所述业务标识可以是调用链标识也可以是运算标识，以下分别进行介绍。

(1)在所述业务标识为调用链标识时，所述第一业务节点为所述业务请求生成所述调用链标识，将所述调用链标识携带在所述业务请求中。所述第一业务节点向所述第二业务节点发送所述业务请求。所述第二业务节点接收业务请求，获取所述业务请求中携带的所述调用链标识。

(2)在所述业务标识为运算标识时，所述第一业务节点根据所述业务请求的内容生成所述运算标识。所述第一业务节点将所述业务请求发送给所述第二业务节点。所述第二业务节点根据所述业务请求的内容生成所述运算标识。

结合第一方面，所述第一运行日志和所述第二运行日志的定义如下：

所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一日常事件、发生所述第一日常事件的日期以及发生所述第一日常事件的时间戳信息，或者，所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一故障事件、发生所述第一故障事件的日期以及发生所述第一故障事件的时间戳信息。

所述第二运行日志包括所述业务标识、执行所述业务请求发生的第二日常事件、发生所述第二日常事件的日期以及发生所述第二日常事件的时间戳信息，或者，所述第一运行日志包括所述业务标识、执行所述业务请求发生的第二故障事件、发生所述第二故障事件的日期以及发生所述第二故障事件的时间戳信息。

第二方面，提供了一种日志生成方法，包括如下步骤：

第一业务节点接收业务请求，并获取所述业务请求的业务标识；

所述第一业务节点根据所述业务标识生成第一运行日志，其中，所述第一运行日志记载了所述业务标识；

所述第一业务节点向日志服务器发送所述第一运行日志；

所述第一业务节点将所述业务请求发送至第二业务节点；

所述第一业务节点将所述业务标识发送至第二业务节点，以供第二业务节点根据所述业务标识生成第二运行日志。

结合第二方面，所述业务标识可以是调用链标识也可以是运算标识，以下分别进行介绍。

(1)在所述业务标识为调用链标识时，所述第一业务节点为所述业务请求生成所述调用链标识，将所述调用链标识携带在所述业务请求中。

(2)在所述业务标识为运算标识时，所述第一业务节点根据所述业务请求的内容生成所述运算标识。

结合第二方面，所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一日常事件、发生所述第一日常事件的日期以及发生所述第一日常事件的时间戳信息；或者，所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一故障事件、发生所述第一故障事件的日期以及发生所述第一故障事件的时间戳信息。

第三方面，提供一种故障定位方法，包括如下步骤：

日志服务器接收第一业务节点发送的第一运行日志，其中，所述第一运行日志记载了业务标识；

所述日志服务器接收第二业务节点发送的第二运行日志，其中，所述第二运行日志记载了所述业务标识；

所述日志服务器获取所述业务标识，根据所述业务标识查询所述第一运行日志和所述第二运行日志，以进行故障定位。

结合第三方面，所述业务标识为调用链标识或者运算标识。

结合第三方面，所述第一运行日志和所述第二运行日志的定义可以是：

所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一日常事件、发生所述第一日常事件的日期以及发生所述第一日常事件的时间戳信息；或者，所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一故障事件、发生所述第一故障事件的日期以及发生所述第一故障事件的时间戳信息。

所述第二运行日志包括所述业务标识、执行所述业务请求发生的第二日常事件、发生所述第二日常事件的日期以及发生所述第二日常事件的时间戳信息；或者，所述第二运行日志包括所述业务标识、执行所述业务请求发生的第二故障事件、发生所述第二故障事件的日期以及发生所述第二故障事件的时间戳信息。

第四方面，提供一种故障定位系统，包括第一业务节点、第二业务节点以及日志服务器，其中，所述日志服务器分别连接所述第一业务节点以及所述第二业务节点，其中，

所述第一业务节点用于接收业务请求，并获取所述业务请求的业务标识；

所述第一业务节点用于根据所述业务标识生成第一运行日志，其中，所述第一运行日志记载了所述业务标识；

所述第一业务节点用于向日志服务器发送所述第一运行日志；

所述第一业务节点将所述业务请求发送至第二业务节点；

所述第二业务节点用于获取所述业务标识；

所述第二业务节点用于根据所述业务标识生成第二运行日志，其中，所述第二运行日志记载了所述业务标识；

第二业务节点用于向所述日志服务器发送所述第二运行日志；

所述日志服务器用于获取所述业务标识，根据所述业务标识查询所述第一运行日志和所述第二运行日志，以进行故障定位。

结合第四方面，所述第一业务节点用于获取调用失败响应，发送所述业务标识至所述日志服务器；所述日志服务器用于接收所述业务标识。也就是说，在第一业务节点在获取到调用失败响应的情况下，向所述日志服务器发送所述业务标识。相应地，所述日志服务器接收所述第一业务节点发送的所述业务标识。

结合第四方面，所述业务标识可以是调用链标识也可以是运算标识，以下分别进行介绍。

(1)在所述业务标识为调用链标识时，所述第一业务节点用于为所述业务请求生成所述调用链标识，将所述调用链标识携带在所述业务请求中。所述第一业务节点用于向所述第二业务节点发送所述业务请求。所述第二业务节点用于接收业务请求，获取所述业务请求中携带的所述调用链标识。

(2)在所述业务标识为运算标识时，所述第一业务节点用于根据所述业务请求的内容生成所述运算标识。所述第一业务节点用于将所述业务请求发送给所述第二业务节点。所述第二业务节点用于根据所述业务请求的内容生成所述运算标识。

结合第四方面，所述第一运行日志和所述第二运行日志的定义可以如下所示：

所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一日常事件、发生所述第一日常事件的日期以及发生所述第一日常事件的时间戳信息；或者，所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一故障事件、发生所述第一故障事件的日期以及发生所述第一故障事件的时间戳信息。

所述第二运行日志包括所述业务标识、执行所述业务请求发生的第二日常事件、发生所述第二日常事件的日期以及发生所述第二日常事件的时间戳信息；或者，所述第二运行日志包括所述业务标识、执行所述业务请求发生的第二故障事件、发生所述第二故障事件的日期以及发生所述第二故障事件的时间戳信息。

第五方面，提供一种日志服务器，包括接收模块、故障定位模块以及发送模块，

所述接收模块用于接收第一业务节点发送的第一运行日志，其中，所述第一运行日志记载了业务标识；

所述接收模块用于接收第二业务节点发送的第二运行日志，其中，所述第二运行日志记载了所述业务标识；

所述故障定位模块用于获取所述业务标识，根据所述业务标识查询所述第一运行日志和所述第二运行日志，以进行故障定位；

所述发送模块用于将所述业务请求发送至第二业务节点；

所述发送模块用于将所述业务标识发送至第二业务节点，以供第二业务节点根据所述业务标识生成第二运行日志。

结合第五方面，所述业务标识为调用链标识或者运算标识。

结合第五方面，所述第一运行日志和所述第二运行日志的定义可以如下所示：

所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一日常事件、发生所述第一日常事件的日期以及发生所述第一日常事件的时间戳信息；或者，所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一故障事件、发生所述第一故障事件的日期以及发生所述第一故障事件的时间戳信息。

所述第二运行日志包括所述业务标识、执行所述业务请求发生的第二日常事件、发生所述第二日常事件的日期以及发生所述第二日常事件的时间戳信息；或者，所述第二运行日志包括所述业务标识、执行所述业务请求发生的第二故障事件、发生所述第二故障事件的日期以及发生所述第二故障事件的时间戳信息。

第六方面，提供一种日志服务器，包括处理器和存储器，所述处理器用于执行所述存储器中的代码，执行如第三方面任一项所述的方法。

第七方面，提供一种计算机可读存储介质，包括指令，当所述指令在业务节点上运行时，使得所述业务节点执行如第二方面任意一项所述的方法。该计算机可读存储介质可以为非瞬态(non-transitory)的存储介质。

第八方面，一种计算机可读存储介质，其特征在于，当所述指令在日志服务器上运行时，使得所述日志服务器执行如第三方面任一项所述的方法。该计算机可读存储介质可以为非瞬态的存储介质。

第九方面，提供了一种程序产品，当所述程序产品在业务节点上运行时，使得所述业务节点执行如第二方面任意一项所述的方法。

第十方面，提供了一种程序产品，当所述所述程序产品在日志服务器上运行时，使得所述日志服务器执行如第三方面任意一项所述的方法。

上述方案中，通过在第一日志和第二日志中写入业务请求的业务标识，然后，将第一日志和第二日志上传日志服务器。日志服务器根据业务标识查询第一日志和第二日志，从而定位故障。由于日志服务器可以根据原来已经存在的第一日志和第二日志进行故障定位，因此，，能够有效减少能够减少计算资源和存储资源的消耗。

附图说明

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

图1是本申请涉及的云系统的一实施方式的结构示意图；

图2是本申请涉及的云业务的调用关系的一实施方式的结构示意图；

图3A-3B是图2所示的云业务的两种可能的响应的示意图；

图4是云系统中的云业务生成调用链和不生成调用链的示意图；

图5是本申请提供的一种故障定位方法的交互示意图；

图6A-6B是本申请提供的故障定位系统的结构示意图；

图7是本申请提供的一种故障定位系统的结构示意图；

图8是本申请提供的一种故障定位系统的结构示意图。

具体实施方式

本申请的技术方案可以应用各种业务系统中，为了陈述简便，下面以云系统和云业务为例进行说明。

云系统中存在多个应用，并且，多个应用之间互相依赖，因此，云系统的结构十分复杂。为了降低云系统的复杂性，可以将多个应用的一些共用功能独立成服务提供给多个应用使用，例如，可以将多个应用的底层功能拆分为多个服务以提供给多个应用进行使用，从而实现共用功能的模块化以及共用功能的解耦，以便于多个应用重复利用。举个例子说明，如图1所示，云系统包括应用层、服务层以及底层，其中，应用层包括应用A、应用B、应用C以及应用D。服务层包括从应用A、应用B、应用C以及应用D的底层功能中独立出服务1、服务2、服务3以及服务4。底层包括数据库、缓存系统、分布式文件系统以及搜索引擎等等。其中，服务1至服务4中的任意一个应用都可以为应用A至应用D中的任意一个应用提供服务。上述图1中的云系统仅仅是作为一个举例，不应构成具体的限定。

云业务被执行时需要多个应用以及多个服务之间进行配合，因此，多个应用以及多个服务之间存在复杂的调用关系。举个例子说明，如图2所示，云业务的多个业务节点(包括应用和服务)之间存在这样的调用关系：用户向应用A节点提出云业务请求，应用A根据云业务请求执行云业务并调用服务1节点提供服务，服务1节点提供完服务后，向应用A节点返回响应。应用A节点根据服务1节点返回的响应继续执行云业务并调用服务2节点提供服务，服务2节点再调用服务3节点提供服务，服务3节点提供完服务后，向服务2节点返回响应，服务2节点再调用服务4节点提供服务，服务4节点提供完服务后，向服务2节点返回响应，服务2节点再向应用A节点返回响应。应用A节点再根据服务2节点返回的响应继续执行云业务。上述图2所示的调用关系仅仅是作为一个举例。

图2所示的云业务被执行时，存在两种可能的结果：(1)云业务被执行成功；(2)云业务被执行失败。其中，云业务被执行成功时的调用过程和云业务被执行失败时的调用响应是不相同的。下面将分别对云业务被执行成功和云业务被执行失败两种不同情况下的调用响应进行详细的介绍。

(1)云业务被执行成功时的调用响应具体为：如图3A所示，用户向应用A节点提出云业务请求，应用A根据云业务请求执行云业务并调用服务1节点提供服务，服务1节点提供完服务后，向应用A节点返回调用成功响应。应用A节点根据服务1节点返回的调用成功响应继续执行云业务并调用服务2节点提供服务，服务2节点再调用服务3节点提供服务，服务3节点提供完服务后，向服务2节点返回调用成功响应，服务2节点再调用服务4节点提供服务，服务4节点提供完服务后，向服务2节点返回调用成功响应，服务2节点再向应用A节点返回调用成功响应。应用A节点再根据服务2节点返回的调用成功响应继续执行云业务，并提示云业务执行成功。

(2)云业务被执行失败时的调用响应具体为：如图3B所示，用户向应用A节点提出云业务请求，应用A根据云业务请求执行云业务并调用服务1节点提供服务，服务1节点提供完服务后，向应用A节点返回调用成功响应。应用A节点根据服务1节点返回的调用成功响应继续执行云业务并调用服务2节点提供服务，服务2节点再调用服务3节点提供服务，服务3节点提供完服务后，向服务2节点返回调用成功响应，服务2节点再调用服务4节点提供服务，服务4节点提供服务失败，向服务2节点返回调用失败响应，服务2节点再向应用A节点返回调用失败响应。应用A节点再根据服务2节点返回的调用失败响应终止执行云业务，并提示云业务执行失败。

在云业务被执行失败时，云系统需要对云业务的故障进行跟踪定位。但是，随着云系统和云业务变得越来越复杂，云业务的故障定位也变得越来越复杂。以图2为例，从用户的角度来看，用户向应用A节点提出了云业务请求之后，如果云业务执行成功，则应用A节点向用户提示云业务执行成功，如果云业务执行失败，则应用A节点向用户提示云业务执行失败。在应用A节点向用户提示云业务执行失败的情况下，用户只能确定该云业务被执行失败了，但是，应用A节点在执行云业务时直接或者间接调用了服务1节点、服务2节点、服务3节点以及服务4节点，用户难以确定在执行云业务时是哪个业务节点出现了故障。

为了便于对故障进行跟踪定位，提出了一种调用链日志式故障定位方法。在该方法中，云系统可以为云业务生成调用链。其中，调用链包括多个调用链节点，每个调用链节点对应该云业务的一个业务节点。如图4所示，由于生成调用链会占用云系统的资源，因此，在需要对云业务进行故障的跟踪定位的情况下，云系统可以为云业务生成调用链(如图中实线所示)；在不需要对云业务进行故障的跟踪定位的情况下，云系统可以不为云业务生成调用链(如图中虚线所示)。在云系统为云业务生成调用链的情况下，调用链上每个调用链节点可以生成调用链日志以及运行日志。在云系统不为云业务生成调用链的情况下，云业务的每个业务节点可以只生成运行日志，不生成调用链日志。其中，业务节点可以包括业务逻辑单元以及调用链软件开发包，其中，业务逻辑单元用于生成运行日志，调用链软件开发包用于生成调用链日志。

运行日志用于记载所述执行所述业务请求发生的事件记录、发生所述事件记录的日期以及发生所述事件记录的时间戳信息等等。其中，事件记录可以是日常事件或者故障事件。其中，日常事件用于记载本业务节点发生的普通事件，例如，日常事件可以是业务节点的参数被重新配置事件等等。故障事件用于记载本业务节点发生的故障，例如，故障事件可以是业务节点的调用参数超出了参数范围事件等等。在一具体的实施例中，运行日志可以如表1所示。

表1 运行日志

调用链日志用于记载调用链信息以及事件信息。其中，调用链信息包括调用链标识(TraceID)，本节点标识(Span ID)以及父节点标识(Parent ID)。其中，调用链标识为调用链的唯一标识，本节点标识为本调用链节点的唯一标识，父节点标识为调用本调用链节点的上一个调用链节点的标识。上述调用链信息的表示方法仅仅作为一个示例，在其他的实施方式中，调用链信息也可以采用其他的方式进行表示，例如，调用链信息至少包括调用链标识(Trace ID)，本节点标识(Span ID)，父节点标识(Parent ID)以及子节点标识(Child ID)等等，其中，子节点标识为本调用链节点调用的下一个调用链节点的标识。以图2所示的调用关系为例，应用A节点对应的调用链节点的调用链信息为调用链标识TraceID1，本节点标识为应用A标识，父节点标识为无。服务1节点对应的调用链节点的调用链信息为调用链标识TraceID 1，本节点标识为服务1节点标识，父节点标识为应用A节点标识。服务2节点对应的调用链节点的调用链信息为调用链标识TraceID 1，本节点标识为服务2节点标识，父节点标识为服务1节点标识。服务3节点对应的调用链节点的调用链信息为调用链标识TraceID1，本节点标识为服务3节点标识，父节点标识为服务2节点标识。服务4节点对应的调用链节点的调用链信息为调用链标识TraceID 1，本节点标识为服务4节点标识，父节点标识为服务2节点标识。事件信息包括本节点被调用的时间、本节点返回响应的时间、故障事件、协议类型以及协议参数等等。其中，协议类型可以是发现和基本配置协议(discovery and basic configuration protocol，DCP)、超文本传输协议(hyper texttransfer protocol，HTTP)等等。协议参数可以是统一资源定位符(uniform resourcelocator，URL)、用户名以及请求数据内容等等。在一具体的实施例中，调用链日志可以如表2所示。

表2 调用链日志

调用链上的每个调用链节点可以通过有线或者无线的方式将调用链日志发送给日志服务器。日志服务器接收到调用链上的每个调用链节点通过有线或者无线的方式发送的调用链日志之后，根据每个调用链节点的调用链日志的调用链信息还原云业务的调用关系。其中，还原的云业务的调用关系可以采用调用关系树的形式进行表示。然后，日志服务器结合调用关系树以及每个调用链节点的事件信息对故障进行跟踪定位。应理解，上述调用关系树仅仅是调用关系的其中一种表示方式，在其他可能的实施方式中，还可以采用其他的表示方式对调用关系进行表示，例如调用关系图，此处不作具体限定。

为了能够保障云系统的高效运行，云系统需要为每个云业务都生成一条调用链以对每个云业务是否出现故障进行跟踪。但是，在云系统中运行的云业务的数量是成千上万的，如果为每一个云业务都生成一条调用链，并且，每条调用链中的每个调用链节点都生成调用链日志，会导致云系统的计算资源和存储资源被大量消耗，从而导致云系统的整体性能大大下降。

本申请提供了一种故障定位方法、装置以及系统，能够减少计算资源和存储资源的消耗。下面将分别进行详细的介绍。

参阅图5，图5是本申请提供的一种故障定位方法的交互示意图。本申请的故障定位方法包括如下步骤：

S101：第一业务节点接收业务请求，并获取所述业务请求的业务标识。

S102：所述第一业务节点根据所述业务标识生成第一运行日志，其中，所述第一运行日志记载了所述业务标识。

S103：所述第一业务节点向日志服务器发送所述第一运行日志。相应地，日志服务器接收所述第一业务节点发送的所述第一运行日志。

S104：所述第一业务节点将所述业务请求发送至第二业务节点。相应地，第二业务节点接收所述第一业务节点发送的所述业务请求。

S105：所述第二业务节点获取所述业务标识。

S106：所述第二业务节点根据所述业务标识生成第二运行日志，其中，所述第二运行日志记载了所述业务标识。

S107：第二业务节点向所述日志服务器发送所述第二运行日志。相应地，日志服务器接收所述第二业务节点发送的第二运行日志。

S108：所述日志服务器获取所述业务标识，根据所述业务标识查询所述第一运行日志和所述第二运行日志，以进行故障定位。

可以理解，上述步骤S101-S108的顺序并非固定不变的，在实际应用中，步骤S101-S108的顺序也可以进行调整，例如，步骤S103也可以放到步骤S107之前，此处不作具体限定。

在本申请实施方式中，第一业务节点和第二业务节是执行同一个业务请求(例如，云业务请求)的业务节点。其中，

第一业务节点可以是首节点也可以是非首节点，第二业务节点可以是非首节点之外的任何一个节点，此处不做具体限定。举个例子说明，假设云业务包括依次连接的A业务节点、B业务节点、C业务节点，D业务节点，则第一业务节点可以是A业务节点(首节点)，也可以是B业务节点、C业务节点以及D业务节点中的任意一个节点(非首节点)。上述举例仅仅是一个示例，不应构成具体限定。

第一业务节点和第二业务节点之间可以是直接连接的，也可以是间接连接的，此处不做具体限定。举个例子说明，假设云业务包括依次连接的A业务节点、B业务节点、C业务节点，D业务节点。第一业务节点可以是A节点，第二业务节点可以是B节点(直接连接)。或者，第一业务节点可以是A节点，第二业务节点可以是C节点(间接连接)。上述举例仅仅是一个示例，不应构成具体限定。

应理解，第一业务节点和第二业务节点可以是指一个节点，也可以是指同一类节点，此处不作具体限定。

在本申请实施方式中，业务标识可以是调用链标识也可以是运算标识等等。下面将分别对调用链标识和运算标识进行详细的介绍。

当业务标识是调用链标识时，调用链标识需要从第一业务节点传递至第二业务节点。具体地，所述第一业务节点为所述业务请求生成所述调用链标识，将所述调用链标识携带在所述业务请求中；所述第二业务节点接收业务请求，获取所述业务请求中携带的所述调用链标识。在这种方式下，如果所述云业务执行失败，则云系统可以继续使用所述调用链标识为该云业务生成调用链，以进一步对该云业务的故障进行跟踪定位。

当业务标识是运算标识时，运算标识不需要从第一业务节点传递至第二业务节点。具体地，所述第一业务节点可以单独地根据所述业务请求的内容生成所述运算标识，所述第二业务节点可以单独地根据所述业务请求的内容生成所述运算标识。其中，所述业务请求的内容可以是所述业务请求的报文头，或者，所述业务请求携带的云标识等等，此处不作具体限定。举个例子说明，第一业务节点在接收到业务请求时，可以根据业务请求的报文头进行哈希运算从而得到第一运算值，并将所述第一运算值作为所述运算标识。第二业务节点在接收到第一业务节点发送的业务请求之后，可以根据业务请求的报文头进行哈希运算从而得到第二运算值，并将所述第二运算值作为所述运算标识。经过哈希运算后的第一运算值和第二运算值是相同的。通过上述方式，运算标识是云业务的每个业务节点根据所述业务请求的内容自行计算得到的，不需要占用数据传输的资源。

应理解，上述调用链标识和运算标识仅仅是业务标识的部分举例，在其他的实施方式中，业务标识还可以是云业务标识等等其他标识，此处不作具体限定。

在本申请实施方式中，第一运行日志和第二运行日志中均写入了业务标识。与现有技术的运行日志相比，第一运行日志和第二运行日志中增加了业务标识。其中，

所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一事件记录、发生所述第一事件记录的日期以及发生所述第一事件记录的时间戳信息等等。其中，第一事件记录可以是第一日常事件或者第一故障事件。应理解，第一运行日志可以包括更少或者更多的元素，例如，第一运行日志可以不包括发生所述第一事件记录的时间戳信息，或者，第一运行日志还可以包括本节点的节点标识等等，此处不作具体限定。在一具体的实施例中，第一运行日志可如表3所示。

所述第二运行日志包括所述业务标识、执行所述业务请求发生的第二事件记录、发生所述第二事件记录的日期以及发生所述第二事件记录的时间戳信息等等。其中，第二事件记录可以是第二日常事件或者第二故障事件。应理解，第二运行日志可以包括更少或者更多的元素，例如，第二运行日志可以不包括发生所述第二事件记录的时间戳信息，或者，第二运行日志还可以包括本节点的节点标识等等，此处不作具体限定。在一具体的实施例中，第二运行日志可如表4所示。

表3第一运行日志

表4 第二运行日志

第二事件记录	日期	时间戳信息	业务标识
				日常事件1	日期1	时间戳信息1	TraceID 1
日常事件2	日期2	时间戳信息2	TraceID 4
				故障事件1	日期3	时间戳信息3	TraceID 2
…	…	…	…

应理解，上述表3和表4仅仅是第一运行日志和第二运行日志的一个具体示例，在其他的可能的实施方式中，第一运行日志和第二运行日志还可以是其他的形式，此处不作具体限定。

在本申请实施方式中，日志服务器获取业务标识的方法可以有多种。在一具体的实施例中，第一业务节点可以生成调用链日志，其中，业务标识可以承载在调用链日志中。然后，第一业务节点将调用链日志发送给日志服务器。相应地，日志服务器相应接收第一业务节点发送的调用链日志，并从调用链日志中获取所述业务标识。在其他的实施例中，业务标识也可以承载在其他类型的日志，例如，系统日志等等中。甚至，业务标识也可以不承载在任何类型的日志中，而是承载于其他的日志服务器可以访问的载体中。

在本申请实施方式中，在第一业务节点接收到调用失败响应的情况下，第一业务节点生成调用链日志。此时，只有在第一业务节点接收到调用失败响应的情况下，第一业务节点生成调用链日志，并发送给日志服务器。日志服务器从调用链日志获取业务标识，并根据业务标识查询第一日志和第二日志以进行故障定位。简单来说，只有在第一业务节点接收到调用失败响应的情况下，日志服务器才会进行故障定位，从而减少系统资源的消耗。当然，在第一业务节点接收到调用成功响应的情况下，第一业务节点也可以生成调用链日志，此处不作具体限定。

在本申请实施方式中，第一业务节点接收到调用失败响应的原因可以包括：重试、响应码、超时、耗时、校验、鉴权、协商以错包等等。表5中分别从各个原因的描述、判断原理以及举例的角度进行描述。应理解，第一业务节点接收到调用失败响应的原因还可以包括更多或者更少的原因，此处不作具体限定。

表5 调用失败响应的各种原因

在本申请实施方式中，调用链日志用于记载调用链标识。在一具体的实施例中，如表6所示，调用链日志可以只记载调用链标识，而不记载本节点标识、父节点标识、本节点被调用的时间、本节点返回响应的时间、故障事件、协议类型以及协议参数等等。此时，表6中的调用链日志的数据量相对于表2中的调用链日志的数据量大幅减少。可以理解，表6中的调用链日志也可以包括本节点标识、父节点标识、本节点被调用的时间、本节点返回响应的时间、故障事件、协议类型以及协议参数等等中的一个或者多个。甚至，调用链日志还可以包括其他的信息，此处不作具体限定。

表6 调用链日志

以云系统为例，云系统上通常同时存在多个云业务。其中，云系统上的每个云业务都可以采用图5所示的方法进行故障定位，或者，云系统上的部分云业务可以采用图5所示的方法(简称：运行日志式故障定位方法)进行故障定位，剩下的部分可以采用现有的故障定位方法进行故障定位，此处不作具体限定。

下面说明云系统上的部分云业务可以采用图5所示的运行日志式故障定位方法进行故障定位，剩下的部分采用调用链日志式故障定位方法进行故障定位的具体实施例。

图6A示出了当第一业务节点生成调用链日志时，云系统上的部分云业务采用运行日志式故障定位方法进行故障定位，剩下的部分云业务采用调用链日志式故障定位方法进行故障定位的具体实施例。其中，实线经过的业务节点为采用了调用链日志式故障定位方法的云业务的业务节点，虚线经过的业务节点为采用了运行日志式故障定位方法的云业务的业务节点。采用了运行日志式故障定位方法的云业务的业务节点中，第一业务节点(A业务节点)生成了携带业务标识的调用链日志和携带业务标识的运行日志，第二业务节点(B业务节点和C业务节点)生成了携带业务标识的运行日志。采用了运行调用链式故障定位方法的业务节点中，每个业务节点(a业务节点、b业务节点以及c业务节点)都生成了运行日志和调用链日志。

图6B示出了当第一业务节点没有生成调用链日志时，云系统上的部分云业务采用运行日志式故障定位方法进行故障定位，剩下的部分云业务采用调用链日志式故障定位方法进行故障定位的具体实施例。其中，实线经过的业务节点为采用调用链日志式故障定位方法的云业务的业务节点，虚线经过的业务节点为采用运行日志式故障定位方法的云业务的业务节点。在采用运行日志式故障定位方法的云业务的业务节点中，第一业务节点(A业务节点)和第二业务节点(B业务节点和C业务节点)均生成了携带业务标识的携带业务标识的运行日志。在采用调用链日志式故障定位方法的云业务的业务节点中，每个业务节点(a业务节点、b业务节点以及c业务节点)都生成了运行日志以及调用链日志。

应理解，图6A和图6B所示的实施例仅仅作为部分具体的示例，此处不作具体限定。

参阅图7，图7是本申请提供的一种故障定位系统的结构示意图。如图7所示，本申请的故障定位系统包括：日志服务器、第一业务节点以及第二业务节点，其中，日志服务器可以通过有线或者无线的方式分别连接所述第一业务节点以及所述第二业务节点，所述第一业务节点可以通过有线或者无线的方式连接所述第二业务节点。第一业务节点可以生成携带业务标识的第一运行日志，并发送给所述日志服务器。第二业务节点可以生成携带业务标识的第二运行日志，并发送给所述日志服务器。

如图7所示，日志服务器可以包括：接收模块111以及故障定位模块112，其中，接收模块111用于执行图5所示的方法中的步骤S103以及步骤S107中日志服务器的操作。故障故障定位模块112用于执行图5所示的方法中的步骤S108。第一业务节点可以包括：接收模块121、生成模块122以及发送模块123，其中，接收模块121用于执行图5所示的方法中的步骤S101。生成模块122用于执行图5所示的方法中的步骤S102。所述发送模块123用于执行图5所示的方法中的步骤S103以及S104中第一业务节点的操作。第二业务节点可以包括：接收模块131、生成模块132以及发送模块133，其中，接收模块131用于执行图5所示的方法中的步骤S104的第二业务节点的操作以及步骤S105的操作。所述生成模块132用于执行图5所示的方法中的步骤S107。所述发送模块133用于执行图5所示的方法中步骤S107中第二业务节点的操作。

参阅图8，图8是本申请实施例提供的一种故障定位系统的结构示意图。如图8所示，本申请的故障定位系统包括：一个或者多个日志服务器、一个或者多个第一业务节点以及一个或者多个第二业务节点，其中，日志服务器可以通过有线或者无线的方式分别连接所述第一业务节点以及所述第二业务节点，所述第一业务节点可以通过有线或者无线的方式连接所述第二业务节点。第一业务节点可以生成携带业务标识的第一运行日志，并发送给所述日志服务器。第二业务节点可以生成携带业务标识的第二运行日志，并发送给所述日志服务器。

如图8所示，日志服务器211包括一个或多个处理器211、通信接口212和存储器214。其中，处理器211、通信接口212和存储器214之间可以通过总线213连接。

处理器211包括一个或者多个通用处理器，其中，通用处理器可以是能够处理电子指令的任何类型的设备，包括中央处理器(central processing unit，CPU)、微处理器、微控制器、主处理器、控制器以及专用集成电路(application specific integratedcircuit，ASIC)等等。它能够是仅用于日志服务器的专用处理器或者能够与其它服务器或者业务节点共享。处理器211执行各种类型的数字存储指令，例如存储在存储器214中的软件或者固件程序，它能使日志服务器211提供较宽的多种服务。例如，处理器211能够执行程序或者处理数据，以执行本文介绍的方法的至少一部分。

通信接口212可以为有线接口(例如以太网接口)或无线接口(例如蜂窝网络接口或使用无线局域网接口)，用于与其他计算设备或用户进行通信。

存储器214可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，RAM)；存储器也可以包括非易失性存储器(non-volatilememory)，例如只读存储器(read-only memory，ROM)、快闪存储器(flash memory)、硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)存储器还可以包括上述种类的存储器的组合。存储器214可以采用集中式存储，也可以采用分布式存储，此处不作具体限定。在本申请的具体实施例中，存储器214中存储了第一业务节点发送的第一运行日志、第二业务节点发送的第二运行日志以及第一业务节点发送的调用链日志等等。此外，存储器214还可以存储有其他的日志，例如，安全日志、系统日志等等。

第一业务节点包括一个或多个处理器221、通信接口222和存储器224。其中，处理器221、通信接口222和存储器224之间可以通过总线223连接。

处理器221包括一个或者多个通用处理器，其中，通用处理器可以是能够处理电子指令的任何类型的设备，包括CPU、微处理器、微控制器、主处理器、控制器以及ASIC等等。它能够是仅用于第一业务节点的专用处理器或者能够与业务节点或者日志服务器共享。处理器221执行各种类型的数字存储指令，例如存储在存储器224中的软件或者固件程序，它能使第一业务节点提供较宽的多种服务。例如，处理器221能够执行程序或者处理数据，以执行本文介绍的方法的至少一部分。在本申请的实施例中，处理器221执行存储器224中的软件或者固件程序可以实现业务逻辑单元以及调用链软件开发包，其中，业务逻辑单元用于生成第一运行日志，调用链软件开发包用于生成调用链日志。

通信接口222可以为有线接口(例如以太网接口)或无线接口(例如蜂窝网络接口或使用无线局域网接口)，用于与其他计算设备或用户进行通信。当通信接口222为有线接口时，通信接口222可以采用TCP/IP之上的协议族，例如，RAAS协议、RFC协议、SOAP协议、SNMP协议、CORBA协议以及分布式协议等等。当通信接口222为无线接口时，可以根据GSM或者CDMA标准利用蜂窝通信，因此包括用于用于数据传输的无线调制解调器、电子处理设备、一个或多个数字存储器设备以及双天线。应该明白，调制解调器能够通过存储在第一业务节点内的软件实施且由处理器221执行，或者它能够是位于第一业务节点内部或者外部的分开的硬件部件。调制解调器能够使用任何数量的不同标准或者协议来运行。

存储器224可以包括易失性存储器，例如RAM；存储器也可以包括非易失性存储器，例如ROM、快闪存储器、HDD或SSD存储器还可以包括上述种类的存储器的组合。存储器224可以用于存储处理器221生成的第一运行日志。并且，当调用链软件开发包生成调用链日志时，所述存储器224还用于存储调用链日志。

第二业务节点包括一个或多个处理器231、通信接口232和存储器234。其中，处理器231、通信接口232和存储器234之间可以通过总线233连接。

处理器231包括一个或者多个通用处理器，其中，通用处理器可以是能够处理电子指令的任何类型的设备，包括CPU、微处理器、微控制器、主处理器、控制器以及ASIC等等。它能够是仅用于第二业务节点的专用处理器或者能够与业务节点或者日志服务器共享。处理器231执行各种类型的数字存储指令，例如存储在存储器234中的软件或者固件程序，它能使第二业务节点提供较宽的多种服务。例如，处理器231能够执行程序或者处理数据，以执行本文讨论的方法的至少一部分。在本申请的实施例中，处理器231可以包括业务逻辑单元以及调用链软件开发包，其中，业务逻辑单元用于生成第二运行日志，调用链软件开发包用于生成调用链日志。

通信接口232可以为有线接口(例如以太网接口)或无线接口(例如蜂窝网络接口或使用无线局域网接口)，用于与其他计算设备或用户进行通信。当通信接口232为有线接口时，通信接口232可以采用TCP/IP之上的协议族，例如，RAAS协议、RFC协议、SOAP协议、SNMP协议、CORBA协议以及分布式协议等等。当通信接口232为无线接口时，可以根据GSM或者CDMA标准利用蜂窝通信，因此包括用于用于数据传输的无线调制解调器、电子处理设备、一个或多个数字存储器设备以及双天线。应该明白，调制解调器能够通过存储在第二业务节点内的软件实施且由处理器231执行，或者它能够是位于第二业务节点内部或者外部的分开的硬件部件。调制解调器能够使用任何数量的不同标准或者协议来运行。

存储器234可以包括易失性存储器，例如RAM；存储器也可以包括非易失性存储器，例如ROM、快闪存储器、HDD或SSD存储器还可以包括上述种类的存储器的组合。存储器234可以用于存储处理器231生成的第一运行日志。并且，当调用链软件开发包生成调用链日志时，所述存储器234还用于存储调用链日志。

本实施例的日志服务器执行的是图5所示的故障定位方法中步骤S103以及步骤S107中日志服务器的操作，和，图5所示的故障定位方法中步骤S108的操作。本实施例的第一业务节点执行的是图5所示的故障定位方法中步骤S101，步骤S102，步骤S103中第一业务节点的操作，步骤S104中第一业务节点的操作。本实施例的第二业务节点执行的是图5所示的故障定位方法中步骤S105，步骤S106，步骤S107中第二业务节点的操作，具体请参见图5以及相关描述，此处不在展开赘述。

本实施例的日志服务器还可以是图7所示的故障定位系统中的日志服务器，本实施例的第一业务节点还可以是图7所示的故障定位系统中的第一业务节点，本实施例的第二业务节点还可以是图7所示的故障定位系统中的第二业务节点，此处不做具体限定。

上述方案中，通过在第一日志和第二日志中写入业务请求的业务标识，然后，将第一日志和第二日志上传日志服务器。日志服务器根据业务标识查询第一日志和第二日志，从而定位故障。由于日志服务器可以利用原来已经存在的第一日志和第二日志进行故障定位，因此，能够有效减少能够减少计算资源和存储资源的消耗。

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

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

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

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (15)

1.一种故障定位方法，其特征在于，包括如下步骤：

第一业务节点接收业务请求，并获取所述业务请求的业务标识；所述第一业务节点根据所述业务标识生成第一运行日志，其中，所述第一运行日志记载了所述业务标识；

所述第一业务节点向日志服务器发送所述第一运行日志；

所述第一业务节点将所述业务请求发送至第二业务节点；

所述第二业务节点获取所述业务标识；

所述第二业务节点根据所述业务标识生成第二运行日志，其中，所述第二运行日志记载了所述业务标识；

第二业务节点向所述日志服务器发送所述第二运行日志；

在所述第一业务节点接收到调用失败响应的情况下，所述第一业务节点生成对应调用链的调用链日志并发送给所述日志服务器，所述调用链包括对应所述第一业务节点与所述第二业务节点的调用链节点，所述调用链日志用于记载调用链信息以及事件信息，所述调用链信息包括调用链标识，每一个所述调用链具有唯一标识的所述调用链标识，所述日志服务器依据所述调用链信息还原所述第一业务节点与所述第二业务节点的调用关系，以及从所述调用链日志获取所述调用链节点对应的所述业务标识，并根据所述业务标识查询所述第一运行日志和所述第二运行日志，以进行故障定位。

2.根据权利要求1所述的方法，其特征在于，所述业务标识为调用链标识，

所述第一业务节点获取所述业务请求的业务标识包括：所述第一业务节点为所述业务请求生成所述调用链标识，将所述调用链标识携带在所述业务请求中；

所述第二业务节点获取所述业务标识包括：所述第二业务节点接收业务请求，获取所述业务请求中携带的所述调用链标识。

3.根据权利要求1所述的方法，其特征在于，所述业务标识为运算标识，

所述第一业务节点获取所述业务请求的业务标识包括：所述第一业务节点根据所述业务请求的内容生成所述运算标识；

所述第二业务节点获取所述业务标识包括：所述第二业务节点根据所述业务请求的内容生成所述运算标识。

4.根据权利要求1至3任一权利要求所述的方法，其特征在于，

所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一日常事件、发生所述第一日常事件的日期以及发生所述第一日常事件的时间戳信息，或者，

所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一故障事件、发生所述第一故障事件的日期以及发生所述第一故障事件的时间戳信息；

所述第二运行日志包括所述业务标识、执行所述业务请求发生的第二日常事件、发生所述第二日常事件的日期以及发生所述第二日常事件的时间戳信息，或者，

所述第一运行日志包括所述业务标识、执行所述业务请求发生的第二故障事件、发生所述第二故障事件的日期以及发生所述第二故障事件的时间戳信息。

5.一种故障定位方法，其特征在于，包括如下步骤：

日志服务器接收第一业务节点发送的第一运行日志，其中，所述第一运行日志记载了业务标识；

所述日志服务器接收第二业务节点发送的第二运行日志，其中，所述第二运行日志记载了所述业务标识；

在所述第一业务节点接收到调用失败响应的情况下，所述日志服务器接收所述第一业务节点生成对应调用链的调用链日志，所述调用链包括对应所述第一业务节点与所述第二业务节点的调用链节点，所述调用链日志用于记载调用链信息以及事件信息，所述调用链信息包括调用链标识，每一个所述调用链具有唯一标识的所述调用链标识，所述日志服务器依据所述调用链信息还原所述第一业务节点与所述第二业务节点的调用关，以及从所述调用链日志获取所述调用链节点对应的所述业务标识，并根据所述业务标识查询所述第一运行日志和所述第二运行日志，以进行故障定位。

6.根据权利要求5所述的方法，其特征在于，所述业务标识为调用链标识或者运算标识。

7.根据权利要求5或6所述的方法，其特征在于，

所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一日常事件、发生所述第一日常事件的日期以及发生所述第一日常事件的时间戳信息；或者，

所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一故障事件、发生所述第一故障事件的日期以及发生所述第一故障事件的时间戳信息；

所述第二运行日志包括所述业务标识、执行所述业务请求发生的第二日常事件、发生所述第二日常事件的日期以及发生所述第二日常事件的时间戳信息；或者，

所述第二运行日志包括所述业务标识、执行所述业务请求发生的第二故障事件、发生所述第二故障事件的日期以及发生所述第二故障事件的时间戳信息。

8.一种故障定位系统，其特征在于，包括第一业务节点、第二业务节点以及日志服务器，其中，所述日志服务器分别连接所述第一业务节点以及所述第二业务节点，其中，

所述第一业务节点用于接收业务请求，并获取所述业务请求的业务标识；

所述第一业务节点用于根据所述业务标识生成第一运行日志，其中，所述第一运行日志记载了所述业务标识；

所述第一业务节点用于向日志服务器发送所述第一运行日志；

所述第一业务节点将所述业务请求发送至第二业务节点；

所述第二业务节点用于获取所述业务标识；

所述第二业务节点用于根据所述业务标识生成第二运行日志，其中，所述第二运行日志记载了所述业务标识；

第二业务节点用于向所述日志服务器发送所述第二运行日志；

在所述第一业务节点接收到调用失败响应的情况下，所述第一业务节点生成对应调用链的调用链日志并发送给所述日志服务器，所述调用链包括对应所述第一业务节点与所述第二业务节点的调用链节点，所述调用链日志用于记载调用链信息以及事件信息，所述调用链信息包括调用链标识，每一个所述调用链具有唯一标识的所述调用链标识，所述日志服务器用于依据所述调用链信息还原所述第一业务节点与所述第二业务节点的调用关系，以及从所述调用链日志获取所述调用链节点对应的所述业务标识，并根据所述业务标识查询所述第一运行日志和所述第二运行日志，以进行故障定位。

9.根据权利要求8所述的系统，其特征在于，

所述第一业务节点用于为所述业务请求生成所述调用链标识，将所述调用链标识携带在所述业务请求中；

所述第二业务节点用于接收业务请求，获取所述业务请求中携带的所述调用链标识。

10.根据权利要求8所述的系统，其特征在于，所述业务标识为运算标识，

所述第一业务节点用于获取所述业务请求的业务标识包括：所述第一业务节点根据所述业务请求的内容生成所述运算标识；

所述第二业务节点用于获取所述业务标识包括：所述第二业务节点根据所述业务请求的内容生成所述运算标识。

11.根据权利要求8至10任一权利要求所述的系统，其特征在于，

所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一日常事件、发生所述第一日常事件的日期以及发生所述第一日常事件的时间戳信息；或者，

所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一故障事件、发生所述第一故障事件的日期以及发生所述第一故障事件的时间戳信息；

所述第二运行日志包括所述业务标识、执行所述业务请求发生的第二日常事件、发生所述第二日常事件的日期以及发生所述第二日常事件的时间戳信息；或者

所述第二运行日志包括所述业务标识、执行所述业务请求发生的第二故障事件、发生所述第二故障事件的日期以及发生所述第二故障事件的时间戳信息。

12.一种日志服务器，其特征在于，包括接收模块、故障定位模块以及发送模块，

所述接收模块用于接收第一业务节点发送的第一运行日志，其中，所述第一运行日志记载了业务标识；

所述接收模块用于接收第二业务节点发送的第二运行日志，其中，所述第二运行日志记载了所述业务标识；

在所述第一业务节点接收到调用失败响应的情况下，所述日志服务器接收所述第一业务节点生成对应调用链的调用链日志，所述调用链包括对应所述第一业务节点与所述第二业务节点的调用链节点，所述调用链日志用于记载调用链信息以及事件信息，所述调用链信息包括调用链标识，每一个所述调用链具有唯一标识的所述调用链标识，所述故障定位模块用于依据所述调用链信息还原所述第一业务节点与所述第二业务节点的调用关，以及从所述调用链日志获取所述调用链节点对应的所述业务标识，并根据所述业务标识查询所述第一运行日志和所述第二运行日志，以进行故障定位。

13.根据权利要求12所述的服务器，其特征在于，所述业务标识为调用链标识或者运算标识。

14.根据权利要求12或者13所述的服务器，其特征在于，

所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一日常事件、发生所述第一日常事件的日期以及发生所述第一日常事件的时间戳信息；或者，

所述第一运行日志包括所述业务标识、执行所述业务请求发生的第一故障事件、发生所述第一故障事件的日期以及发生所述第一故障事件的时间戳信息；

所述第二运行日志包括所述业务标识、执行所述业务请求发生的第二日常事件、发生所述第二日常事件的日期以及发生所述第二日常事件的时间戳信息；或者，

所述第二运行日志包括所述业务标识、执行所述业务请求发生的第二故障事件、发生所述第二故障事件的日期以及发生所述第二故障事件的时间戳信息。

15.一种日志服务器，其特征在于，包括处理器和存储器，所述处理器用于执行所述存储器中的代码，执行如权利要求5-7任一项所述的方法。

Images