确定调用链路的方法、装置及电子设备

技术领域

本申请涉及计算机技术领域，具体涉及一种确定调用链路的方法、装置及电子设备。

背景技术

目前，随着应用端和调用请求的数量不断增加，各个应用端之间的调用过程随着调用请求的数量的增加变得越来越复杂。即使对于一条调用请求，在各个应用端之间的调用过程也变得越来越复杂。因此，当出现异常请求时，无法快速确定在调用过程中是哪个调用环节出现了异常，进而无法提高排除故障的工作效率，从而增加了额外的时间成本。

发明内容

有鉴于此，本申请实施例提供了一种确定调用链路的方法、装置及电子设备，能够快速确定调用过程中的异常调用节点。

第一方面，本申请的实施例提供了一种确定调用链路的方法，应用于日志处理装置，该方法包括：获取包含调用请求的标识的查询请求，查询请求用于查询调用请求的日志信息，调用请求包括至少两个调用节点；根据调用请求的标识从数据库获取调用请求的至少两个调用节点的日志信息，其中，每个调用节点的日志信息包括调用请求的标识、调用节点的标识和目标调用节点的标识，目标调用节点的标识为调用该调用节点的上游调用节点；根据每个调用节点的标识和每个目标调用节点的标识，确定调用请求的日志调用链路，其中日志调用链路包括至少两个日志节点，日志节点与调用节点一一对应。

第二方面，本申请的实施例提供了一种确定调用链路的方法，应用于调用节点，包括：针对调用请求生成调用节点的日志信息，日志信息包括调用请求的标识、调用节点的标识和目标调用节点的标识，目标调用节点为调用调用节点的上游调用节点；将日志信息存储至数据库，以便日志处理装置根据调用请求的标识从数据库获取调用请求的至少两个调用节点的日志信息，并根据每个调用节点的标识和每个目标调用节点的标识，确定调用请求的日志调用链路，其中，日志调用链路包括至少两个日志节点，日志节点与调用节点一一对应。

第三方面，本申请的实施例提供了一种确定调用链路的装置，该装置包括：第一获取模块，用于获取包含调用请求的标识的查询请求，查询请求用于查询调用请求的日志信息，调用请求包括至少两个调用节点；第二获取模块，用于根据调用请求的标识从数据库获取调用请求的至少两个调用节点的日志信息，其中，每个调用节点的日志信息包括调用请求的标识、调用节点的标识和目标调用节点的标识，目标调用节点为调用该调用节点的上游调用节点；确定模块，用于根据每个调用节点的标识和每个目标调用节点的标识，确定调用请求的日志调用链路，其中日志调用链路包括至少两个日志节点，日志节点与调用节点一一对应。

第四方面，本申请的实施例提供了一种确定调用链路的装置，包括：生成模块，用于针对调用请求生成调用节点的日志信息，日志信息包括调用请求的标识、调用节点的标识和目标调用节点的标识，目标调用节点为调用调用节点的上游调用节点；存储模块，用于将日志信息存储至数据库，以便日志处理装置根据调用请求的标识从数据库获取调用请求的至少两个调用节点的日志信息，并根据每个调用节点的标识和每个目标调用节点的标识，确定调用请求的日志调用链路，其中，日志调用链路包括至少两个日志节点，日志节点与调用节点一一对应。

第五方面，本申请实施例提供了一种电子设备，其特征在于，电子设备包括：一个或多个处理器；存储器，用于存储一个或多个程序，其中，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器实现上述的方法。

第六方面，本申请实施例提供了一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器实现上述的方法。

根据本申请的实施例，通过根据调用请求的标识从数据库获取调用请求对应的至少两个调用节点的日志信息，并根据每个日志信息中的调用节点的标识以及位于上游的目标调用节点的标识，确定日志调用链路，从而使得本申请实施例能够根据日志信息中记录的标识信息，快速确定日志调用链路中位于上游的调用节点，提高了生成调用链路的效率，并且还能够根据各个调用节点的日志信息快速定位异常调用节点，进而及时对存在异常的调用节点进行故障排除。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是本申请一示例性实施例提供的确定调用链路的系统的示意性架构图。

图2是本申请一示例性实施例提供的基于ELK日志分析平台的系统的示意性架构图。

图3是本申请一示例性实施例提供的确定调用链路的方法的示意性流程图。

图4是本申请另一示例性实施例提供的确定调用链路的方法的示意性流程图。

图5是本申请一示例性实施例提供的各个日志节点的结构图。

图6是本申请又一示例性实施例提供的确定调用链路的方法的示意性流程图。

图7是本申请一示例性实施例提供的确定调用链路的装置的结构示意图。

图8是本申请再一示例性实施例提供的确定调用链路的装置的结构示意图。

图9是本申请一示例性实施例提供的电子设备的示意性框图。

具体实施方式

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

目前，日志分析平台一般通过将不同应用端的日志信息分别收集到服务器，然后通过检索工具利用索引对日志信息进行检索和分析。其中，不同索引对应不同的日志信息，各个日志信息之间相互独立。当通过检索工具进行检索和分析时，各个日志信息可能分布在不同的索引下，导致检索到的日志信息无法快速关联，从而无法快速了解整个调用链路的调用信息，严重降低了工作效率。

针对上述问题，本申请实施例提供了一种确定调用链路的方法、装置及电子设备，下面将参考附图来具体介绍本申请的各种非限制性实施例。

图1是本申请一示例性实施例提供的确定调用链路的系统的示意性架构图。该系统可以包括服务器120、应用端130及日志处理装置140。

具体地，服务器120用于对来自客户端的调用请求110进行负载均衡，并在接收到调用请求110后根据调用请求110生成调用请求110的标识。服务器120可以将调用请求110的标识和服务器120的标识携带在调用请求110中发送给应用端130。服务器120还可以生成包含调用请求的标识和服务器120的标识的日志信息，该日志信息可以包含调用该服务器的上游节点的标识。应用端130可以包括多个应用端，例如，应用端1、应用端2及应用端3，即应用端1、应用端2或应用端3均能够接收调用请求110并生成与之对应的日志信息。可选地，应用端130之间也可以互相调用，例如，应用端1可以向应用端2发送调用请求以调用应用端2，应用端2可以向应用端3发送调用请求以调用应用端3，……，从而形成针对该调用请求的日志调用链路，每个应用端可以生成针对该调用请求的标识，并将应用端的标识和调用请求的标识携带在调用请求中发送给下游的应用端。每个应用端还可以在调用过程中生成日志信息，该日志信息中可以包括该调用请求的标识、该应用端的标识以及调用应用端的上游应用端的标识，并将生成的日志信息发送至日志处理装置140。

日志处理装置140接收每个应用端发送的在调用过程中生成的日志信息，而后将该日志信息进行存储，以便于根据查询请求中携带的调用请求的标识，获取每个调用节点的日志信息，并根据每个日志信息中包含的调用请求的标识等信息，确定日志调用链路，从而快速确定调用过程中的异常调用节点。

调用请求110例如可以是超文本传输协议(Hyper Text Transfer Protocol,HTTP)请求，例如，上述调用请求的标识和服务器的标识可以添加在HTTP请求的头(header)中。

图2是本申请一示例性实施例提供的基于ELK日志分析平台的系统的示意性架构图。

如图2所示，服务器210可以是Nginx服务器。该Nginx服务器可以针对每一条调用请求生成一个标识，并将携带该调用请求的标识以及Nginx服务器的标识的调用请求发送至应用端1221，另外，Nginx服务器还可以生成日志信息，该日志信息除了包含该调用请求的标识以及Nginx的标识外，还可以包含调用Nginx的目标调用节点(也称“上游调用节点”)的标识，应理解的是，由于Nginx为调用链路的起点或根节点，因此，该目标调用节点的标识可以为空或预设值。

应用端1221接收到上述的调用请求之后，可以生成应用端1221的针对该请求的标识，并将应用端1221的标识携带在调用请求中发送给应用端2222。应用端1221还会生成日志信息，其中日志信息中包括调用请求的标识、Nginx的标识以及应用端1221的标识，并将日志信息发送至ELK系统。应用端2222在接收到应用端1221发送的调用请求后，可以生成应用端2222针对该调用请求的标识，并将该应用端2222的标识、该调用请求的标识以及调用应用端2222的上游应用端(即应用端1)的标识包含在日志信息中发送给ELK系统，同时应用端2222可以在发送给应用端3223的调用请求中携带该调用请求的标识以及应用端2222的标识。另外，由于Nginx服务器内存占用少，启动极快，高并发能力强，如此可以高效地同时处理多条调用请求。

日志处理装置230用于在接收到用户的查询请求时，根据查询请求中携带的调用请求的标识从ELK系统240中获取每个调用节点的日志信息，并根据日志信息中包含的调用请求的标识、应用端的标识以及调用该应用端的上游应用端的标识确定调用链路(也称“日志调用链路”)，以判断多个应用端对应的日志节点是否存在异常。

如图2所示，ELK系统240可以包括搜索服务器(Elasticsearch)242、处理端(Logstash)241、显示端(Kibana)243。其中，搜索服务器242用于将接收到的日志信息存储在搜索服务器242的数据库中。处理端241用于对存储在搜索服务器的数据库中的日志信息进行过滤等处理。显示端243用于显示搜索服务器中存储的多个日志信息及显示处理端241的判断结果。应理解的是，日志处理装置230可以作为一个独立的物理设备与搜索服务器242连接，用于以调用链路的形式显示搜索服务器中存储的日志信息以及调用信息。

在本申请的一实施例中，日志处理装置230也可以设置在显示端243上，即由显示端243以日志调用链路的形式显示搜索服务器中存储的日志信息以及调用信息。该调用信息为用于表示调用请求的状态的信息，例如可以是调用时间或调用请求的状态码。

需要说明的是，在Elasticsearch搜索服务器中，需要配置Elasticsearch集群地址，Elasticsearch集群地址可以为一个或多个。其中，每个Elasticsearch集群地址可以对应于多个索引，而一个索引则对应于多条日志信息。当对存储在Elasticsearch搜索服务器的数据库中的日志信息进行处理时，可以通过一个索引将从数据库中读取该索引对应的所有日志信息以对其进行处理。

图3是本申请一示例性实施例提供的确定调用链路的方法的示意性流程图。该方法可以由图1的日志处理装置执行。该方法可以包括如下步骤：

步骤S310：获取包含调用请求的标识的查询请求，查询请求用于查询调用请求的日志信息，调用请求包括至少两个调用节点。

具体地，日志处理装置在接收到用户发送的查询请求时，可以根据查询请求中携带的调用请求的标识从数据库中，获取该调用请求对应的每个调用节点的日志信息。每个调用请求的日志信息为调用节点针对调用请求产生的信息。一个调用请求可以对应至少两个调用节点，即一个调用请求可以对应至少两条日志信息。

步骤S320：根据调用请求的标识从数据库获取调用请求的至少两个调用节点的日志信息。

在一实施例中，每个调用节点的日志信息包括调用请求的标识、调用节点的标识和目标调用节点的标识，该目标调用节点的标识为调用该调用节点的上游调用节点。

具体地，调用请求与该调用请求的标识一一对应，即针对每一个调用请求，存在唯一的标识。一个调用请求的标识可以对应于至少两条日志信息，每个日志信息用于表示通过该调用请求调用该调用节点时所产生的信息，该信息可以包括每个调用节点针对该调用请求所产生的标识，也称为该调用节点的标识，该信息还可以包括调用该调用节点的上游调用节点针对该调用请求所产生的标识，也称为目标调用节点的标识，用于表示哪个上游调用节点通过该调用请求调用了该调用节点。

在本申请某些实施例中，调用节点可以为日志调用链路的第一调用节点，并且该第一调用节点可以为用于负载均衡的服务器，该服务器用于生成调用请求的标识。例如，该服务器可以为Nginx服务器。数据库可以为日志处理装置的数据库或ELK系统。应理解的是，当调用节点为第一调用节点时，由于第一调用节点为日志调用链路的起点，其并没有目标调用节点，因此，对于第一调用节点而言，其日志信息中记录的目标调用节点的标识可以设置为空或预设值，以便在确定日志调用链路时，根据该标识为空或预设值将其识别为调用链路的第一调用节点。并且在第一调用节点调用的调用节点的日志信息中，获取的该第一调用节点的标识，会被记录为目标调用节点的标识。

在本申请某些实施例中，调用节点可以为日志调用链路上除第一调用节点之外其他调用节点，即第二调用节点，该第二调用节点为与服务器连接的应用端。一个应用端的上游调用节点可以为另一应用端，也可以为服务器。

具体地，当该应用端从目标调用节点接收到调用请求时，可以从该调用请求中提取该目标调用节点的标识，并针对该调用请求生成该应用端的标识，然后将该应用端的标识携带在调用请求中发送给下游应用端。同时该应用端可以在所产生的日志信息中记录该调用请求的标识、该应用端的标识以及该目标调用节点的标识，并将该日志信息发送给日志处理装置或与日志处理装置连接的日志分析平台或系统。日志处理装置可以为图1或图2中的日志处理装置，在此不再赘述。

当日志处理装置接收到用户发送的用于查询该调用请求的查询请求时，可以从该查询请求中获取该调用请求的标识，并根据该调用请求的标识从日志处理装置的数据库中获取调用请求的至少两个调用节点的日志信息。如此，通过获取该调用请求的标识，就能够快速确定与该调用请求对应的所有日志信息，进而提高了日志信息的获取速度。

步骤S330：根据每个调用节点的标识和每个目标调用节点的标识，确定调用请求的日志调用链路。

在一实施例中，日志调用链路包括至少两个日志节点，日志节点与调用节点一一对应。

在一实施例中，根据每个调用节点的标识和每个目标调用节点的标识，确定调用请求的日志调用链路，包括：根据每个调用节点的标识和每个目标调用节点的标识，确定至少两个调用节点之间的调用关系；根据调用关系将至少两个日志节点进行关联，以生成日志调用链路。

具体地，日志处理装置可以根据每个调用节点的标识和其对应的目标调用节点的标识，确定至少两个日志节点的调用关系，并根据调用关系将至少两个日志节点进行关联，以生成日志调用链路。也就是说，在根据调用请求的标识，获取到与该调用请求对应的所有日志信息后，可以从每条日志信息中，获取每条日志信息包括的调用节点的标识和目标调用节点的标识，从而确定该目标调用节点与该调用节点为调用和被调用的关系。

例如，日志处理装置可以分别将上述的每个调用节点通过该调用请求进行调用所产生的日志信息作为多个日志节点(或至少两个日志节点)，其中日志节点与调用节点是一一对应的关系。一个调用节点可以通过该调用请求调用一个或至少两个调用节点，例如，调用节点1可以通过该调用请求，调用下游的调用节点2，而调用节点2可以通过该调用请求调用下游的调用节点3和调用节点4。相应地，在日志调用链路上，日志节点之间关系可以包括串联连接关系和/或并联连接关系，例如，调用节点1对应的日志节点1与调用节点2对应的日志节点2串联连接，而调用节点3对应的日志节点3与调用节点4对应的日志节点4并联连接并同时与日志节点2串联连接。

通过分析该条日志调用链路上的各个调用节点的日志信息，就可以确定该条日志调用链路上是否存在异常的调用节点。

需要说明的是，一个调用请求可以对应一条日志调用链路。根据每个日志信息将每个调用节点进行关联可以得到该日志调用链路，日志调用链路可以包括每个调用节点对应的调用信息，从而能够根据每个调用节点对应的调用信息，判断每个调用节点是否存在异常。如此，通过每个调用请求对应的日志信息，将每个调用节点进行关联以得到日志调用链路，能够快速了解日志调用链路上各个调用节点的调用信息，进而根据各个调用节点的调用信息快速提高定位异常调用节点的速度，以便于及时对存在异常的调用节点进行故障排除，进而降低时间成本。

应理解的是，调用节点1发送给调用节点2的调用请求与调用节点2发送给调用节点3和调用4的调用请求携带的调用请求的标识相同，但携带的调用节点的标识不同。

还应理解的是，当存在多个调用请求时，利用上述步骤可以分别确定针对多个调用请求的多条日志调用链路，以便于对多条日志调用链路进行分析和故障定位，从而在多条日志调用链路中确定存在异常的调用节点。

根据本申请的实施例，通过根据调用请求的标识从数据库获取调用请求对应的至少两个调用节点的日志信息，并根据每个日志信息中的调用节点的标识以及位于上游的目标调用节点的标识，确定日志调用链路，从而使得本申请实施例能够根据日志信息中记录的标识信息，快速确定日志调用链路中位于上游的调用节点，提高了生成调用链路的效率，并且还能够根据各个调用节点的日志信息快速定位异常调用节点，进而及时对存在异常的调用节点进行故障排除。

可选地，作为另一实施例，图3的方法还包括：在获取包含调用请求的标识的查询请求之前，获取调用请求对应的每个调用节点的日志信息，日志信息是调用节点被调用请求调用时生成的。

具体地，服务器接收到调用请求后可以根据调用请求，将该调用请求发送至至少一个调用节点(即应用端)。进而日志处理装置可以接收每个调用节点发送的日志信息，并将获取的每个调用节点的日志信息进行存储。

在一实施例中，针对某一特定的索引，在数据库中配置该调用请求的标识、调用节点的标识和目标调用节点的标识之间的映射关系，并根据该映射关系将该调用请求的所有日志信息存储于该索引中。这样，可以在接收用户的查询请求时，先根据查询请求中的调用请求的标识确定索引，再根据索引确定所有的日志信息。

根据本申请的实施例，通过根据调用请求的标识、调用节点的标识和目标调用节点的标识之间的映射关系，将日志信息存储于特定的索引下，有助于根据调用请求的标识快速搜索到该调用请求的所有日志信息，从而有利于加快确定日志调用链路的进程。

可选地，作为另一实施例，图3的方法还包括：显示日志调用链路，其中通过日志节点链接与日志节点对应的调用节点的日志信息。

具体地，上述的日志调用链路的数量可以为一条或多条，在确定日志调用链路之后，可以根据日志调用链路生成链路追踪图。在链路追踪图上，可以随意查看各个调用节点的日志信息，也可以将各个调用节点的调用关系展示出来。通过分析每个调用节点对应的调用信息，可以快速在一条调用链路上是否存在异常的调用节点，从而能够快速定位异常的调用节点，以便于排除故障，从而保证调用请求的顺利进行。

可选地，作为另一实施例，调用节点的日志信息还以包括该调用节点的调用时间，图3的方法还包括：显示调用时间差，以确定调用节点对应的日志节点是否出现异常，其中调用时间差是基于调用节点的调用时间和目标调用节点的调用时间确定的。

在本申请的一种实施例中，可以根据每个调用节点对应的调用时间差，判断调用请求是否存在异常，具体可以包括如下步骤：

步骤S410：根据每个调用节点对应的日志信息确定该调用节点的调用时间。

步骤S420：根据每个调用节点的调用时间确定该调用节点与目标调用节点的调用时间差。

步骤S430：判断调用时间差是否超过预设时间。其中，若调用时间差超过预设时间，则执行步骤S440；若调用时间差未超过预设时间，则执行步骤S450。

步骤S440：调用节点出现异常。

步骤S450：调用节点未出现异常。

具体地，调用时间差指的是一个调用节点在执行调用请求时到下一个调用节点在执行调用请求时所消耗的时间。上述的调用节点之间的时间差也可以指一个日志信息到下一个日志信息之间所记录的时间之差。

举例而言，如图5所示，参见图5，日志节点1对应的日志信息包括：调用该调用节点1的目标调用节点的标识：parent_spin_id＝null；调用节点1的标识：spin＝a，请求的标识：request_id＝x，调用时间：create_time1。日志节点2对应的日志信息包括：调用该调用节点2的目标调用节点的标识：parent_spin_id＝a；调用节点2的标识：spin＝b，请求的标识：request_id＝x，调用时间：create_time2；日志节点3对应的日志信息包括：调用该调用节点3的目标调用节点的标识：parent_spin_id＝b；调用节点3的标识：spin＝c，请求的标识：request_id＝x，调用时间：create_time3；日志节点4对应的日志信息包括：调用该调用节点4的目标调用节点的标识：parent_spin_id＝b；调用节点4的标识：spin＝d，请求的标识：request_id＝x，调用时间：create_time4。

日志节点1对应的应用端1在执行调用请求时记录了日志信息A，并将记录日志信息A的时刻定义为第一时刻(create_time1)；当调用请求传递至日志节点2对应的应用端2时，应用端2在执行该调用请求时记录了日志信息B，并将记录日志信息B的时刻定义为第二时刻(create_time2)；因此，应用端1与应用端2在执行调用请求时的时间差为第二时刻减去第一时刻，即应用端1在执行调用请求时所消耗的时间。

类似地，日志节点3对应的应用端3在执行调用请求时记录了日志信息C，并将记录日志信息C的时刻定义为第三时刻(create_time3)；当调用请求传递至日志节点4对应的应用端4时，应用端4在执行该调用请求时记录了日志信息D，并将记录日志信息D的时刻定义为第四时刻(create_time4)；因此，应用端3与应用端4在执行调用请求时的时间差为第四时刻减去第三时刻，即应用端3在执行调用请求时所消耗的时间。

根据本申请的实施例，通过每个调用节点对应的日志信息确定调用节点之间的调用时间差并判断调用时间差是否超过预设时间来确定调用节点是否存在异常。若调用时间超过预设时间，则确定调用节点出现异常，即该调用节点的调用请求出现了异常。如此能够提高定位异常调用节点的速度，从而提高排除故障的速度。

应理解的是，上述的预设时间可以根据不同的应用端的业务需求进行相应的调整。本申请中对此不做特殊的限定，本领域技术人员能够根据不同的业务需求定义与之相匹配的预设时间，都应落入本申请的技术构思中。例如，在执行支付等实时性较强的业务时，需要各应用端快速响应并执行调用请求，此时若预设时间超过2秒，则可以判定该应用端出现异常。又例如，在执行查询等实时性较弱的业务时，若预设时间超过4秒，则可以判定该应用端出现异常。

可选地，作为另一实施例，调用节点的日志信息还以包括该调用节点针对该调用请求的状态码，图3的方法还包括：显示状态码，以确定调用节点对应的日志节点是否存在异常。

具体地，根据每个调用节点对应的状态码，判断每个调用节点是否存在异常。状态码可以有多个，且每个状态码可以具有不同的含义。而不同含义的状态码能够反映出各个调用节点是否存在异常。举例而言，状态码可以包括三个十进制数字，第一个十进制数字用于表示状态码的类型。而状态码的类型可以包括请求响应、请求成功、请求重定向和请求错误等。

在某些实施例中，日志处理装置可以根据每个调用节点对应的状态码的类型判断每个调用请求是否存在异常。例如，可以获取每个状态码的类型，根据每个状态码的类型按预设状态码分析表判断每个状态码的含义，并根据每个状态码的含义判断每个调用节点是否存在异常。

本申请中判断每个调用请求是否存在异常的方法中，每个状态码的类型是不同的，而不同类型的状态码所代表的含义也是不同的。因此，可以通过每个状态码的含义快速判断每个调用节点是否存在异常，进而可以判断调用请求是否存在异常。

举例而言，当状态码的类型为请求响应时，状态码的三个十进制数字的范围可以为100–199。当状态码的类型为请求成功时，状态码的三个十进制数字的范围可以为200-299。当状态码的类型为请求重定向时，状态码的三个十进制数字的范围可以为300-399。当状态码的类型为请求错误时，状态码的三个十进制数字的范围可以为400-599。即：利用上述不同的状态码类型就可以判断每个调用节点的请求是否被正常调用，进而可以快速判断每个调用节点是否存在异常。

需要说明的是，状态码的三个十进制数字可以代表不同的含义。如此，在通过判断状态码的类型确定每个调用是否是请求响应、请求成功、请求重定向和请求错误中的一种情况之后，还可以通过上述的三个十进制数字进一步详细了解各个调用节点的调用信息。举例而言，202用于表示已接受调用请求，但未处理完成；413用于表示由于请求量过大，服务器无法处理并拒绝请求；500用于表示服务器内部错误，无法完成调用请求。

在本申请一实施例中，日志调用链路可以包括第一日志节点和第二日志节点，第一日志节点对应的调用节点为用于负载均衡的服务器，服务器用于生成调用请求的标识，第二日志节点对应的调用节点为与服务器连接的应用端，其中第二日志节点为日志调用链路对应的日志节点中除第一日志节点之外的其它日志节点。

图6是本申请又一示例性实施例提供的确定调用链路的方法的示意性流程图。该方法可以由图1的服务器或应用端执行。该方法可以包括如下步骤：

610，针对调用请求生成调用节点的日志信息，日志信息包括调用请求的标识、调用节点的标识和目标调用节点的标识，目标调用节点为调用该调用节点的上游调用节点。

620，将日志信息存储至数据库，以便日志处理装置根据调用请求的标识从数据库获取调用请求的至少两个调用节点的日志信息，并根据每个调用节点的标识和每个目标调用节点的标识，确定调用请求的日志调用链路，其中，日志调用链路包括至少两个日志节点，日志节点与调用节点一一对应。

具体地，每个调用节点在接收到上游调用节点(或目标调用节点)发送的调用请求时可以生成日志文件，日志文件用于记录调用节点执行调用请求时产生的日志信息，包括调用请求的标识、调用节点的标识以及目标调用节点的标识。调用节点可以将每个日志文件存入日志处理装置的预设数据库，日志处理装置在接收到用户的查询请求时，在预设数据库中获取与调用请求的标识对应的所有日志文件，并读取与日志文件中的日志信息，最后根据日志信息中读取的每个调用节点的标识和其对应的目标调用节点的标识，确定调用请求的日志调用链路。其中日志处理装置确定日志调用链路的方法与图3的方法相同，在此不再赘述。

应理解的是，当调用节点为服务器时，服务器的日志信息中的目标调用节点的标识为空或为预设值，以便在确定日志调用链路时根据标识为空或预设值将其识别为日志调用链路的起始节点。

在一实施例中，调用节点包括第一调用节点和第二调用节点，第一调用节点为用于负载均衡的服务器，服务器用于生成调用请求的标识，第二调用节点为与服务器连接的应用端，其中第二调用节点为调用请求对应的调用节点中除第一调用节点之外的其它调用节点。

根据本申请的实施例，通过针对调用请求生成调用节点的日志信息，在日志信息包含调用请求的标识、调用节点的标识和目标调用节点的标识，并将日志信息存储至数据库，以便日志处理装置根据调用请求的标识，从数据库中获取调用请求的至少两个调用节点的日志信息，并根据每个调用节点的标识和对应的目标调用节点的标识确定调用请求的日志调用链路，从而能够提高生成调用链路的效率，使得能够根据各个调用节点的日志信息快速定位异常调用节点，进而及时对存在异常的调用节点进行故障排除。

图7是本申请一示例性实施例提供的确定调用链路的装置700的结构示意图。如图7所示，该装置700可以包括第一获取模块710、第二获取模块720和确定模块730。

第一获取模块710用于获取包含调用请求的标识的查询请求，查询请求用于查询调用请求的日志信息，调用请求包括至少两个调用节点；第二获取模块720用于根据调用请求的标识从数据库获取调用请求的至少两个调用节点的日志信息，其中，每个调用节点的日志信息包括调用请求的标识、调用节点的标识和目标调用节点的标识，目标调用节点为调用该调用节点的上游调用节点；确定模块730用于根据每个调用节点的标识和每个目标调用节点的标识，确定调用请求的日志调用链路，其中日志调用链路包括至少两个日志节点，日志节点与调用节点一一对应。

根据本申请的实施例，通过根据调用请求的标识从数据库获取调用请求对应的至少两个调用节点的日志信息，并根据每个日志信息中的调用节点的标识以及位于上游的目标调用节点的标识，确定日志调用链路，从而使得本申请实施例能够根据日志信息中记录的标识信息，快速确定日志调用链路中位于上游的调用节点，提高了生成调用链路的效率，并且还能够根据各个调用节点的日志信息快速定位异常调用节点，进而及时对存在异常的调用节点进行故障排除。

在本申请某些实施例中，确定模块720用于根据每个调用节点的标识和每个目标调用节点的标识，确定至少两个调用节点之间的调用关系；根据调用关系将至少两个日志节点进行关联，以生成日志调用链路。

可选地，作为另一实施例，装置700还包括第三获取模块740用于获取调用请求对应的每个调用节点的日志信息，日志信息是调用节点被调用请求调用时生成的。

可选地，作为另一实施例，装置700还包括：显示模块750用于显示日志调用链路，其中，通过日志节点链接与日志节点对应的调用节点的日志信息。

可选地，作为另一实施例，装置700还包括：显示模块750用于显示调用时间差，以确定调用节点对应的日志节点是否出现异常，其中调用时间差是基于调用节点的调用时间和目标调用节点的调用时间确定的。

可选地，作为另一实施例，装置700还包括：显示模块750，用于显示状态码，以确定日志节点是否存在异常。

在本申请某些实施例中，日志调用链路包括第一日志节点和第二日志节点，第一日志节点对应的调用节点为用于负载均衡的服务器，服务器用于生成调用请求的标识，第二日志节点对应的调用节点为与服务器连接的应用端，其中第二日志节点为日志调用链路对应的日志节点中除第一日志节点之外的其它日志节点。

图8是本申请再一示例性实施例提供的确定调用链路的装置800的结构示意图。装置800包括生成模块810和存储模块820。

生成模块810用于针对调用请求生成调用节点的日志信息，日志信息包括调用请求的标识、调用节点的标识和目标调用节点的标识，目标调用节点为调用该调用节点的上游调用节点。

存储模块820用于将日志信息存储至数据库，以便日志处理装置根据调用请求的标识从数据库获取调用请求的至少两个调用节点的日志信息，并根据每个调用节点的标识和每个目标调用节点的标识，确定调用请求的日志调用链路，其中，日志调用链路包括至少两个日志节点，日志节点与调用节点一一对应。

在本申请的某些实施例中，调用节点包括第一调用节点和第二调用节点，第一调用节点为用于负载均衡的服务器，服务器用于生成调用请求的标识，第二调用节点为与服务器连接的应用端，其中第二调用节点为调用请求对应的调用节点中除第一调用节点之外的其它调用节点。

需要说明的是，本申请提供的一种确定调用链路的装置的实施例具体可以用于执行上述实施例中的确定调用链路的方法的实施例的处理流程，其功能在此不再赘述，可以参照上述方法实施例的详细描述。

图9是本申请一示例性实施例提供的电子设备900的框图。

参照图9，电子设备900包括一个或多个处理器910，以及由存储器920所代表的存储器资源，用于存储可由处理器910的执行的指令，例如应用程序。存储器920中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理器被配置为执行指令，以执行上述确定调用链路的方法。

电子设备900还可以包括一个电源组件被配置为执行电子设备900的电源管理，一个有线或无线网络接口被配置为将电子设备900连接到网络，和一个输入输出(I/O)接口。可以基于存储在存储器920的操作系统操作电子设备900，例如Windows Server

一种非临时性计算机可读存储介质，当存储介质中的指令由上述电子设备900的处理器910执行时，使得上述电子设备900能够执行一种确定调用链路的方法，包括：获取包含调用请求的标识的查询请求，查询请求用于查询调用请求的日志信息，调用请求包括至少两个调用节点；根据调用请求的标识从数据库获取调用请求的至少两个调用节点的日志信息，其中，每个调用节点的日志信息包括调用请求的标识、调用节点的标识和目标调用节点的标识，目标调用节点的标识为调用该调用节点的上游调用节点；根据每个调用节点的标识和每个目标调用节点的标识，确定调用请求的日志调用链路，其中日志调用链路包括至少两个日志节点，日志节点与调用节点一一对应。

上述所有可选技术方案，可采用任意结合形成本申请的可选实施例，在此不再一一赘述。

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

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

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

需要说明的是，在本申请的描述中，术语“第一”、“第二”、“第三”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义是两个或两个以上。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换等，均应包含在本申请的保护范围之内。