CN109992454A - 故障定位的方法、装置和存储介质 - Google Patents

Abstract

本发明公开了一种的故障定位的方法、装置和存储介质。该方法包括：响应于故障定位的请求，在Blackcat架构下，通过故障链路代理Agent将故障监测代码注入待监测链路中的业务应用内；接收注入了故障监测代码的业务应用所上报的监测数据；分析监测数据，得到故障定位结果。上述发明实施例基于Blackcat架构，可以实现故障监控的运维代码与应用业务代码的解耦，从而实现零侵入式运维，提高了应用业务的安全性；通过对注入了故障监测代码的业务应用所上报的监测数据分析，可以得到的监测数据，进行得到故障定位结果，可以实现快速、准确故障定位。

Description

故障定位的方法、装置和存储介质

技术领域

本发明涉及网络通信的技术领域，尤其涉及一种故障定位的方法、装置和存储介质。

背景技术

随着网络通信的快速发展，越来越多用户通过网络为其提供服务。例如，移动电子渠道(如网上营业厅、掌上营业厅(WAP营业厅)、短信营业厅等渠道)可以为客户提供缴费、查询、产品变更等服务功能。网络通信为用户带来方便的同时，也会出现故障。

移动电渠所用的故障定位方式是通过对应用日志进行分析的行业通行技术。当现有网络链路中的***、模块等发生问题时，因采用传统日志分析的技术方式，运维技术要求高、运维人员监控工作量巨大，无法快速定位故障来源。

另外，因现有故障定位技术需预先在应用程序中添加故障检测代码，否则无法完成故障定位。这使得整个故障定位与处理过程耗时较长，对于用户体验和电子渠道业务存在一定影响。此外，因现有故障定位方式运维代码需要与应用业务代码耦合在一起，存在业务安全隐患。

如何将运维代码与应用业务代码进行解耦，实现快速、准确故障定位，成为亟待解决的技术问题。

发明内容

为了解决运维代码与应用业务代码耦合，利用代码命令符的方式采集分散日志，故障定位繁琐、缓慢且不安全的问题，本发明实施例提供了一种故障定位的方法、装置和存储介质。

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

响应于故障定位的请求，在Blackcat架构下，通过故障链路代理Agent 将故障监测代码注入待监测链路中的业务应用内；

接收注入了故障监测代码的业务应用所上报的监测数据；

分析监测数据，得到故障定位结果。

第二方面，提供了一种故障定位的装置。该装置包括：

代码注入单元，用于响应于故障定位的请求，通过故障链路代理 Agent将故障监测代码注入待监测链路中的业务应用内；

数据接收单元，用于接收注入了故障监测代码的业务应用所上报的监测数据；

数据分析单元，用于分析监测数据，得到故障定位结果。

第三方面，提供了一种故障定位的装置。该装置包括：

存储器，用于存放程序；

处理器，用于执行所述存储器存储的程序，所述程序使得所述处理器执行上述各方面所述的方法。

第四方面，提供了一种计算机可读存储介质。该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面所述的方法。

第五方面，提供了一种包含指令的计算机程序产品。当该产品在计算机上运行时，使得计算机执行上述各方面所述的方法。

第六方面，提供了一种计算机程序。当该计算机程序在计算机上运行时，使得计算机执行上述各方面所述的方法。

一方面，上述发明实施例基于Blackcat架构，可以实现故障监控的运维代码与应用业务代码的解耦，从而实现零侵入式运维，提高了应用业务的安全性。

另一方面，上述发明实施例通过对注入了故障监测代码的业务应用所上报的监测数据分析，可以得到的监测数据，进行得到故障定位结果，可以实现快速、准确故障定位。

附图说明

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

图1是本发明一实施例的故障定位方法的流程示意图；

图2是本发明一实施例的BlackCat***架构示意图；

图3是本发明一实施例的链路全文检索界面示意图；

图4是本发明一实施例的一种故障定位的装置的结构示意图；

图5是本发明一种故障定位的装置的框架示意图；

图6是本发明一实施例的故障链路代理针对HttpWebService类的RPCInvoke函数添加代码的示意图。

具体实施方式

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

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

图1是本发明一实施例的故障定位的方法的流程示意图。

如图1所示，故障定位的方法可以包括以下步骤：

S110，响应于故障定位的请求，在Blackcat架构下，通过故障链路代理Agent将故障监测代码注入待监测链路中的业务应用内；

S120，接收注入了故障监测代码的业务应用所上报的监测数据；

S130，分析监测数据，得到故障定位结果。

Blackcat架构是一种新型网络架构。该架构无需像JAVA SPRING等技术框架方式需把SPRING等技术框架修改的代码放在应用程序包中，该架构可以实现故障监控的运维代码与应用业务代码的解耦，是实现零侵入式运维的基础。此部分内容将在下文继续描述。

在一些实施例中，可以先由Java agent植入应用程序，发送数据到链路数据采集器，并写入Hbase；然后由链路数据分析器分析链路数据(如监测数据)并交给数据转换器，或直接对链路数据进行告警判断，得到故障定位结果并对该结果进行展示。另外，也可以通过Blackcat web和 Dashboard从Hbase、数据归档处查询故障定位的结果数据。

在一些实施例中，可以先由Agent采集数据，将采集到的数据发送到数据转换器，然后数据转换器对数据进行转换、写入Hbase、归档等处理；再输出告警、通知等故障定位结果。

在一些实施例中，上述操作的执行主体可以是基于BlackCat架构的全链路故障定位跟踪***、装置或者设备等。

一方面，上述发明实施例基于Blackcat架构，可以实现故障监控的运维代码与应用业务代码的解耦，从而实现零侵入式运维，提高了应用业务的安全性。

另一方面，上述发明实施例通过对注入了故障监测代码的业务应用所上报的监测数据分析，可以得到的监测数据，进行得到故障定位结果，可以实现快速、准确故障定位。

图2是本发明一实施例的BlackCat***架构示意图。

如图2所示，图1中的BlackCat***架构300可以包括：日志采集模块301、数据收集模块302、消息中间件模块303、数据入库模块304、数据分析模块305和数据展示模块306。

BlackCat***架构300可以采集主机A(HOST-A)100和主机B (HOST-B)200的故障数据，并对故障数据进行分析，定位出故障点。

BlackCat架构可以是面向分布式***的全链路监控追踪的***架构。 BlackCat架构可以用于对应用集群的分布式调用情况和服务性能进行监控，对负载分布情况的分析***、以及中间件等进行监控分析。该架构可以支持***性能采集、分析、数据展示，也可以支持中间件服务性能采集分析及数据展示、服务调用性能采集分析及数据展示等操作。

基于BlackCat架构的全链路故障定位跟踪***可以帮助分析***行为、分析***的性能问题，快速排查前端响应过慢或报错的原因，实现调用路径、去向、来源的综合分析等，快速定位出网络链路中的各种***故障，可以实现对全局故障的全链路的实时监控定位与管理，例如对江西移动电渠***的稳定性和性能提供优分析、故障定位等处理。

可以理解，上述BlackCat的***架构中的各个模块可以根据实际运行场景进行灵活调整。例如，BlackCat的***架构可以包括日志采集端、数据收集服务端，消息中间件以及数据入库和分析等模块。

在一些实施例中，故障定位的方法可以基于Java字节码增强技术，将故障监测代码自动注入待监测链路中的业务应用内。

在一些实施例中，故障定位的方法可以将故障监测代码注入待监测链路中的业务应用内可以包括如下步骤：启动业务应用的应用程序；通过增加***的方法，将故障监测代码自动注入应用程序内。

在一些实施例中，可以启动业务应用的应用程序；通过增加***的方法，将故障监测代码自动注入应用程序内。

在一些实施例中，故障定位的方法通过增加***的方法，将故障监测代码自动注入应用程序内，包括：获取应用程序的HttpWebServer类的 RPCInvoke函数；向PRCInoke函数增加Interceptor.before()字节码和 Interceptor.after()字节码。

在一些实施例中，故障链路代理Agent可以采用Java字节码技术实现目标应用程序包的故障日志自动化注入，无需应用开发人员编写相关代码，从而对应用程序和故障链路程序进行解耦。

在一些实施例中，在全链路监控方法、装置或者***中采用此技术的目的可以是：解耦应用程序代码和故障检测链路程序代码，做到无需在应用程序中添加故障检测代码，从而实现链路故障检测代码对应用程序代码的零侵入。

在一些实施例中，Java字节码增强技术指的是在应用Java字节码生成之后，Agent对其进行修改添加相关代码段，增强其功能，这种方式相当于对应用程序的二进制文件进行修改。Java字节码增强的应用目的可以是减少冗余代码，对开发人员屏蔽底层的实现细节。

在一些实施例中，利用Agent直接修改目标类的字节码，当JVM加载HttpWebService JAVA类的字节码时，Agent可以针对HttpWebService类的 RPCInvoke函数进行字节码修改，例如，添加Interceptor.before()和 Interceptor.after()节码。Interceptor的before和after函数可以实现故障检测。具体添加代码的方式可以如图6所示。

在一些实施例中，通过抽象出***Interceptor，在类装载时通过介入应用代码为分布式事务和故障信息注入必要的跟踪代码。***可以在故障数据被记录的地方注入。为了跟踪，可以通过添加***的before() 函数和after()函数，并在before()函数和after()函数中实现了部分故障数据的记录。使用字节码增强技术，Agent可以记录需要拦截的数据。

在一些实施例中，故障链路代理Agent实现日志自动化注入的实现方式可以包括：

S1，启动虚拟机(Virtual Machine，VM)和PinPoint Agent；

S2，Agent加载插件(可以调用的插件)；

S3，Agent调用ProfilePlugin.setup方法，对需转换的类进行定义并为其注册TransformerCallback；

S4，启动目标应用程序(如某服务应用的应用程序)；

S5，Agent通过增加***等方法修改目标类的字节码；

S6，将修改后的字节码返回给Java虚拟机(Java Virtual Machine， JVM)，并重新加载目标类；

S7，继续执行应用程序；

S8，调用***的before()和after()方法追踪性能数据；

S9，***记录待追踪的故障数据。

图3是本发明一实施例的链路全文检索界面示意图。

如图3所示，该链路全文检索界面可以包括：选择应用区域、检索条件区域、处理状态区域、选择时间段区域、查看链路详情区域以及加载更多的自动滚屏区域等。

在本实施例中，可以通过链路全文检索的方法对故障进行定位，还可以通过图形化技术实现可视化运维。链路全文检索和图形化技术的应用，可以帮助运维人员在使用全链路故障检测***时快速有效的发现、查找相关问题，并且直观地从不同角度查看问题详情。

通过链路全文检索的方法可以从多种维度实时检索服务链路数据。多种维度可以包括：应用/主机/服务地址/请求参数/时间(秒/分钟/小时/天) 等维度。

链路全文检索可以是异常服务检索，具体可以实时检索给定时间段内异常服务数据。

在一些实施例中，该方法还可以包括：故障监测代码用于对链路的全文进行检索，以得到监测数据。

在一些实施例中，该方法还可以包括：对故障检测插件平台中的插件进行如下操作中的一种或者多种：增加、删除、修改。

在一些实施例中，故障定位的方法还可以包括：基于BlackCat架构的图形化技术，在操作界面上显示和/或播放故障定位结果。

在一些实施例中，可以用图形化操作界面展示故障定位结果。例如，可以采用Blackcat架构的图形化技术技术，实现有数据就有监控视图，根据监控数据或者自定义数据源。经过大量的实验数据表明，自建不同角度的Dashboard使用全链路故障定位跟踪***之后，运维人力从之前的6个减少至4个，运维效率提升30％。

在一些实施例中，该方法还可以包括：在Agent中搭建故障日志插件平台，对如下故障日志插件中的一个或者多个进行统一管理：spring框架故障日志插件、dubbo框架故障日志插件、webService框架故障日志插件、 HTTPClient框架故障日志插件、BES框架故障日志插件、mysql框架故障日志插件、oracle框架故障日志插件、mybatis框架故障日志插件、redis缓存框架故障日志插件、KAFKA框架故障日志插件、ActiveMQ框架故障日志插件。

在一些实施例中，故障检测插件平台可以实现高扩展。例如，在故障检测链路代理Agent中搭建故障检测插件平台，可以做到故障检测插件统一管理，实现全链路监控***的高扩展性。

在一些实施例中，故障检测插件平台可以支持spring、dubbo、webService、HTTPClient、BES、mysql、oracle、mybatis、redis缓存、 KAFKA和ActiveMQ等多种技术框架的故障检测插件，从而可以实现全局自动化添加故障检测插件。例如，当有新的技术框架或者需要修改原来的技术框架，都只需要在此插件平台新增插件或者修改插件，因此，故障检测插件平台扩展性非常强。

在一些实施例中，以针对dubbo中心化架构故障检测插件为例：只需按照故障检测链路代理Agent插件平台规范新建一个故障检测插件，如： DubboPlugin插件。继承相关插件平台***继承类，并指明需修改Dubbo中心化架构中的JAVA类：com.alibaba.dubbo.rpc.cluster.support.Abstract ClusterInvoker类。当JVM虚拟机加载到该类文件时将回调到该插件中，通过doInTransform方法实现该类中的invoke函数字节码修改，该函数可以实现dubbo的远程调用，在函数中加入DubboConsumerInterceptor***，在***中实现远程调用故障检测生成代码的注入，完成dubbo中心化调用的耗时统计。

需要说明的是，在不冲突的情况下，本领域的技术人员可以按实际需要将上述的操作步骤的顺序进行灵活调整，或者将上述步骤进行灵活组合等操作。为了简明，不再赘述各种实现方式。另外，各实施例的内容可以相互参考引用。

上述发明实施例可以基于BlackCat架构，通过故障链路代理Agent采用Java字节码技术实现目标应用程序包的故障日志自动化注入，并在故障链路代理Agent中搭建故障日志插件平台，做到故障日志插件统一管理，最终实现故障定位的可视化全链路跟踪。

上述发明实施例采用Blackcat架构可以统一替换原有JAVA SPRING等技术框架，通过故障链路代理Agent技术实现全链路监控，并通过图形化交互界面替换原有代码命令符分散检索日志的繁琐故障定位方式，具体实现了以下技术效果：

1、基于Blackcat架构，该架构无需像JAVA SPRING等技术框架方式需把SPRING等技术框架修改的代码放在应用程序包中，是实现故障监控的运维代码与应用业务代码的解耦，实现零侵入式运维的基础。

2、故障链路代理Agent采用Java字节码增强技术实现目标应用程序包的故障检测自动化注入，无需应用开发人员编写一行相关代码，极大减少工作量和全链路故障检测***的上线周期。

3、应用程序开发人员可以专心开发应用程序提升应用开发效率，应用程序和故障全链路***程序上物理隔离，应用和运维开发人员同样做到解耦。

4、实现链路全文检索和图形化故障呈现及图形化操作界面，实现运维监控的可视化便捷操作；

5、构建故障检测插件平台，做到故障检测插件统一管理，实现高扩展。故障检测插件平台目前支持spring、dubbo、webService、HTTPClient、 BES、mysql、oracle、mybatis、redis缓存、KAFKA和ActiveMQ等多种技术框架的故障检测插件，实现全局自动化添加故障检测。如有新的技术框架或需修改原来的技术框架，都只需要在此插件平台新增插件或者修改插件，扩展性强。

图4是本发明一实施例的一种故障定位的装置的结构示意图。

如图4所示，故障定位的装置400可以包括：代码注入单元401、数据接收单元402和数据分析单元403。其中，代码注入单元401可以用于响应于故障定位的请求，通过故障链路代理Agent将故障监测代码注入待监测链路中的业务应用内；数据接收单元402可以用于接收注入了故障监测代码的业务应用所上报的监测数据；数据分析单元403可以用于分析监测数据，得到故障定位结果。

在一些实施例中，代码注入单元401可以基于Java字节码增强技术，将故障监测代码自动注入待监测链路中的业务应用内。

在一些实施例中，代码注入单元401可以启动业务应用的应用程序；通过增加***的方法，将故障监测代码自动注入应用程序内。

在一些实施例中，代码注入单元401可以获取应用程序的 HttpWebServer类的RPCInvoke函数；向PRCInoke函数增加 Interceptor.before()字节码和Interceptor.after()字节码。

在一些实施例中，故障监测代码可以用于对链路的全文进行检索，以得到监测数据。

在一些实施例中，故障定位的装置400还可以包括：显示单元。显示单元可以基于BlackCat架构的图形化技术，在操作界面上显示和/或播放故障定位结果。

在一些实施例中，故障定位的装置400还可以包括：平台单元。该平台单元可以用于在Agent中搭建故障日志插件平台，对如下故障日志插件中的一个或者多个进行统一管理：spring框架故障日志插件、dubbo框架故障日志插件、webService框架故障日志插件、HTTPClient框架故障日志插件、BES框架故障日志插件、mysql框架故障日志插件、oracle框架故障日志插件、mybatis框架故障日志插件、redis缓存框架故障日志插件、 KAFKA框架故障日志插件、ActiveMQ框架故障日志插件。

在一些实施例中，故障定位的装置400还可以包括：插件操作单元。插件操作单元可以用于对故障检测插件平台中的插件进行如下操作中的一种或者多种：增加、删除、修改。

需要说明的是，上述各实施例的装置可作为上述各实施例的用于各实施例的方法中的执行主体，可以实现各个方法中的相应流程，实现相同的技术效果，为了简洁，此方面内容不再赘述。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。例如，将加密/解密单元集成在一个单元中，也可以分为两个单独的单元。又例如将请求接收单元和请求发送单元用一个传输接口替代。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令，当其在计算机上运行时，使得计算机执行上述各个实施例中描述的方法。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线 (例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

图5是本发明一种故障定位的装置的框架示意图。

如图5所示，该框架可以包括中央处理单元(CPU)501，其可以根据存储在只读存储器(ROM)502中的程序或者从存储部分508加载到随机访问存储器(RAM)503中的程序而执行图1中各个实施例所做的各种操作。在RAM503中，还存储有***架构操作所需的各种程序和数据。CPU 501、ROM 502以及RAM 503通过总线504彼此相连。输入/输出(I/O) 接口505也连接至总线504。

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

特别地，根据本发明的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明的实施例包括一种计算机程序产品，其包括有形地包含在机器可读介质上的计算机程序，所述计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分509从网络上被下载和安装，和/或从可拆卸介质511 被安装。

在一些实施例中，电子渠道通过故障检测代码独立于业务代码运行，不再像传统日志分析故障检测一样在业务代码中写入故障检测代码，实现故障检测与业务运行松耦合，同时不对业务代码造成任何影响，实现零侵入以及图形化的操作界面和故障呈现，直接将网上故障定位到对应的代码上。

由此，上述实施例可以实现如下效果：

1、业务代码零侵入：故障检测链路采用松耦合与零侵入业务代码的方式，极大减少工作量和故障全链路监控***的上线周期。 2、图形化故障运维：解耦应用程序和故障检测链路程序，链路全文检索和图形化故障呈现及操作界面。

3、插件平台高扩展：搭建故障检测插件平台，做到故障检测插件统一管理，实现高扩展。

上述发明实施例能够有效地改变电渠***运维工作中，代码命令符方式分散日志检索进行繁琐故障定位，实现可视化操作快捷故障定位；同时实现故障检索代码与业务应用代码的解耦，零侵入方式运维，大幅提升运维效能、降低业务风险。

上述发明实施例可以极大地提高运维效率，方便运维人员快速准确地发现为、定位问题和解决问题，既保障了在网业务的安全运行，维护了用户的使用体验，同时又降低了维护成本，提升了工作效率，有利于电子渠道业务的发展。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等) 执行各个实施例或者实施例的某些部分所述的方法。

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

Claims (11)

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

响应于故障定位的请求，在Blackcat架构下，通过故障链路代理Agent将故障监测代码注入待监测链路中的业务应用内；

接收注入了所述故障监测代码的所述业务应用所上报的监测数据；

分析所述监测数据，得到故障定位结果。

2.根据权利要求1所述的方法，其特征在于，将故障监测代码注入待监测链路中的业务应用内，包括：

基于Java字节码增强技术，将所述故障监测代码自动注入待监测链路中的所述业务应用内。

3.根据权利要求1所述的方法，其特征在于，基于Java字节码增强技术，将所述故障监测代码自动注入待监测链路中的所述业务应用内，包括：

启动所述业务应用的应用程序；

通过增加***的方法，将所述故障监测代码自动注入所述应用程序内。

4.根据权利要求3所述的方法，其特征在于，通过增加***的方法，将所述故障监测代码自动注入所述应用程序内，包括：

获取所述应用程序的HttpWebServer类的RPCInvoke函数；

向PRCInoke函数增加Interceptor.before()字节码和Interceptor.after()字节码。

5.根据权利要求1所述的方法，其特征在于，还包括：

所述故障监测代码用于对所述链路的全文进行检索，以得到所述监测数据。

6.根据权利要求1所述的方法，其特征在于，还包括：

基于BlackCat架构的图形化技术，在操作界面上显示和/或播放所述故障定位结果。

7.根据权利要求1-6中任一项所述的方法，其特征在于，还包括：

在Agent中搭建故障日志插件平台，对如下故障日志插件中的一个或者多个进行统一管理：spring框架故障日志插件、dubbo框架故障日志插件、webService框架故障日志插件、HTTPClient框架故障日志插件、BES框架故障日志插件、mysql框架故障日志插件、oracle框架故障日志插件、mybatis框架故障日志插件、redis缓存框架故障日志插件、KAFKA框架故障日志插件、ActiveMQ框架故障日志插件。

8.根据权利要求7所述的方法，其特征在于，还包括：

对所述故障检测插件平台中的插件进行如下操作中的一种或者多种：增加、删除、修改。

9.一种故障定位的装置，其特征在于，包括：

代码注入单元，用于响应于故障定位的请求，在Blackcat架构下，通过故障链路代理Agent将故障监测代码注入待监测链路中的业务应用内；

数据接收单元，用于接收注入了所述故障监测代码的业务应用所上报的监测数据；

数据分析单元，用于分析所述监测数据，得到故障定位结果。

10.一种故障定位的装置，其特征在于，包括：

存储器，用于存放程序；

处理器，用于执行所述存储器存储的程序，所述程序使得所述处理器执行如权利要求1-8中任意一项所述的方法。

11.一种计算机可读存储介质，其特征在于，其上存储有计算机程序指令，其特征在于，当所述计算机程序指令被处理器执行时实现如权利要求1-9中任一项所述的方法。