CN113934733A - 问题定位方法、装置、系统、存储介质及电子设备 - Google Patents

Abstract

本公开涉及计算机技术领域，具体涉及一种问题定位方法、问题定位装置、问题定位系统、存储介质及电子设备。该问题定位方法包括采集全链路的业务数据以创建业务关键字与业务请求索引之间的第一索引关系，以及所述业务请求索引与业务调用链路信息之间的第二索引关系；响应于目标业务关键字的查询请求，基于所述第一索引关系获取所述目标业务关键字对应的目标业务请求索引；基于所述第二索引关系获取所述目标业务请求索引对应的目标业务调用链路信息，以利用所述目标业务调用链路信息进行业务问题定位。本公开提供的问题定位方法，能够自动化、快速地返回业务调用链路信息以用于全链路业务的问题定位。

Description

问题定位方法、装置、系统、存储介质及电子设备

技术领域

本公开涉及计算机技术领域，具体涉及一种问题定位方法、问题定位装置、问题定位系统、存储介质及电子设备。

背景技术

当今互联网系统中，分布式系统已成为系统设计、部署上线运营的常态，分布式系统可以很好的应对大规模业务并发请求。分布式系统及微服务技术在解耦业务逻辑的同时，也将业务流程分隔打散成一个个孤立的应用节点，每个应用节点只能感知它所调用的直接上游，而对完整的业务流程链条全景一无所知。

当一个系统的链条上出现业务问题时，可能是正常的业务提示，也有可能是业务本身存在的问题，所以要对业务问题进行快速定位。现有技术中，一般只能从报出错误的应用节点逐一向上进行回溯，整个溯源过程费时费力，复杂程度随着业务链条的长度成指数增加，耗时也很冗长。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种问题定位方法、问题定位装置、问题定位系统、存储介质及电子设备，旨在自动化、快速地返回业务调用链路信息以用于全链路业务的问题定位。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开实施例的一方面，提供了一种问题定位方法，包括：采集全链路的业务数据以创建业务关键字与业务请求索引之间的第一索引关系，以及所述业务请求索引与业务调用链路信息之间的第二索引关系；响应于目标业务关键字的查询请求，基于所述第一索引关系获取所述目标业务关键字对应的目标业务请求索引；基于所述第二索引关系获取所述目标业务请求索引对应的目标业务调用链路信息，以利用所述目标业务调用链路信息进行业务问题定位。

根据本公开的一些实施例，基于前述方案，所述采集全链路的业务数据以创建业务关键字与业务请求索引之间的第一索引关系，以及所述业务请求索引与业务调用链路信息之间的第二索引关系，包括：对全链路的业务数据进行全量采集得到全链路的业务日志；基于所述全链路的业务日志创建业务关键字，并确定包括所述业务关键字的业务请求信息；根据所述业务请求信息创建业务请求索引，以及生成业务调用链路信息；创建所述第一索引关系和所述第二索引关系。

根据本公开的一些实施例，基于前述方案，所述对全链路的业务数据进行全量采集得到全链路的业务日志，包括：基于第一线程池执行利用面向切面编程AOP方式获取全链路的业务数据，并对所述业务数据进行初步压缩后写入有界队列；基于第二线程池执行针对所述有界队列中各消息体进行特征值比较，以进行再次压缩得到所述业务日志。

根据本公开的一些实施例，基于前述方案，所述初步压缩包括：基于预设的常用参数值和常量之间的映射关系将所述业务数据中的参数值替换为常量；和/或采用变长编码方法对所述业务数据进行压缩编码。

根据本公开的一些实施例，基于前述方案，在所述基于所述全链路的业务日志创建业务关键字之前，所述方法还包括：对所述业务日志进行数据类型过滤和/或关键字过滤。

根据本公开的一些实施例，基于前述方案，所述基于所述全链路的业务日志创建业务关键字，包括：提取所述业务日志中业务请求的参数；在所述参数满足关键字条件时，将所述参数作为所述业务关键字。

根据本公开的一些实施例，基于前述方案，所述业务请求信息包括至少一个事务的事务信息，所述根据所述业务请求生成业务调用链路信息，包括：为全链路中所述事务分配全局唯一的交易标识；以及根据所述业务请求信息获取所述事务之间的调用关系；基于所述交易标识和所述调用关系生成所述业务调用链路信息。

根据本公开的一些实施例，基于前述方案，在所述目标业务关键字对应多个目标业务请求索引时，所述方法还包括：获取各所述目标业务请求索引的业务请求；根据所述业务请求确定各所述目标业务请求索引之间的上下游关系；基于所述上下游关系将各所述目标业务调用链路信息进行整合得到目标业务全链路信息，以利用所述目标业务全链路信息进行业务问题定位。

根据本公开的一些实施例，基于前述方案，所述方法还包括：利用所述目标业务调用链路信息进行业务问题定位，得到异常事务以及所述异常事务在所述目标业务调用链路信息中的异常位置信息。

根据本公开实施例的第二方面，提供了一种问题定位装置，包括：采集模块，用于采集全链路的业务数据以创建业务关键字与业务请求索引之间的第一索引关系，以及所述业务请求索引与业务调用链路信息之间的第二索引关系；第一查询模块，用于响应于目标业务关键字的查询请求，基于所述第一索引关系获取所述目标业务关键字对应的目标业务请求索引；第二查询模块，用于基于所述第二索引关系获取所述目标业务请求索引对应的目标业务调用链路信息，以利用所述目标业务调用链路信息进行业务问题定位。

根据本公开实施例的第三方面，提供了一种问题定位系统，包括：日志采集器，用于采集全链路的业务数据，并将所述业务数据发送至数据分析器；数据分析器，用于接收所述日志采集器发送的所述业务数据，并创建业务关键字与业务请求索引之间的第一索引关系，以及所述业务请求索引与业务调用链路信息之间的第二索引关系，并将所述第一索引关系、所述第二索引关系和所述业务数据存储至索引数据库中；用户查询界面，用于响应于目标业务关键字的查询请求，将所述查询请求发送至查询分析器，以及显示所述查询分析器返回的目标业务调用链路信息；查询分析器，用于接收所述查询请求，调用所述索引数据库基于所述第一索引关系获取所述目标业务关键字对应的目标业务请求索引，基于所述第二索引关系获取所述目标业务请求索引对应的目标业务调用链路信息，并将所述目标业务调用链路信息返回至所述用户查询界面。

根据本公开的一些实施例，基于前述方案，所述查询分析器还被配置为：利用所述目标业务调用链路信息进行业务问题定位，得到异常事务以及所述异常事务在所述目标业务调用链路信息中的异常位置信息；将所述异常事务和所述异常位置信息返回至所述用户查询界面。

根据本公开的一些实施例，基于前述方案，所述用户查询界面还被配置为：将从所述查询分析器接收到的所述异常事务按照所述异常位置信息进行突出显示。

根据本公开的一些实施例，基于前述方案，所述用户查询界面还被配置为：根据所述目标业务调用链路信息中的事务生成事务查看按钮；基于用户对目标事务查看按钮的操作生成目标事务的查看请求，并将所述查看请求发送至查询分析器；以及显示从所述查询分析器返回的目标事务信息。

根据本公开的一些实施例，基于前述方案，所述查询分析器还被配置为：接收所述用户查询界面发送的所述目标事务的查看请求；调用所述索引数据库提取目标事务信息，并将所述目标事务信息返回至所述用户查询界面。

根据本公开的一些实施例，基于前述方案，所述日志采集器被配置为：使用用户数据报UDP协议将所述业务数据发送至数据分析器。

根据本公开实施例的第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如上述实施例中的问题定位方法。

根据本公开实施例的第五方面，提供了一种电子设备，其特征在于，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中的问题定位方法。

本公开示例性实施例可以具有以下部分或全部有益效果：

在本公开的一些实施例所提供的技术方案中，预先采集全链路的业务数据建立业务关键字与业务请求索引的索引关系，和业务请求索引与业务调用链路信息的索引关系，使得在问题定位查询时，能够根据目标业务关键字以及预先创建的索引关系，获取到目标业务关键字对应的目标业务请求索引，进而得到目标业务调用链路信息，以提供问题定位分析的信息基础。基于本公开提供的方法，一方面引入业务关键字，并基于全链路的业务数据创建业务关键字的索引方式，能够打通全链路各分布式系统的上下游应用之间的业务流程关联，进而基于业务关键字的查询自动快速地获取全链路中包括业务关键字的所有业务调用链路信息；另一方面，通过建立第一索引关系和第二索引关系，即两级的索引关系，能够将数据分布式存储，进一步加快业务调用链路信息的查询速度。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示意性示出本公开示例性实施例中一种问题定位方法的流程示意图；

图2示意性示出本公开示例性实施例中一种执行第一线程的流程示意图；

图3示意性示出本公开示例性实施例中一种执行第二线程的流程示意图；

图4示意性示出本公开示例性实施例中一种业务调用链路信息追踪过程的示意图；

图5示意性示出本公开示例性实施例中一种索引数据库中数据之间的关系的示意图；

图6示意性示出本公开示例性实施例中一种问题定位装置的组成示意图；

图7示意性示出本公开示例性实施例中一种问题定位系统的数据交互示意图；

图8示意性示出本公开示例性实施例中一种用户查询界面的界面示意图；

图9示意性示出本公开示例性实施例中一种计算机可读存储介质的示意图；

图10示意性示出本公开示例性实施例中一种电子设备的计算机系统的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本公开的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本公开的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

当今互联网系统中，分布式系统已成为系统设计、部署上线运营的常态，分布式系统可以很好的应对大规模业务并发请求。但分布式系统及微服务技术在解耦业务逻辑的同时，也将业务流程分隔打散成一个个孤立的应用节点，每个应用节点只能感知它所调用的直接上游，而对完整的业务流程链条全景一无所知。

一个系统总会存在由于产品设计问题或者研发bug问题而导致存在线上业务问题，这个业务问题有可能是正常的业务提示，也有可能是业务本身存在的问题。

当需要在这个链条中进行问题定位时，一般是通过从报出错误的应用节点(往往是面向用户的最终节点)逐一向上进行回溯，整个溯源过程费时费力，复杂程度随着业务链条的长度成指数增加。例如需要链条上的每个应用都要将下游应用提供的信息进行映射转换，并查询本系统日志，然后判断该数据是由本系统产生的，还是上游传入的如果是本系统产生，则分析具体原因；如果是上游下传，则再联系上游对接人，循环往复这个排查过程。而如果各个应用日志存在日志缺失或隐式传参等情况，还需要研发通过代码反向推演可能数据，问题定位过程更加繁琐，耗时更为冗长。往往排查一个问题，就要涉及整个业务流程不同业务系统的数十个研发工作几个小时，既浪费了大量人力资源，又耗费了宝贵的时间，还可能会给重要业务带来金钱及信誉上的损失。

对于如何快速定位业务，在现有技术中一方面是监控，目前存在的分布式系统监控只能对系统指标、分布式链路、异常等进行系统层面监控，例如阿里的鹰眼、开源的分布式追踪系统(skywalking)等，而针对业务流程本身的问题监控是没有的；另一方面是通过分布式系统中的各个应用内部输出关键日志，进而根据关键日志进行问题定位。

因此，针对现有技术中存在的问题，本公开提供了一种问题定位方法，通过采集所有业务数据，并对数据进行分析建立数据索引，使之通过业务关键字对应的索引信息找到所有业务所有的数据请求，能够自动记录全链路全量的业务日志，并打通分布式系统上下游应用之间的关联，进而实现快速查询和业务问题定位。

以下对本公开实施例的技术方案的实现细节进行详细阐述。

图1示意性示出本公开示例性实施例中一种问题定位方法的流程示意图。如图1所示，该问题定位方法包括步骤S1至步骤S3：

步骤S1，采集全链路的业务数据以创建业务关键字与业务请求索引之间的第一索引关系，以及所述业务请求索引与业务调用链路信息之间的第二索引关系；

步骤S2，响应于目标业务关键字的查询请求，基于所述第一索引关系获取所述目标业务关键字对应的目标业务请求索引；

步骤S3，基于所述第二索引关系获取所述目标业务请求索引对应的目标业务调用链路信息，以利用所述目标业务调用链路信息进行业务问题定位。

在本公开的一些实施例所提供的技术方案中，预先采集全链路的业务数据建立业务关键字与业务请求索引的索引关系，和业务请求索引与业务调用链路信息的索引关系，使得在问题定位查询时，能够根据目标业务关键字以及预先创建的索引关系，获取到目标业务关键字对应的目标业务请求索引，进而得到目标业务调用链路信息，以提供问题定位分析的信息基础。基于本公开提供的方法，一方面引入业务关键字，并基于全链路的业务数据创建业务关键字的索引方式，能够打通全链路各分布式系统的上下游应用之间的业务流程关联，进而基于业务关键字的查询自动快速地获取全链路中包括业务关键字的所有业务调用链路信息；另一方面，通过建立第一索引关系和第二索引关系，即两级的索引关系，能够将数据分布式存储，进一步加快业务调用链路信息的查询速度。

下面，将结合附图及实施例对本示例实施方式中的问题定位方法的各个步骤进行更详细的说明。

在步骤S1中，采集全链路的业务数据以创建业务关键字与业务请求索引之间的第一索引关系，以及所述业务请求索引与业务调用链路信息之间的第二索引关系。

其中，全链路是指由一个业务系统中所有分布式系统中的所有环节，而业务数据是在该业务系统下各环节的业务请求信息，包括参数、方法名、返回值等等数据。

在本公开的一个实施例中，所述所述采集全链路的业务数据以创建业务关键字与业务请求索引之间的第一索引关系，以及所述业务请求索引与业务调用链路信息之间的第二索引关系，包括：

步骤S11，对全链路的业务数据进行全量采集得到全链路的业务日志；

步骤S12，基于所述全链路的业务日志创建业务关键字，并确定包括所述业务关键字的业务请求信息；

步骤S13，根据所述业务请求信息创建业务请求索引，以及生成业务调用链路信息；

步骤S14，创建所述第一索引关系和所述第二索引关系。

进一步地，在步骤S11中，所述对全链路的业务数据进行全量采集得到全链路的业务日志，包括：

步骤S111，基于第一线程池执行利用面向切面编程AOP方式获取全链路中所有业务的业务数据，并对所述业务数据进行初步压缩后写入有界队列；

步骤S112，基于第二线程池执行针对所述有界队列中各消息体进行特征值比较，以进行再次压缩得到所述业务日志。

其中，对应步骤S111，第一线程池可以是消费线程(Consumer Thread)，用来获取全链路中所有业务的业务数据，并将采集的数据进行初步压缩写入有界队列。

日志采集器通过AOP原理对系统中所有的方法进行代理，记录其使用时的参数、方法名、返回值、异常等信息作为业务数据。其中，AOP(Aspect-Oriented Programming，面向切面编程)使用“横切”技术，把软件系统分为两个部分：核心业务逻辑组件和横切关注点。横切关注点模块化为特殊的类，这些类被称为“切面”，关注点都集中于一块，不会出现大量重复代码，同时核心模块只关注核心功能的代码，模块间藕合度降低。

由于全链路的数据信息量非常大，所以如何快速的不丢信息的记录业务数据是关键之处，因此需要对业务数据进行初步压缩。

进一步地，在对所述业务数据进行初步压缩时，所述初步压缩包括：基于预设的常用参数值和常量之间的映射关系将所述业务数据中的参数值替换为常量；和/或采用变长编码方法对所述业务数据进行压缩编码。

具体来说，采集大量的数据会增大磁盘和网络的消耗，而像方法名，SQL，类名等信息每调用一次就会收集一次，重复性很高，所以我们用一个ID替换"method A"，再用一个常量表保存ID和"method A"的信息，这样会大大的减少数据的大小。因此，首先预设一些常用参数值和常量之间的映射关系构建常量表，然后将业务数据中存在与常量表中的参数值替换为对应的常量。

而通过使用二进制格式，生成的数据比较小，有利于减少磁盘和网络使用。使用变长编码和格式优化数据记录，如果将一个长整型转换为固定长度的字符串，数据大小一般是8个字节；然而，如果使用变长编码，数据大小可以是从1到10个字符，这取决于给定数字的大小。因此，可以采用变长编码方法对业务数据进行压缩来减少存储空间。

其中，变长编码指非规整型操作码的长度不定，且分散在指令字的不同位置上的编码，广泛用在小型、微型计算机上。这种编码的好处在于，对于小的数值，可以用更少的字节去表示，不过相应的，对于大数就要使用更多的字节去存储。在统计学上，一般消息中的数字以小数为主，所以用它可以省空间。

需要说明的是，在进行初步压缩时，利用常量表和变长编码压缩都可以实现减小数据量的效果，可以根据实际需要选择只使用其中的一种，或采用两种方法均使用的压缩方式，本公开对此不做具体限定。

另外，还可以采用异步刷盘的方式进一步提高消费线程的性能和吞吐量。异步刷盘能够充分利用OS(Operating System，操作系统)的Page Cache(页面缓存)的优势，只要消息写入页面缓存即可将成功的ACK(Acknowledgement，确认字符)返回，异步将内存中的数据持久化到磁盘上。刷盘采用后台异步线程提交的方式进行，降低了读写延迟，提高了Consumer Thread消费线程的性能和吞吐量。

执行消费线程之后，将压缩后的消息体写入一个有界队列中。有界队列能够有效的控制数据数量的大小，不会因为数据过多导致内存激增问题，如果队列满了，则会选择丢掉消息，保证采集器端的稳定。

图2示意性示出本公开示例性实施例中一种执行第一线程的流程示意图。参考图2所示，日志采集器主要设置有界队列(Queue)201和消费线程(Consumer Thread)203。其中，有界队列中包括通过AOP原理记录的业务数据202，随后执行消费线程203对采集的数据进行处理作为消息体写入有界队列。其处理过程可以包括：步骤S201，利用常量表(ConstantTables)将业务数据中的参数值进行常量替换；步骤S202，数据压缩(Compress)，采用变长编码进行压缩；步骤S203，Java堆分析(Java Heap)，这是减少内存使用时一个重要目标，在堆分析上最简单的方法是利用堆直方图，通过堆直方图我们可以快速看到应用内的对象数目，同时不需要进行完整的堆转储；步骤S204，设置虚拟内存(Virtual Memory)，虚拟内存用于操作系统对主存的管理，主要强调的是如何合理利用主存空闲区的问题，之后，提出了一系列增加利用率的策略；步骤S205，异步多线程刷新磁盘，数据写入内存后，直接响应client，异步将内存中的数据持久化到磁盘上。

在步骤S112中，基于第二线程池执行针对所述有界队列中各消息体进行特征值比较，以进行再次压缩得到所述业务日志。

具体来说，数据写入有界队列后，可以通过异步线程对队列中的消息体进行特征值比较，从而进行数据的进一步合并，进一步压缩数据包，减少网络请求次数以及发送时的网络流量。例如在业务中，同一个方法被连续调用多次，就可以将连续调用的这一过程进行合并。

图3示意性示出本公开示例性实施例中一种执行第二线程的流程示意图。参考图3所示，写入有界队列中301的是步骤S111经初步压缩后的消息体302，异步执行线程303和304对消息体进行读取并数据合并，最终由发送模块305读取偏移量以进行发送。举例来说，可以按照正对相同类+方法的参数按照时间段进行合并，提交偏移量(Send Offset)从而进一步减少数据量；之后将合并后的消息体写入日志采集器的发送模块(Sender)305，发送模块读取偏移量(Offset Reader)，并经由UDP(User Datagram Protocol，用户数据报协议)协议将数据发送至数据分析器。

在步骤S12中，基于所述全链路的业务日志创建业务关键字，并确定包括所述业务关键字的业务请求信息。

在日志采集器获取到全量全链路业务日志之后，数据分析器可以处理所有业务日志中请求的参数，然后分析出合理的业务关键字，根据业务关键字可以查询到包括该业务关键字的业务请求中的参数名和数据经过方法名及应用名等业务请求信息，这样就可以知道业务关键字在哪个应用哪个方法中使用，从而为后续生成业务调用链路信息以及建立索引关系提供基础。

在本公开的一个实施例中，在所述基于所述全链路的业务日志创建业务关键字之前，所述方法还包括：对所述业务日志进行数据类型过滤和/或关键字过滤。

为了过滤掉一些与创建索引无用的信息，可以通过过滤器先过滤掉，例如一些不会被用于作为业务关键字的信息，比如中文、时间、小数、数字位数少于8位(因为普遍的运单号都是8位以上)的等等规则。过滤的规则可以根据系统的实际使用情况进行设定，本公开在此就不做具体限定。

根据设置的过滤规则，可以按照对应的方式进行过滤。举例而言，如果需要过滤掉小数或日期，那么可以通过数据类型过滤，将浮点类型和日期类型信息删除，或者利用关键字过滤，例如参数中包括过滤掉时间“time”、日期“date”、姓名“name”、类型“type”等等，将这些关键字参数对应的信息过滤。

举例而言，有业务日志(一)如下：

根据需求，将文字、数量等信息进行剔除，采用经过数据类型和关键词过滤后业务日志(二)如下：

经过过滤后，数据量更小，有利于更快进行数据分析，创建索引关系。

在本公开的一个实施例中，所述基于所述全链路的业务日志创建业务关键字，包括：提取所述业务日志中业务请求的参数；在所述参数满足关键字条件时，将所述参数作为所述业务关键字。

具体来说，每个业务请求中都包括不同的参数，可以将每个参数设置为业务关键字，但是这样会造成存储的信息过多，难度大，实现较困难，所以可以设置关键字条件来对业务关键字进行筛选。

关键字条件可以依据该业务关键字出现的频率、频次或者与其他请求的关联性进行判断，也可以由人工进行确认，若用户确认后则记录为关键字，若没有确认，则不进行记录。设置时可以根据需求完成，本示例中对设置的关键字条件仅是示例性说明，并不能限制本公开。

举例来说，如有一经过滤后的业务日志(三)如下：

业务日志(二)中请求1的orderNo和业务日志(三)中请求2的wayBillNo字段是一致的，由此可以推导出请求1和请求2都处理过“1234567890”这个数据。所以将“1234567890”设置为关键字，同时记录请求1和请求2中“1234567890”的参数名和数据经过方法名及应用名等业务请求信息。

在基于全链路的业务日志创建业务关键字之后，从业务日志中检索包括该业务关键字的业务请求信息。

举例而言，以业务关键字为1234567890为例，可以查询到该业务关键字的业务请求信息如下：

请求1：(调用：17：00，A应用，方法f1；入参：xxx，1234567890；返回值：xxx)。

请求2：(调用：17：10，B应用，方法f2；入参：1234567890；返回值：xxx)。

请求3：(调用：17：20，A应用，方法f5；入参：1234567890；返回值：xxx)。

在步骤S13中，根据所述业务请求信息创建业务请求索引，以及生成业务调用链路信息。

具体来说，对每个请求中所调用应用之间建立关联，可以采用分布式调用链。所述业务请求信息包括至少一个事务的事务信息，所述根据所述业务请求生成业务调用链路信息，包括：

步骤S131，为全链路中所述事务分配全局唯一的交易标识；以及

步骤S132，根据所述业务请求信息获取所述事务之间的调用关系；

步骤S133，基于所述交易标识和所述调用关系生成所述业务调用链路信息。

图4示意性示出本公开示例性实施例中一种业务调用链路信息追踪过程的示意图。参考图4所示，401节点1(Node1)和402节点2(Node2)属于应用a的节点，403节点3(Node3)和404节点4(Node4)为应用b的节点，整个调用链路完成一个事务，事务编号为TxID(交易标识)，即为Node1^Time1^1，并用SpanId和pSpanId标注节点之间的调度关系，从而完成跨应用的调用关系的标注。

其中，使用TxID在分布式系统间单个事务发送/接收的消息的ID，ID是必须跨整个服务器集群做到全局唯一。

Span是RPC(Remote Procedure Call Protocol，远程过程调用协议)跟踪的基本单元，当一个RPC调用到达时指示工作已经处理完成并包含跟踪数据。为了确保代码级别的可见性，Span拥有带SpanEvent标签的子结构作为数据结构。每个Span包含一个TraceId。

Trace是多个Span的集合，即一次业务请求的TxID，由关联的RPC(Spans)组成。在同一个Trace中的Span共享相同的TransactionId。Trace通过SpanId和ParentSpanId整理为继承树结构。

SpanId是指当收到RPC消息时处理的工作的ID，在RPC请求到达节点时生成。PSpanId则是发起RPC调用的父span的SpanId，如果节点是事务的起点，这里将没有父span，对于这种情况，使用值-1来表示这个span是事务的根span。

在步骤S14中，创建所述第一索引关系和所述第二索引关系。

根据步骤S13的执行过程可以知道，在创建业务请求索引，以及生成业务调用链路信息时是根据业务关键字的业务请求信息实现的，因此可以分别创建业务关键字与业务请求索引之间的第一索引关系，以及所述业务请求索引与业务调用链路信息之间的第二索引关系。

举例而言，表1示出了根据业务日志(二)和业务日志(三)创建的第一索引关系索引表。

表1第一索引关系索引表

如表1所示，业务关键字“1234567890”与请求“orderNo”以及“wayBillNo”都相关，业务关键字“13477789900”则与请求“sendUserAddress.phone”相关。

表2示出了根据业务日志(二)和业务日志(三)创建的第二索引关系索引表。

表2第二索引关系索引表

其中，SpanId是收到RPC时处理的工作的ID，PSpanId是发起RPC调用的父span，使用值-1表示这个span是事务的根span。

在本公开的一个实施例中，在建立索引关系后，可以将相关的数据存储至索引数据库中，方便后续根据业务关键字查找业务请求信息。在数据存储时，设计数据索引表(DATA_INDEX)，用于存储第一索引关系，keyword为业务关键字，其中包括record_id，即对应DATA_RECODE中的业务调用链路信息；设计数据记录表(DATA_RECODE)，用于存储第二索引关系，记录分布式调用的业务调用链路信息，利用record_id获取；同时，还设计了根据业务单元BU的业务日志原始数据Original Date生成的相关表(Meta)，用于记录、描述应用、方法之间的元数据，用于推断业务应用之间的关联。

图5示意性示出本公开示例性实施例中一种索引数据库中数据之间的关系的示意图。参考图5所示，其中索引数据库包括了DATA_INDEX、DATA_RECODE、Meta(包括meta_method、meta_request等)以及存储业务日志的BU、APP之类的Original Date。

步骤S2，响应于目标业务关键字的查询请求，基于所述第一索引关系获取所述目标业务关键字对应的目标业务请求索引，以及步骤S3，基于所述第二索引关系获取所述目标业务请求索引对应的目标业务调用链路信息，以利用所述目标业务调用链路信息进行业务问题定位，解释了根据业务关键字查询业务调用链路信息的过程。

具体地，首先需要生成目标业务关键字的查询请求。生成请求这一过程可以由终端设备响应于用户的操作生成，再将查询请求中的业务关键字发送至查询服务器，由查询服务器来根据业务关键字进行查询。

在接收到业务系统的查询请求之后，首先提取查询请求中的目标业务关键字，然后执行步骤S2和步骤S3，根据第一索引关系获取对应的目标业务请求索引，再根据第二索引关系获取对应的目标业务调用链路信息。

在本公开的一个实施例中，在所述目标业务关键字对应多个目标业务请求索引时，所述方法还包括：获取各所述目标业务请求索引的业务请求；根据所述业务请求确定各所述目标业务请求索引之间的上下游关系；基于所述上下游关系将各所述目标业务调用链路信息进行整合得到目标业务全链路信息，以利用所述目标业务全链路信息进行业务问题定位。

具体地，一个业务请求对应了一个业务调用链路信息，而当一个业务关键字对应多个目标业务请求时，便获得了多条业务调用链路信息，为了能够直观地展示上下游的关系，方便用户根据业务流程进行问题追溯，所有还可以对获取的业务调用链路信息进行整理并合并得到业务全链路信息。

举例来说，在业务日志的元数据中包括有请求的调用时间，根据调用时间的先后顺序确定各个业务请求的上下游关系。比如请求1调用时间为17：00，请求2调用时间为17：10，请求3调用时间为17：20，那么链路之间的上下游关系为：请求1-请求2-请求3，在全链路追溯时，就可以考虑上下游关系进行问题定位。

在本公开的一个实施例中，所述方法还包括：利用所述目标业务调用链路信息进行业务问题定位，得到异常事务以及所述异常事务在所述目标业务调用链路信息中的异常位置信息。

当查询服务器在查询到业务调用链路信息之后，可以先进行自检。例如对于链路中的各个事务环节中的数据返回值与预设的返回值进行比较，当超过了一定的阈值范围，则被定义为异常事务；或者是当链路中某一事务环节缺少入参，则被定义为异常事务。需要说明的是，本实施例公开的只是业务问题定位的示例性解释，并不能限制本公开。

在问题定位之后确定了异常事务之后，还可以获取该异常事务在业务调用链路信息中的异常位置信息，进而方便工作人员按照异常位置信息进行问题查询和解决。

基于上述方法，一方面写入优化的全量全链路业务日志，通过两次压缩处理减小数据量，加快索引关系的创建速度，数据全面；另一方面通过建立业务关键字索引方式打通上下游应用之间的业务流程关联，能够基于业务关键字自动获取所有相关的业务调用链路信息，自动化程度高；再一方面，通过设计数据索引关联业务请求的业务查询方案，能够将数据分布式存储，并且加快了链路信息的查询速度，进而能够实现问题的快速定位。

图6示意性示出本公开示例性实施例中一种问题定位装置的组成示意图，如图6所示，该问题定位装置600可以包括采集模块601、第一查询模块602以及第二查询模块603。其中：

采集模块601，用于采集全链路的业务数据以创建业务关键字与业务请求索引之间的第一索引关系，以及所述业务请求索引与业务调用链路信息之间的第二索引关系；

第一查询模块602，用于响应于目标业务关键字的查询请求，基于所述第一索引关系获取所述目标业务关键字对应的目标业务请求索引；

第二查询模块603，用于基于所述第二索引关系获取所述目标业务请求索引对应的目标业务调用链路信息，以利用所述目标业务调用链路信息进行业务问题定位。

根据本公开的示例性实施例，所述采集模块601可以包括全量采集单元、关键字单元、链路单元以及索引单元。其中，所述全量采集单元用于对全链路的业务数据进行全量采集得到全链路的业务日志；所述关键字单元用于基于所述全链路的业务日志创建业务关键字，并确定包括所述业务关键字的业务请求信息；所述根据所述业务请求信息创建业务请求索引，以及生成业务调用链路信息；所述索引单元用于创建所述第一索引关系和所述第二索引关系。

根据本公开的示例性实施例，所述全量采集单元用于基于第一线程池执行利用面向切面编程AOP方式获取全链路的业务数据，并对所述业务数据进行初步压缩后写入有界队列；基于第二线程池执行针对所述有界队列中各消息体进行特征值比较，以进行再次压缩得到所述业务日志。

根据本公开的示例性实施例，所述全量采集单元还用于基于预设的常用参数值和常量之间的映射关系将所述业务数据中的参数值替换为常量；和/或采用变长编码方法对所述业务数据进行压缩编码。

根据本公开的示例性实施例，所述关键字单元用于在所述基于所述全链路的业务日志创建业务关键字之前，对所述业务日志进行数据类型过滤和/或关键字过滤。

根据本公开的示例性实施例，所述关键字单元还用于提取所述业务日志中业务请求的参数；在所述参数满足关键字条件时，将所述参数作为所述业务关键字。

根据本公开的示例性实施例，所述链路单元用于为全链路中所述事务分配全局唯一的交易标识；以及根据所述业务请求信息获取所述事务之间的调用关系；基于所述交易标识和所述调用关系生成所述业务调用链路信息。

根据本公开的示例性实施例，所述问题定位装置600还可以包括整合模块，所述整合模块用于在所述目标业务关键字对应多个目标业务请求索引时，获取各所述目标业务请求索引的业务请求；根据所述业务请求确定各所述目标业务请求索引之间的上下游关系；基于所述上下游关系将各所述目标业务调用链路信息进行整合得到目标业务全链路信息，以利用所述目标业务全链路信息进行业务问题定位。

根据本公开的示例性实施例，所述问题定位装置600还可以包括定位模块，所述定位模块用于利用所述目标业务调用链路信息进行业务问题定位，得到异常事务以及所述异常事务在所述目标业务调用链路信息中的异常位置信息。

上述的问题定位装置600中各模块的具体细节已经在对应的问题定位方法中进行了详细的描述，因此此处不再赘述。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

在本公开的一个实施例中，还提供了一种问题定位系统，包括：

日志采集器，用于采集全链路的业务数据，并将所述业务数据发送至数据分析器；数据分析器，用于接收所述日志采集器发送的所述业务数据，并创建业务关键字与业务请求索引之间的第一索引关系，以及所述业务请求索引与业务调用链路信息之间的第二索引关系，并将所述第一索引关系、所述第二索引关系和所述业务数据存储至索引数据库中；用户查询界面，用于响应于目标业务关键字的查询请求，将所述查询请求查询分析器，以及显示所述查询分析器返回的目标业务调用链路信息；查询分析器，用于接收所述查询请求，调用所述索引数据库基于所述第一索引关系获取所述目标业务关键字对应的目标业务请求索引，基于所述第二索引关系获取所述目标业务请求索引对应的目标业务调用链路信息，并将所述目标业务调用链路信息返回至所述用户查询界面。

图7示意性示出本公开示例性实施例中一种问题定位系统的数据交互示意图。参考图7所示，问题定位系统包括日志采集器701、数据分析器702、索引数据库703、用户查询界面704以及查询分析器705。

在日志采集器701中，首先采集全链路的业务数据并进行初步压缩写入有界队列，然后再次压缩得到业务日志，之后将业务日志发送至数据分析器702。

其中，所述日志采集器被配置为：使用用户数据报UDP协议将所述业务数据发送至数据分析器。其中，UDP是一个简单的传输层协议，应用进程往一个UDP套接字写入一个消息，该消息随后被封装到一个UDP数据包，该UDP数据报进而又被封装到一个IP数据报，然后发送到目的地。UDP不保证UDP数据会达到其最终目的地，不保证各个数据报的先后顺序跨网络后保持不变，也不保证每个数据包只能达到一次。

因为UDP协议连接简单、发送后不需要确认，当数据通讯持续突发时网络会成为问题，在这种情况下，使用UDP协议来给服务让出网络连接优先级。

在数据分析器702中，对接收到的日志采集器701发送的业务日志进行数据分析，将元数据存储为Original Date，将业务日志中的应用、方法等信息生成Meta，创建业务关键字以及第一和第二索引关系得到索引信息Index Info，包括DATA_INDEX和DATA_RECODE，将这些数据都存储至索引数据库703中。

索引数据库703则包括从数据分析器702整理的Meta(包括Application Info、Business Info等)、Index Info(包括DATA_INDEX、DATA_RECODE)以及元数据OriginalDate。

在用户查询界面704中，用户可以与之进行交互，例如支持用户输入查询信息，用户查询界面将查询信息中的业务关键字发送给查询分析器705，以及将查询分析器705返回的业务调用链路信息进行显示。

在查询分析器705中，接收用户查询界面发送的查询请求，提取目标业务关键字，然后调用索引数据库703根据第一索引关系和第二索引关系获取到业务调用链路信息，将其返回给用户查询界面704。

根据本公开的示例性实施例，所述查询分析器还被配置为：利用所述目标业务调用链路信息进行业务问题定位，得到异常事务以及所述异常事务在所述目标业务调用链路信息中的异常位置信息；将所述异常事务和所述异常位置信息返回至所述用户查询界面。

当用户查询界面接收到异常事务和异常位置信息时，可以将其显示在查询界面中，所述用户查询界面还被配置为：将从所述查询分析器接收到的所述异常事务按照所述异常位置信息进行突出显示。

具体地，突出显示可以例如以不同颜色、不同字体、特殊符号等形式进行突出显示，本公开在不做具体限定。

根据本公开的示例性实施例，所述用户查询界面还被配置为：根据所述目标业务调用链路信息中的事务生成事务查看按钮；基于用户对目标事务查看按钮的操作生成目标事务的查看请求，并将所述查看请求发送至查询分析器；以及显示从所述查询分析器返回的目标事务信息。

所述查询分析器还被配置为：接收所述用户查询界面发送的所述目标事务的查看请求；调用所述索引数据库提取目标事务信息，并将所述目标事务信息返回至所述用户查询界面。

具体来说，业务调用链路信息中包括了该链路上各个环节的事物信息，例如在该环节处调用的应用、方法、入参、返回值等。因此可以在用户查询界面中提供一个事务查询功能。

因此，在用户查询界面显示业务调用链路信息之后，为每一个事务都提供查看按钮，这样一来，用户可选择想要查看信息的事务查看按钮，之后用户查询界面将查看请求发送至查询分析器，调用索引数据库获取该事务对应的原始数据，将其返回至用户查询界面以进行显示。

图8示意性示出本公开示例性实施例中一种用户查询界面的界面示意图。参考图8所示，用户查询界面中提供一个搜索区域801，用户可以在该搜索中输入待查询的信息，用户查询界面便可根据输入信息生成查询请求，而输入信息则为业务关键字。

同时，用户查询界面中还提供了用于显示业务调用链路信息的显示区域802，展示出了该业务关键字对应的全部业务调用链路信息，调用链路中包括了多个事务，并且按照调用时间进行上下游整合之后进行显示。

在用户查询界面的右侧还提供可用于查看事务信息的查看区域803，可以展示业务调用链路信息中某一事物的详细信息，例如方法名、入参、出参等。

通过提供可视化的查询界面，输入需要查询的关键字，例如运单号，系统通过查询索引快速查询出这个运单号所有请求的中调用的方法，并且按照时间顺序排序。如果出现异常，可以一眼看出，并且可以看到上游调用的参数及返回值；如果没有异常发生而是数据不准确，可以通过从上到下追踪数据，从而快速发现数据不准确的点，从而快速解决问题。

在本公开的示例性实施例中，还提供了一种能够实现上述方法的存储介质。图9示意性示出本公开示例性实施例中一种计算机可读存储介质的示意图，如图9所示，描述了根据本公开的实施方式的用于实现上述方法的程序产品900，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如手机上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。图10示意性示出本公开示例性实施例中一种电子设备的计算机系统的结构示意图。

需要说明的是，图10示出的电子设备的计算机系统700仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图10所示，计算机系统1000包括中央处理单元(Central Processing Unit，CPU)1001，其可以根据存储在只读存储器(Read-Only Memory，ROM)1002中的程序或者从存储部分1008加载到随机访问存储器(Random Access Memory，RAM)1003中的程序而执行各种适当的动作和处理。在RAM 1003中，还存储有系统操作所需的各种程序和数据。CPU1001、ROM 1002以及RAM 1003通过总线1004彼此相连。输入/输出(Input/Output，I/O)接口1005也连接至总线1004。

以下部件连接至I/O接口1005：包括键盘、鼠标等的输入部分1006；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分1007；包括硬盘等的存储部分1008；以及包括诸如LAN(Local AreaNetwork，局域网)卡、调制解调器等的网络接口卡的通信部分1009。通信部分1009经由诸如因特网的网络执行通信处理。驱动器1010也根据需要连接至I/O接口1005。可拆卸介质1011，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1010上，以便于从其上读出的计算机程序根据需要被安装入存储部分1008。

特别地，根据本公开的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1009从网络上被下载和安装，和/或从可拆卸介质1011被安装。在该计算机程序被中央处理单元(CPU)1001执行时，执行本公开的系统中限定的各种功能。

需要说明的是，本公开实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为另一方面，本公开还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (18)

1.一种问题定位方法，其特征在于，包括：

采集全链路的业务数据以创建业务关键字与业务请求索引之间的第一索引关系，以及所述业务请求索引与业务调用链路信息之间的第二索引关系；

响应于目标业务关键字的查询请求，基于所述第一索引关系获取所述目标业务关键字对应的目标业务请求索引；

基于所述第二索引关系获取所述目标业务请求索引对应的目标业务调用链路信息，以利用所述目标业务调用链路信息进行业务问题定位。

2.根据权利要求1所述的问题定位方法，其特征在于，所述采集全链路的业务数据以创建业务关键字与业务请求索引之间的第一索引关系，以及所述业务请求索引与业务调用链路信息之间的第二索引关系，包括：

对全链路的业务数据进行全量采集得到全链路的业务日志；

基于所述全链路的业务日志创建业务关键字，并确定包括所述业务关键字的业务请求信息；

根据所述业务请求信息创建业务请求索引，以及生成业务调用链路信息；

创建所述第一索引关系和所述第二索引关系。

3.根据权利要求2所述的问题定位方法，其特征在于，所述对全链路的业务数据进行全量采集得到全链路的业务日志，包括：

基于第一线程池执行利用面向切面编程AOP方式获取全链路的业务数据，并对所述业务数据进行初步压缩后写入有界队列；

基于第二线程池执行针对所述有界队列中各消息体进行特征值比较，以进行再次压缩得到所述业务日志。

4.根据权利要求3所述的问题定位方法，其特征在于，所述初步压缩包括：

基于预设的常用参数值和常量之间的映射关系将所述业务数据中的参数值替换为常量；和/或

采用变长编码方法对所述业务数据进行压缩编码。

5.根据权利要求2所述的问题定位方法，其特征在于，在所述基于所述全链路的业务日志创建业务关键字之前，所述方法还包括：

对所述业务日志进行数据类型过滤和/或关键字过滤。

6.根据权利要求2所述的问题定位方法，其特征在于，所述基于所述全链路的业务日志创建业务关键字，包括：

提取所述业务日志中业务请求的参数；

在所述参数满足关键字条件时，将所述参数作为所述业务关键字。

7.根据权利要求2所述的问题定位方法，其特征在于，所述业务请求信息包括至少一个事务的事务信息，所述根据所述业务请求生成业务调用链路信息，包括：

为全链路中所述事务分配全局唯一的交易标识；以及

根据所述业务请求信息获取所述事务之间的调用关系；

基于所述交易标识和所述调用关系生成所述业务调用链路信息。

8.根据权利要求1所述的问题定位方法，其特征在于，在所述目标业务关键字对应多个目标业务请求索引时，所述方法还包括：

获取各所述目标业务请求索引的业务请求；

根据所述业务请求确定各所述目标业务请求索引之间的上下游关系；

基于所述上下游关系将各所述目标业务调用链路信息进行整合得到目标业务全链路信息，以利用所述目标业务全链路信息进行业务问题定位。

9.根据权利要求1所述的问题定位方法，其特征在于，所述方法还包括：

利用所述目标业务调用链路信息进行业务问题定位，得到异常事务以及所述异常事务在所述目标业务调用链路信息中的异常位置信息。

10.一种问题定位装置，其特征在于，包括：

采集模块，用于采集全链路的业务数据以创建业务关键字与业务请求索引之间的第一索引关系，以及所述业务请求索引与业务调用链路信息之间的第二索引关系；

第一查询模块，用于响应于目标业务关键字的查询请求，基于所述第一索引关系获取所述目标业务关键字对应的目标业务请求索引；

第二查询模块，用于基于所述第二索引关系获取所述目标业务请求索引对应的目标业务调用链路信息，以利用所述目标业务调用链路信息进行业务问题定位。

11.一种问题定位系统，其特征在于，包括：

日志采集器，用于采集全链路的业务数据，并将所述业务数据发送至数据分析器；

数据分析器，用于接收所述日志采集器发送的所述业务数据，并创建业务关键字与业务请求索引之间的第一索引关系，以及所述业务请求索引与业务调用链路信息之间的第二索引关系，并将所述第一索引关系、所述第二索引关系和所述业务数据存储至索引数据库中；

用户查询界面，用于响应于目标业务关键字的查询请求，将所述查询请求发送至查询分析器，以及显示所述查询分析器返回的目标业务调用链路信息；

查询分析器，用于接收所述查询请求，调用所述索引数据库基于所述第一索引关系获取所述目标业务关键字对应的目标业务请求索引，基于所述第二索引关系获取所述目标业务请求索引对应的目标业务调用链路信息，并将所述目标业务调用链路信息返回至所述用户查询界面。

12.根据权利要求11所述的问题定位系统，其特征在于，所述查询分析器还被配置为：

利用所述目标业务调用链路信息进行业务问题定位，得到异常事务以及所述异常事务在所述目标业务调用链路信息中的异常位置信息；

将所述异常事务和所述异常位置信息返回至所述用户查询界面。

13.根据权利要求12所述的问题定位系统，其特征在于，所述用户查询界面还被配置为：

将从所述查询分析器接收到的所述异常事务按照所述异常位置信息进行突出显示。

14.根据权利要求11所述的问题定位系统，其特征在于，所述用户查询界面还被配置为：

根据所述目标业务调用链路信息中的事务生成事务查看按钮；

基于用户对目标事务查看按钮的操作生成目标事务的查看请求，并将所述查看请求发送至查询分析器；以及

显示从所述查询分析器返回的目标事务信息。

15.根据权利要求14所述的问题定位系统，其特征在于，所述查询分析器还被配置为：

接收所述用户查询界面发送的所述目标事务的查看请求；

调用所述索引数据库提取目标事务信息，并将所述目标事务信息返回至所述用户查询界面。

16.根据权利要求11所述的问题定位系统，其特征在于，所述日志采集器被配置为：

使用用户数据报UDP协议将所述业务数据发送至数据分析器。

17.一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如权利要求1至9任一项所述的问题定位方法。

18.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至9任一项所述的问题定位方法。

Images