一种微服务链路监控方法、装置、设备及介质与流程

本发明涉及计算机技术领域，特别涉及一种微服务链路监控方法、装置、设备及介质。

背景技术：

当前，随着微服务应用模式日益流行，伴随出现了在微服务应用场景下系统故障的及时发现和定位问题。现有技术中，通过人工查看日志的方式确定系统故障，但由于一个互联网的应用通常会被拆分成多个不同的模块，调用过程产生的日志可能分布在几台甚至几十台不同的机器上，因此可能导致线上产生的问题无法迅速定位并在短时间内有效的解决问题，所以通过人工去查看日志的方式定位系统的故障具有很大的局限性。为解决上述问题，现有技术中通过编写代码来处理局部故障，但由于微服务是一个分布式系统，开发者需要选择和实现基于消息或者远程过程调用协议(即remoteprocedurecallprotocol，rpc)的进程间通信机制，使其整体变得复杂，并且微服务模式下模块间需要相互调用，一次请求往往需要涉及到多个服务，由此降低了通过编写代码的方式进行系统故障定位的普适性和速度。

技术实现要素：

有鉴于此，本发明的目的在于提供一种微服务链路监控方法、装置、设备及介质。其具体方案如下：

第一方面，本申请公开了一种微服务链路监控方法，包括：

创建目标探针和目标监控日志格式；

基于所述目标探针并根据所述目标监控日志格式，采集与目标微服务链路的dubbo调用对应的日志数据；

通过数据收集器从所述目标探针获取所述日志数据并将所述日志数据发送至搜索服务器，以便所述搜索服务器对所述目标微服务链路进行监控和分析。

可选的，所述目标监控日志格式包括监控日志标识、时间信息、日志类型、链路标识、第一类被调用信息标识、发起调用方标识、第二类被调用信息标识以及扩展信息。

可选的，所述日志类型，包括客户端发起日志、客户端接收日志、服务端接收日志、服务端反馈日志和异常信息日志。

可选的，所述目标探针包括客户端拦截探针、客户端过滤探针和服务端过滤探针；

相应的，所述基于所述目标探针并根据所述目标监控日志格式，采集与目标微服务链路的dubbo调用对应的日志数据，包括：

基于所述客户端拦截探针并根据所述目标监控日志格式，从网页框架的控制层采集与目标微服务链路的dubbo调用对应的第一日志数据；

基于所述客户端过滤探针并根据所述目标监控日志格式，从客户端采集与目标微服务链路的dubbo调用对应的第二日志数据；

基于所述服务端过滤探针并根据所述目标监控日志格式，从服务端采集与目标微服务链路的dubbo调用对应的第三日志数据。

可选的，所述基于所述客户端拦截探针并根据所述目标监控日志格式，从网页框架的控制层采集与目标微服务链路的dubbo调用对应的第一日志数据，包括：

利用所述拦截探针从服务调用请求中采集所述链路标识，并生成所述目标微服务链路的第一类被调用信息标识；

利用所述拦截探针查看所述服务调用请求中是否已含有第一类被调用信息标识；

如果是，则将所述服务调用请求中的第一类被调用信息标识作为所述目标微服务链路的发起调用方标识；

如果否，则将所述目标微服务链路的第一类被调用信息标识对应的数据赋值给所述目标微服务链路的发起调用方标识；

基于所述链路标识、所述目标微服务链路的第一类被调用信息标识和所述目标微服务链路的发起调用方标识生成所述服务端反馈日志；

利用所述拦截探针采集所述服务调用请求在处理过程中的异常信息以得到所述异常信息日志，并在所述服务调用请求完成后采集所述服务端接收日志；

利用所述拦截探针获取当前主机ip作为所述扩展信息以标识所述服务调用请求的入口服务器地址；

基于所述服务端反馈日志、所述服务端接收日志、所述异常信息日志和所述扩展信息得到所述目标微服务链路的dubbo调用对应的第一日志数据。

可选的，所述基于所述客户端拦截探针并根据所述目标监控日志格式，从网页框架的控制层采集与目标微服务链路的dubbo调用对应的第一日志数据的过程中，还包括：

将所述链路标识、所述目标微服务链路的第一类被调用信息标识和所述目标微服务链路的发起调用方标识存储于与当前调用线程对应的存储结构中；

在所述服务调用请求完成后清空所述存储结构中的数据。

可选的，所述基于所述客户端过滤探针并根据所述目标监控日志格式，从客户端采集与目标微服务链路的dubbo调用对应的第二日志数据，包括：

利用所述客户端过滤探针从当前调用线程中采集所述时间信息、所述链路标识和所述目标微服务链路的第一类被调用信息标识，以得到所述客户端发起日志，并将所述链路标识和所述目标微服务链路的第一类被调用信息标识发送至服务端；

在服务调用请求完成后利用所述客户端过滤探针采集当前时间得到所述时间信息，以得到所述客户端接收日志；

基于所述客户端发起日志和所述客户端接收日志得到所述目标微服务链路的dubbo调用对应的第二日志数据。

可选的，所述基于所述服务端过滤探针并根据所述目标监控日志格式，从服务端采集与目标微服务链路的dubbo调用对应的第三日志数据，包括：

利用所述服务端过滤探针从客户端发送的数据中采集所述时间信息，所述链路标识和所述目标微服务链路的第一类被调用信息标识，以得到所述服务端接收日志；

在服务调用请求完成后利用所述服务端过滤探针采集当前时间得到所述时间信息，以得到所述服务端反馈日志，并采集服务端异常信息得到所述异常信息日志；

基于所述服务端接收日志、所述服务端反馈日志和所述异常信息日志得到所述目标微服务链路的dubbo调用对应的第三日志数据。

可选的，所述通过数据收集器从所述目标探针获取所述日志数据并将所述日志数据发送至搜索服务器，包括：

利用第一fluentd插件并基于所述监控日志标识从所述拦截探针获取所述第一日志数据以及从所述客户端过滤探针获取所述第二日志数据，并将所述第一日志数据和所述第二日志数据发送至搜索服务器elasticsearch；

利用第二fluentd插件并基于所述监控日志标识从所述服务端过滤探针获取所述第三日志数据，并将所述第三日志数据发送至所述搜索服务器elasticsearch。

第二方面，本申请公开了一种微服务链路监控装置，包括：

创建模块，用于创建目标探针和目标监控日志格式；所述目标探针包括客户端拦截探针、客户端过滤探针和服务端过滤探针；

日志获取模块，用于基于所述目标探针并根据所述目标监控日志格式，采集与目标微服务链路的dubbo调用对应的日志数据；

日志发送模块，用于通过数据收集器从所述目标探针获取所述日志数据并将所述日志数据发送至搜索服务器，以便所述搜索服务器对所述目标微服务链路进行监控和分析。

第三方面，本申请公开了一种电子设备，包括：

存储器，用于保存计算机程序；

处理器，用于执行所述计算机程序，以实现前述的微服务链路监控方法。

第四方面，本申请公开了一种计算机可读存储介质，其特征在于，用于存储计算机程序；其中计算机程序被处理器执行时实现前述的微服务链路监控方法。

本申请中，通过创建目标探针和目标监控日志格式，然后基于所述目标探针并根据所述目标监控日志格式采集与目标微服务链路的dubbo调用对应的日志数据，最后通过数据收集器从所述目标探针获取所述日志数据并将所述日志数据发送至搜索服务器，以便所述搜索服务器对所述目标微服务链路进行监控和分析。本申请通过创建目标探针，利用所述目标探针并根据目标监控日志格式采集与目标微服务链路对应的日志数据，然后由数据收集器将所述日志数据发送至搜索服务器，并由搜索服务器对所述目标微服务链路进行监控和分析，相比于现有技术中通过编写代码的方式，通过创建的探针获取相应的日志数据减少了对业务系统的侵入，同时减少开发人员的负担，通过这种方式，可以自动采集并分析日志，提高了系统故障位置和性能瓶颈位置定位的能力。

附图说明

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

图1为本申请提供的一种链路监控方法流程图；

图2为本申请提供的一种具体的链路监控方法流程图；

图3为本申请提供的一种具体的服务调用请求及链路监控流程图；

图4为本申请提供的一种装置结构示意图；

图5为本申请提供的一种电子设备结构图。

具体实施方式

现有技术中，通过编写代码来处理微服务应用过程中的故障问题，降低了系统故障位置和性能瓶颈位置定位的普适性和速度。为了克服上述问题，本申请提出一种实现多cpu架构下dubbo微服务链路监控方法，可以提高系统故障位置和性能瓶颈位置定位的能力。

本发明实施例公开了一种链路监控方法，参见图1所示，该方法可以包括以下步骤：

步骤s11：创建目标探针和目标监控日志格式。

本实施例中，首先创建目标探针和目标监控日志格式，其中，上述目标探针可以包括客户端拦截探针、客户端过滤探针和服务端过滤探针，可以理解的是，本实施例中可以在客户端创建客户端拦截探针，在客户端创建客户端过滤探针，以及在服务端创建服务端过滤探针；并且，需要说明的是，此处的客户端并不是特指，在微服务模式下所有发起调用请求的调用方都可以认为是客户端；相应的，此处的服务端也不是特指，在微服务模式下所有被调用方都可以认为是服务端；可以理解的是，一个服务方既可以作为客户端也可以作为服务端。

步骤s12：基于所述目标探针并根据所述目标监控日志格式，采集与目标微服务链路的dubbo调用对应的日志数据。

本实施例中，在创建上述目标探针和目标监控日志格式后，可以基于上述目标探针并根据上述目标监控日志格式，采集与目标微服务链路的dubbo调用对应的日志数据。可以理解的是，在基于dubbo方式实现调用的微服务应用模式下，不同服务方之间的调用会产生相应的微服务链路，通过在不同服务方上创建上述客户端拦截探针、上述客户端过滤探针和上述服务端过滤探针，可以采集到基于dubbo方式实现调用时产生的目标微服务链路的日志数据，并且根据上述目标探针可以采集到相应的客户端日志数据或服务端日志数据。其中，dubbo是一款高性能、轻量级的开源javarpc框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

步骤s13：通过数据收集器从所述目标探针获取所述日志数据并将所述日志数据发送至搜索服务器，以便所述搜索服务器对所述目标微服务链路进行监控和分析。

本实施例中，在利用上述目标探针采集到上述目标微服务链路对应的日志数据后，可以通过预先在每台服务器上安装的数据收集器从上述目标探针实时获取上述日志数据，并通过简单的数据处理后发送至搜索服务器，以便上述搜索服务器通过对日志数据的进行查询分析实现对上述目标微服务链路进行监控和分析，从而实时并精确的定位到系统的性能瓶颈和错误原因。

由上可见，本实施例通过创建目标探针和目标监控日志格式，然后基于所述目标探针并根据所述目标监控日志格式采集与目标微服务链路的dubbo调用对应的日志数据，最后通过数据收集器从所述目标探针获取所述日志数据并将所述日志数据发送至搜索服务器，以便所述搜索服务器对所述目标微服务链路进行监控和分析。本实施例通过创建目标探针，利用所述目标探针并根据目标监控日志格式采集与目标微服务链路对应的日志数据，然后由数据收集器将所述日志数据发送至搜索服务器，并由搜索服务器对所述目标微服务链路进行监控和分析，相比于现有技术中通过编写代码的方式，通过创建的探针获取相应的日志数据减少了对业务系统的侵入，同时减少开发人员的负担，通过这种方式，可以自动采集并分析日志，提高了系统故障位置和性能瓶颈位置定位的能力。

本发明实施例公开了一种具体的链路监控方法，参见图2所示，该方法可以包括以下步骤：

步骤s21：创建目标探针和目标监控日志格式。

本实施例中，所述目标监控日志格式可以包括但不限于监控日志标识、时间信息、日志类型、链路标识、第一类被调用信息标识、发起调用方标识、第二类被调用信息标识以及扩展信息。并且上述目标监控日志的格式可以由用户自定义。其中，上述监控日志标识用于标识微服务链路的监控日志，上述链路标识用于标识当前微服务链路，具体的上述链路标识可以为traceid，上述第一类被调用信息标识和上述第二类被调用信息标识用于标识当前被调用服务调的信息，具体的上述第一类被调用信息标识可以为spanid，上述第二类被调用信息标识可以为spanname，上述发起调用方标识用于标识发起调用的服务方，具体的上述发起方调用标识可以为parentspanid，上述扩展信息可以存放业务数据，以便体现当前链路中的业务信息。

本实施例中，所述日志类型，包括客户端发起日志、客户端接收日志、服务端接收日志、服务端反馈日志和异常信息日志。其中，上述客户端发起日志即cs(clientstart)日志，表示客户端发起请求；上述服务端接收日志即sr(serverreceive)日志，表示服务端收到上述客户端的请求；上述服务端反馈日志即ss(serversend)日志，表示服务端完成请求的处理，并将结果发送给客户端；上述客户端接收日志即cr(clientreceived)日志，表示客户端接收到上述服务端的反馈信息；上述异常信息日志即exp(exception)日志。

步骤s22：基于所述客户端拦截探针并根据所述目标监控日志格式，从网页框架的控制层采集与目标微服务链路的dubbo调用对应的第一日志数据。

本实施例中，通过创建的客户端拦截探针并根据上述目标监控日志格式，可以从网页框架(即springmvc)的控制层采集与上述目标微服务链路的dubbo调用对应的第一日志数据。其中，上述客户端拦截探针的本质为拦截器(即handlerinterceptor)，并且该客户端拦截探针的执行顺序为最先执行。

本实施例中，所述基于所述客户端拦截探针并根据所述目标监控日志格式，从网页框架的控制层采集与目标微服务链路的dubbo调用对应的第一日志数据，可以包括：利用所述拦截探针从服务调用请求中采集所述链路标识，并生成所述目标微服务链路的第一类被调用信息标识；利用所述拦截探针查看所述服务调用请求中是否已含有第一类被调用信息标识；如果是，则将所述服务调用请求中的第一类被调用信息标识作为所述目标微服务链路的发起调用方标识；如果否，则将所述目标微服务链路的第一类被调用信息标识对应的数据赋值给所述目标微服务链路的发起调用方标识；基于所述链路标识、所述目标微服务链路的第一类被调用信息标识和所述目标微服务链路的发起调用方标识生成所述服务端反馈日志；利用所述拦截探针采集所述服务调用请求在处理过程中的异常信息以得到所述异常信息日志，并在所述服务调用请求完成后采集所述服务端接收日志；利用所述拦截探针获取当前主机ip作为所述扩展信息以标识所述服务调用请求的入口服务器地址；基于所述服务端反馈日志、所述服务端接收日志、所述异常信息日志和所述扩展信息得到所述目标微服务链路的dubbo调用对应的第一日志数据。

可以理解的是，通过在上述拦截探针的预处理方法(即prehandle)中，查看服务调用请求的头信息中是否存在链路标识，即traceid字段，如果存在则将上述traceid字段作为上述目标微服务链路的链路标识，同时生成上述目标微服务链路的spanid；其中，上述spanid为唯一的针对上述目标微服务链路的第一类被调用信息标识。并且查看上述服务调用请求的头信息中是否存在spanid，如果存在则将上述头信息中的spanid作为上述目标微服务链路的parentspanid，如果上述头信息中不存在spanid，则将上述目标微服务链路的spanid对应的数据赋值给上述目标微服务链路的parentspanid；可以理解的是，此时的服务方为在处理用户请求时最先开始发起调用的服务。然后基于得到的上述目标微服务链路的traceid、spanid和parentspanid生成上述服务端反馈日志；并且利用上述拦截探针采集上述服务调用请求在处理过程中异常信息以得到异常信息日志。在上述服务调用请求完成后，即可以在上述拦截探针的aftercompletion方法中采集服务端接收日志。进一步利用上述拦截探针获取当前主机ip存放于上述目标监控日志格式中扩展信息的字段，以标识上述服务调用请求的入口服务器地址；最后基于上述服务端反馈日志、上述服务端接收日志、上述异常信息日志和上述扩展信息得到上述目标微服务链路的dubbo调用对应的第一日志数据。由此一来，本实施例中通过客户端拦截探针在预处理方法中打印服务端反馈日志，然后在服务调用请求完成后打印服务端接收日志，并通过采集异常信息得到异常信息日志以及采集当前主机ip得到上述扩展信息，最终得到上述目标微服务链路的dubbo调用对应的第一日志数据。

本实施例中，所述基于所述客户端拦截探针并根据所述目标监控日志格式，从网页框架的控制层采集与目标微服务链路的dubbo调用对应的第一日志数据的过程中，还包括：将所述链路标识、所述目标微服务链路的第一类被调用信息标识和所述目标微服务链路的发起调用方标识存储于与当前调用线程对应的存储结构中；在所述服务调用请求完成后清空所述存储结构中的数据。可以理解的是，将得到的上述链路标识traceid、上述目标微服务链路的第一类被调用信息标识spanid和上述目标微服务链路的发起调用方标识存储于与当前调用线程对应的存储结构中，具体的上述存储结构可以为threadlocal；并且由于springmvc的控制器(即controller)是多线程模式，存在线程复用的现象，因此在上述服务调用请求完成后，即在上述拦截探针的aftercompletion方法中清空threadlocal中的数据；其中，上述threadlocal是一个线程内部的存储类，可以在指定线程内存储数据，数据存储以后，只有指定线程可以得到存储数据。由此一来，通过将traceid和spanid存放于threadlocal中可以实现线程间数据隔离。

步骤s23：基于所述客户端过滤探针并根据所述目标监控日志格式，从客户端采集与目标微服务链路的dubbo调用对应的第二日志数据。

本实施例中，通过创建的客户端过滤探针并根据上述目标监控日志格式，从客户端采集与目标微服务链路的dubbo调用对应的第二日志数据；其中，上述过滤探针的本质为dubbo的过滤器。

本实施例中，所述基于所述客户端过滤探针并根据所述目标监控日志格式，从客户端采集与目标微服务链路的dubbo调用对应的第二日志数据，包括：利用所述客户端过滤探针从当前调用线程中采集所述时间信息、所述链路标识和所述目标微服务链路的第一类被调用信息标识，以得到所述客户端发起日志，并将所述链路标识和所述目标微服务链路的第一类被调用信息标识发送至服务端；在服务调用请求完成后利用所述客户端过滤探针采集当前时间得到所述时间信息，以得到所述客户端接收日志；基于所述客户端发起日志和所述客户端接收日志得到所述目标微服务链路的dubbo调用对应的第二日志数据。

具体的，本实施例中通过重写上述客户端过滤探针中的invoke方法，其中，上述invoke方法表示已完成服务调用响应；然后利用上述客户端过滤探针在执行invoke方法之前获取当前调用线程的traceid和spanid，并获取当前线程中的时间戳以得到上述时间信息，基于上述当前调用线程的traceid、spanid以及上述时间信息得到相应的客户端发起日志，以标识客户端发起调用之前的时间点；同时将上述当前调用线程的traceid和spanid存放至数据单元invocation中，并作为rpc请求的附加信息传递到dubbo的服务端；然后在执行invoke方法后再次获取时间戳，即采集当前时间以得到时间信息，基于得到的当前时间打印出客户端接收日志，以标识客户端完成调用的时间。由此一来，本实施例中通过重写过滤探针中的invoke方法，并在客户端引入上述过滤探针，可以实现利用上述客户端过滤探针在执行invoke方法之前采集客户端发起日志，并在执行invoke方法之后采集客户端接收日志，从而得到上述第二日志数据。

步骤s24：基于所述服务端过滤探针并根据所述目标监控日志格式，从服务端采集与目标微服务链路的dubbo调用对应的第三日志数据。

本实施例中，通过创建的服务端过滤探针并根据上述目标监控日志格式，从服务端采集与目标微服务链路的dubbo调用对应的第三日志数据。

本实施例中，所述基于所述服务端过滤探针并根据所述目标监控日志格式，从服务端采集与目标微服务链路的dubbo调用对应的第三日志数据，包括：利用所述服务端过滤探针从客户端发送的数据中采集所述时间信息，所述链路标识和所述目标微服务链路的第一类被调用信息标识，以得到所述服务端接收日志；在服务调用请求完成后利用所述服务端过滤探针采集当前时间得到所述时间信息，以得到所述服务端反馈日志，并采集服务端异常信息得到所述异常信息日志；基于所述服务端接收日志、所述服务端反馈日志和所述异常信息日志得到所述目标微服务链路的dubbo调用对应的第三日志数据。

具体的，本实施例中通过重写上述服务端过滤探针中的invoke方法，然后利用上述服务端过滤探针在执行invoke方法之前从客户端发送的调用请求的数据单元invocation中获取traceid、spanid和时间信息得到服务端接收日志，以标识服务端收到请求的时间点；然后在执行invoke方法后再次获取时间戳，即采集当前时间以得到时间信息，基于得到的当前时间打印出服务端反馈日志，以标识服务端完成请求并向客户端发送响应的时间点；同时利用服务端拦截探针获取服务端的异常信息以得到异常信息日志。基于上述服务端接收日志、上述服务端反馈日志和上述异常信息日志得到上述目标微服务链路的dubbo调用对应的第三日志数据。由此一来，本实施例中通过重写过滤探针中的invoke方法，并在服务端引入上述过滤探针，可以实现利用上述服务端过滤探针在执行invoke方法之前采集服务端接收日志，并在执行invoke方法之后采集服务端反馈日志，从而得到上述第三日志数据。

步骤s25：利用第一fluentd插件并基于所述监控日志标识从所述客户端拦截探针获取所述第一日志数据以及从所述客户端过滤探针获取所述第二日志数据，并将所述第一日志数据和所述第二日志数据发送至搜索服务器elasticsearch。

本实施例中，利用预先在客户端安装的第一fluentd插件并通过识别监控日志标识从客户端拦截探针获取第一日志数据，并从客户端过滤探针获取第二日志数据，然后利用上述第一fluentd插件将所述第一日志数据和所述第二日志数据发送至搜索服务器elasticsearch。上述fluentd插件为一个开源的数据收集器，它允许用户统一数据收集和消耗，以便更好地使用和理解数据。fluentd从各种数据源收集事件，将其写入文件、rdbms、nosql、iaas、saas和hadoop等。上述elasticsearch是一个基于lucene的搜索服务器，它提供一个分布式多用户能力的基于restfulweb接口的全文搜索引擎。

步骤s26：利用第二fluentd插件并基于所述监控日志标识从所述服务端过滤探针获取所述第三日志数据，并将所述第三日志数据发送至所述搜索服务器elasticsearch。

本实施例中，利用预先在服务端安装的第二fluentd插件并通过识别监控日志标识从服务端过滤探针获取第三日志数据，然后利用上述第二fluentd插件将所述第三日志数据发送至搜索服务器elasticsearch。由此一来，通过识别创建的目标监控日志格式中的监控日志标识，可以准确高效的采集到相应的日志数据。

其中，关于上述步骤s21的具体过程可以参考前述实施例公开的相应内容，在此不再进行赘述。

由上可见，本实施例通过创建的客户端拦截探针并根据所述目标监控日志格式，从网页框架的控制层采集与目标微服务链路的dubbo调用对应的第一日志数据；通过创建的客户端过滤探针并根据所述目标监控日志格式，从客户端采集与目标微服务链路的dubbo调用对应的第二日志数据；通过创建的服务端过滤探针并根据所述目标监控日志格式，从服务端采集与目标微服务链路的dubbo调用对应的第三日志数据；最后利用预先安装的第一fluentd插件将上述第一日志数据和上述第二日志数据发送至搜索服务器elasticsearch，以及利用预先安装的第二fluentd插件将上述第三日志数据发送至搜索服务器elasticsearch。通过这种方式可以在客户端和服务端采集到相应的日志数据，然后利用fluentd插件将日志数据发送至搜索服务器elasticsearch，由此提高了日志获取的全面性，进而提高了系统故障位置和性能瓶颈位置定位的能力。

如图3所示，以单次服务之间的调用为例对本申请进行说明。本申请主要应用于spring+dubbo的微服务应用场景下，不同服务之间采用dubbo的方式相互调用，通过采集每一次请求的全处理过程中涉及到的服务之间的调用关系、调用次数、响应时间等数据，并以图形化的形式展示每一次请求的处理链路，最终实现对微服务链路的监控和分析。本实施例中，在客户端引入客户端拦截探针(即inteceptor)并将上述客户端拦截探针设置为优先执行；在发起dubbo调用的服务中引入过滤探针(即dubbofilter)得到客户端过滤探针，在响应dubbo调用的服务中引入过滤探针(即dubbofilter)得到服务端过滤探针，并在dubbo的配置文件中指定使用上述客户端过滤探针和上述服务端过滤探针，并将上述客户端过滤探针和上述服务端过滤探针设置为优先执行。同时可以由用户自定义目标监控日志的格式，上述目标监控日志的格式可以包括监控日志标识、时间信息、日志类型、链路标识、第一类被调用信息标识、发起调用方标识、第二类被调用信息标识以及扩展信息。然后在所有的服务器上安装fluentd插件，并修改fluentd配置文件中的路径(即path)为当前服务器上需要采集的日志目录，同时修改配置文件中的过滤规则，只采集以上述监控日志标识开头的日志；配置异步多线程采集方式，修改配置文件中的输出(即output)为es(即elasticsearch)数据库；最后部署链路追踪展示工具(例如图3中webiu(即网页界面))连接上述es数据库以展示目标微服务链路的追踪数据。

当客户端接收到服务调用请求，由客户端拦截探针从网页框架的控制层采集与目标微服务链路对应的第一日志数据，由客户端过滤探针从客户端采集目标微服务链路相应的第二日志数据，然后由客户端安装的fluentd插件获取上述第一日志数据和第二日志数据并发送至elasticsearch；客户端接收到服务调用请求后调用服务端，由服务端过滤探针从服务端采集目标微服务链路相应的第三日志数据，然后由服务端安装的fluentd插件获取上述第三日志数据发送至elasticsearch；最后由webiu展示目标微服务链路的追踪数据。本申请实现了基于dubbo的微服务架构链路监控数据采集和展示，减少了对业务系统的侵入，保持了对使用方的透明性，减少了开发人员的负担，降低了接入门槛和难度，日志采集数据方式尽可能的降低了对性能的损耗。同时几乎可以实时展示目标微服务链路的监控数据，监控数据可以包括链路的总耗时、每个服务的耗时以及服务调用关系拓扑等相关指标，帮助相关人员理解系统行为，为流程、架构、代码优化，以及扩容缩容、服务限流降级提供正确客观的数据参考。

相应的，本实施例还公开了一种微服务链路监控装置，参见图4所示，该装置包括：

创建模块11，用于创建目标探针和目标监控日志格式；

日志获取模块12，用于基于所述目标探针并根据所述目标监控日志格式，采集与目标微服务链路的dubbo调用对应的日志数据；

日志发送模块13，用于通过数据收集器从所述目标探针获取所述日志数据并将所述日志数据发送至搜索服务器，以便所述搜索服务器对所述目标微服务链路进行监控和分析。

由上可见，本实施例中通过创建目标探针，利用所述目标探针并根据目标监控日志格式采集与目标微服务链路对应的日志数据，然后由数据收集器将所述日志数据发送至搜索服务器，并由搜索服务器对所述目标微服务链路进行监控和分析，相比于现有技术中通过编写代码的方式，通过创建的探针获取相应的日志数据减少了对业务系统的侵入，同时减少开发人员的负担，通过这种方式，可以自动采集并分析日志，提高了系统故障位置和性能瓶颈位置定位的速度。

在一些实施例中，所述日志获取模块12具体可以包括：

第一日志获取单元，用于基于所述客户端拦截探针并根据所述目标监控日志格式，从网页框架的控制层采集与目标微服务链路的dubbo调用对应的第一日志数据；

第二日志获取单元，用于基于所述客户端过滤探针并根据所述目标监控日志格式，从客户端采集与目标微服务链路的dubbo调用对应的第二日志数据；

第三日志获取单元，用于基于所述服务端过滤探针并根据所述目标监控日志格式，从服务端采集与目标微服务链路的dubbo调用对应的第三日志数据。

在一些实施例中，所述日志发送模块13具体可以包括：

第一日志发送单元，用于利用第一fluentd插件并基于所述监控日志标识从所述拦截探针获取所述第一日志数据以及从所述客户端过滤探针获取所述第二日志数据，并将所述第一日志数据和所述第二日志数据发送至搜索服务器elasticsearch；

第二日志发送单元，用于利用第二fluentd插件并基于所述监控日志标识从所述服务端过滤探针获取所述第三日志数据，并将所述第三日志数据发送至所述搜索服务器elasticsearch。

进一步的，本申请实施例还公开了一种电子设备，参见图5所示，图中的内容不能被认为是对本申请的使用范围的任何限制。

图5为本申请实施例提供的一种电子设备20的结构示意图。该电子设备20，具体可以包括：至少一个处理器21、至少一个存储器22、电源23、通信接口24、输入输出接口25和通信总线26。其中，所述存储器22用于存储计算机程序，所述计算机程序由所述处理器21加载并执行，以实现前述任一实施例公开的链路监控方法中的相关步骤。

本实施例中，电源23用于为电子设备20上的各硬件设备提供工作电压；通信接口24能够为电子设备20创建与外界设备之间的数据传输通道，其所遵循的通信协议是能够适用于本申请技术方案的任意通信协议，在此不对其进行具体限定；输入输出接口25，用于获取外界输入数据或向外界输出数据，其具体的接口类型可以根据具体应用需要进行选取，在此不进行具体限定。

另外，存储器22作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，其上所存储的资源包括操作系统221、计算机程序222及包括日志数据在内的数据223等，存储方式可以是短暂存储或者永久存储。

其中，操作系统221用于管理与控制电子设备20上的各硬件设备以及计算机程序222，以实现处理器21对存储器22中海量数据223的运算与处理，其可以是windowsserver、netware、unix、linux等。计算机程序222除了包括能够用于完成前述任一实施例公开的由电子设备20执行的链路监控方法的计算机程序之外，还可以进一步包括能够用于完成其他特定工作的计算机程序。数据223可以包括电子设备20获取到的日志数据。

进一步的，本申请实施例还公开了一种计算机存储介质，所述计算机存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器加载并执行时，实现前述任一实施例公开的链路监控方法步骤。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本发明所提供的一种微服务链路监控方法、装置、设备及介质进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。