一种基于执行轨迹追踪的分布式软件异常诊断方法

摘要

本发明涉及一种基于执行轨迹追踪的分布式软件异常诊断方法。通过跨服务组件的执行轨迹监测及约简方法对执行轨迹进行刻画，从系统错误和性能异常两方面进行异常诊断。在系统错误诊断方面，利用树编辑距离来评估当前执行轨迹的异常程度，通过对比分析与历史执行轨迹的差异，定位发生错误的函数调用。在检测性能异常方面，利用主成分分析定位引起性能异常的函数调用。

权利要求

1.一种基于执行轨迹追踪的分布式软件异常诊断方法，其特征在于包括以下步骤：第一步：执行轨迹监测：利用动态插桩的方式，在分布式软件的函数调用处插入监测代码，收集该函数的执行信息，执行信息包括该函数唯一标识、处理时间、服务组件唯一标识和远程调用协议中加入的该函数调用关系；根据以上函数的执行信息利用调用树描述函数的执行序列，即执行轨迹；

第二步：在覆盖测试阶段对分布式软件进行监测，以构建执行轨迹的集合，上述执行轨迹的集合构建过程如下：针对当前的执行轨迹，通过宽度优先搜索的树匹配算法与上述执行轨迹的集合中已有的执行轨迹进行匹配；如果匹配成功，则继续下一个执行轨迹的匹配；如果匹配失败，则在上述执行轨迹的集合中新增当前的执行轨迹；

第三步：将第二步建立的执行轨迹集合作为检测分布式软件的故障的基准，通过比较与分析监测得到的当前执行轨迹与上述执行轨迹集合中的执行轨迹，以定位分布式软件故障的原因；

将分布式软件的故障分为系统错误故障和性能异常故障两类，针对系统错误故障和性能异常故障这两类故障分别提出相应的异常诊断方法，实现了函数粒度的故障定位。

2.根据权利要求1所述的基于执行轨迹追踪的分布式软件异常诊断方法，其特征在于：所述第三步中，具体实现如下：

(1)在系统错误诊断方面

利用树编辑距离来评估执行轨迹的异常程度，通过对比分析历史执行轨迹的差异，定位发生错误的函数调用；

树编辑距离为：

其中，Ti为监测得到的当前第i个执行轨迹；Cj为执行轨迹集合中的第j个基准执行轨迹；V(Ti)和V(Cj)分别为Ti和Cj中函数的数量；δ(Ti，Cj)为Ti和Cj的编辑距离；

Ti的异常程度AD：

AD＝1-max(Sim(Ti,Cj))；

如果AD大于预置的阀值γ，则表示该执行轨迹发生了错误；

利用宽度优先搜索比较Ti和Cj的轨迹差别，能够定位到错误出现在分布式软件的具体函数；

(2)在性能异常诊断方面

执行轨迹是由函数调用的序列组成，在确定出现性能异常的执行轨迹后，利用主成分分析提取引起性能异常的函数调用，如果当前执行轨迹的执行时间出现大幅度波动，则当前执行轨迹出现性能异常，利用变异系数来衡量执行轨迹的执行时间的波动程度：其中：

其中，xi为第i个执行轨迹的执行时间；μ为该执行轨迹的执行时间的平均值；σ为该执行轨迹的执行时间的标准差；CV为执行轨迹的执行时间的标准差与均值的比值，表明分布式软件的执行轨迹的执行时间波动幅度；

所述利用主成分分析定位造成执行轨迹性能异常的函数调用的过程如下：建立线性组合，如下式：

pi＝ai1t1+…+aijtj+…+aintn

其中，pi表示主成分i；变量tj表示执行轨迹中的第j个函数的执行时间；aij表示主成分pi对于tj的系数；n为该执行轨迹中函数的个数；

利用主成分分析计算得到k个主成分为p1，p2，..，pk，其对应的特征值为λ1，λ2，...，λk，k

说明书

一种基于执行轨迹追踪的分布式软件异常诊断方法

技术领域

[0001] 本发明涉及分布式软件的异常诊断方法，尤其涉及一种基于执行轨迹追踪的分布式软件异常检测与故障定位方法，属于软件技术领域。

背景技术

[0002] 云计算环境下，分布式软件的动态性和复杂性不断增加，传统的软件架构已经难以适应用户需求的快速变化。分布式软件架构旨在设计与开发可维护性和可扩展的软件，将复杂的软件系统拆分成功能单一，可独立开发部署的模块，通过轻量级通信机制使得这些模块协同配合，从而形成一种高内聚低耦合的分布式软件。但是，分布式软件的模块众多，依赖关系复杂，大大增加了故障发生的概率和诊断的难度。特别是，当其中一个分布式软件模块出现故障时，故障的影响会随着模块间的相互调用不断扩散，最终导致整个服务失效或违约。因此有效检测分布式软件故障，并准确定位问题原因是保障分布式软件性能与可靠性的关键技术之一。

[0003] 引发分布式软件故障的原因有很多，比如软件设计缺陷、代码问题、配置错误。故障会导致系统行为异常，表现为请求失败、响应延时等。当前的分布式软件异常诊断方法可以分为基于规则和异常检测等两类。基于规则的方法根据历史故障所表现的现象来定义故障出现时可辨别的特征，而后将观察到的现象与已定义的故障特征进行匹配。当匹配成功则检测为故障，发出警报；否则认为软件运行正常(Chen H，Jiang G，Yoshihira K，Saxena A.Invariants based failure diagnosis in distributed computing systems//Proceedings of the 29th IEEE Symposium on Reliable Distributed Systems.India，2010：160-166)。基于规则的方法由于事先已知故障及其表现，具有较高的准确性和及时性。然而，当此前未曾出现该故障，或者该故障的表现难以刻画，基于规则的方法就不能够准确识别。

[0004] 另一方面，基于异常检测的方法为目标系统建立模型作为基准，将系统行为与基准进行对比。根据软件监测分析对象的不同，基于异常检测的方法可以分为度量分析和日志分析等方法。度量分析方法通过调用操作系统提供的接口收集监测数据，将当前监测数据与历史监测数据进行对比分析。(Wang T，Zhang W，Wei.J，Zhong H.Workload-aware online anomaly detection in enterprise applications with local outlier factor//Proceedings of  the IEEE 36th Annual Computer Software and Applications Conference.Izmir，Turkey，2012：25-34.)。该方法无需事先知道错误类型并描述其特征，但由于云计算环境具有动态性与复杂性，建立具有鲁棒性和普适性的基准相当困难。基于日志分析的方法，通过分析日志信息可以推断出分布式软件的部分执行路径，进而分析软件是否正确执行(Fu Q，Lou JG，Wang Y，Li J.Execution anomaly detection in distributed systems through unstructured log analysis//
Proceedings of the 9th IEEE International Conference on Data Mining.Miami，FL，
2009：149-158.)。该方法能够定位到具体的故障组件，但其准确性取决于日志记录的数量和位置。同时，由于需要收集大量的日志文件，从中抽取固定的模式，难以满足在线故障检测的需求。

[0005] 面向分布式软件架构的分布式软件，当前的异常诊断方法面临以下挑战。首先，分布式软件的一个请求处理需要多个相互独立的组件协同配合完成，因而难以监测与特定请求相对应的跨节点请求处理路径。其次，分布式软件的业务逻辑种类繁多，因而难以分析得到众多不确定的执行轨迹。最后，分布式软件组件通常会有多个运行实例，因此难以准确定位出现故障的运行实例与具体位置。

发明内容

[0006] 本发明的技术解决问题：克服现有技术的不足，提供一种基于执行轨迹追踪的分布式软件异常诊断方法，通过代码注入监测请求处理的执行路径，刻画分布式软件的执行轨迹，从而通过与基准执行轨迹进行对比分析，以准确定位故障原因，从而准确定位发生错误的位置。

[0007] 本发明技术解决方案：一种基于执行轨迹追踪的分布式软件异常诊断方法，包括以下步骤：

[0008] 第一步：执行轨迹监测：利用动态插桩的方式，在分布式软件的函数调用处插入监测代码，收集该函数的执行信息，执行信息包括该函数唯一标识、处理时间、服务组件唯一标识和远程调用协议中加入的该函数调用关系；根据以上函数的执行信息利用调用树描述函数的执行序列，即执行轨迹；

[0009] 第二步：在覆盖测试阶段对分布式软件进行监测，以构建执行轨迹的集合，上述执行轨迹的集合构建过程如下：

[0010] 针对当前的执行轨迹，通过宽度优先搜索的树匹配算法与上述执行轨迹的集合中已有的执行轨迹进行匹配；如果匹配成功，则继续下一个执行轨迹的匹配；如果匹配失败，则在上述执行轨迹的集合中新增当前的执行轨迹；

[0011] 第三步：将第二步建立的执行轨迹集合作为检测分布式软件的故障的基准，通过比较与分析监测得到的当前执行轨迹与上述执行轨迹集合中的执行轨迹，以定位分布式软件故障的原因；

[0012] 将分布式软件的故障分为系统错误故障和性能异常故障两类，针对这两类故障分别提出相应的异常诊断方法，实现了函数粒度的故障定位。

[0013] 所述第三步中，具体实现如下：

[0014] (1)在系统错误诊断方面，利用树编辑距离来评估执行轨迹的异常程度，通过对比分析历史执行轨迹的差异，定位发生错误的函数调用；

[0015] 树编辑距离为：

[0016]

[0017] 其中，Ti为监测得到的当前第i个执行轨迹；Cj为执行轨迹集合中的第j个基准执行轨迹；V(Ti)和V(Cj)分别为Ti和Cj中函数的数量；δ(Ti，Cj)为Ti和Cj的编辑距离。

[0018] Ti的异常程度：

[0019] AD＝1-max(Sim(Ti,Cj))；

[0020] 如果AD大于预置的阀值γ，则表示该执行轨迹发生了错误；

[0021] 利用宽度优先搜索比较Ti和Cj的轨迹差别，能够定位到错误出现在具体函数；

[0022] (2)在性能异常方面，利用主成分分析提取引起性能异常的函数调用，如果当前执行轨迹的执行时间出现大幅度波动，则该执行轨迹出现性能异常，利用变异系数来衡量执行轨迹的执行时间的波动程度：

[0023]

[0024] 其中：

[0025]

[0026]

[0027] 其中，xi为第i个执行轨迹的执行时间；μ为该执行轨迹的执行时间的平均值；σ为该执行轨迹的执行时间的标准差；CV为该执行轨迹的执行时间的标准差与均值的比值，表明分布式软件的执行轨迹的执行时间波动幅度；

[0028] 执行轨迹是由函数调用的序列组成，在确定出现性能异常的执行轨迹后，需要利用主成分分析定位造成该执行轨迹性能异常的函数调用；

[0029] 建立线性组合，如下式：

[0030] pi＝ai1t1+…+aijtj+…+aintn

[0031] 其中，pi表示主成分i；变量ti表示执行轨迹中的第i个函数的执行时间；aij表示主成分pi对于tj的系数；n为该执行轨迹中函数的个数；

[0032] 利用主成分分析计算得到k个主成分为p1，p2，..，pk，其对应的特征值为λ1，λ2，...，λk，k

[0033] 本发明的原理：首先利用跨服务组件的执行轨迹监测及约简方法对执行轨迹进行了刻画；然后，从系统错误和性能异常两方面进行了异常诊断。在系统错误诊断方面，利用调用树的编辑距离来评估请求处理的异常程度，通过对比分析执行轨迹的差异，准确定位发生错误的函数调用。在检测性能异常方面，利用主成分分析提取对响应时间延迟造成影响较大的组件实例与函数调用。

[0034] 本发明与现有技术相比具有如下优点：

[0035] (1)本发明利用动态插桩的方式，在分布式软件的函数调用处插入监测代码，收集函数的执行信息。在远程调用协议中加入了函数调用关系，以实现跨组件的请求处理轨迹监测。同时，为了消除递归、循环调用等对执行轨迹的影响，增加了相应的约简规则。该函数具有可插拔、易扩展的特点，并能够自动化刻画与构建请求处理的执行轨迹。

[0036] (2)本发明针对造成执行轨迹改变的故障，采用树的编辑距离来评估请求的异常程度，通过对比分析定位引起故障的函数调用。针对造成服务响应时间延迟的故障，利用主成分分析对监测数据进行降维，进而提取异常函数。本发明以较低开销，能够以函数为粒度准确定位问题原因。

附图说明

[0037] 图1为本发明的实现流程图；

[0038] 图2为本发明的实验环境；

[0039] 图3为本发明的四种服务构建的执行轨迹数；

[0040] 图4为本发明的系统异常程度变化；

[0041] 图5为本发明中服务13种执行轨迹变异系数；

[0042] 图6为本发明中服务轨迹5响应时间；

[0043] 图7为本发明中主成分占比。

具体实施方式

[0044] 以下结合具体实施例和附图对本发明进行详细说明。

[0045] 如图1所示，本发明一种基于执行轨迹追踪的分布式软件异常诊断方法，实现步骤如下：

[0046] 首先，进行执行轨迹监测。利用动态插桩的方式，在分布式软件的函数调用处插入监测代码，收集该函数的执行信息，利用调用树描述函数的执行序列，即执行轨迹；

[0047] 然后，在覆盖测试阶段对分布式软件进行监测，以构建执行轨迹的集合。通过宽度优先搜索的树匹配算法与执行轨迹集合中已有的执行轨迹进行匹配；如果匹配成功，则继续下一个执行轨迹的匹配；如果匹配失败，则在执行轨迹的集合中新增当前的执行轨迹；

[0048] 最后，将建立的执行轨迹集合作为检测分布式软件故障的基准。通过比较与分析监测得到的当前执行轨迹与执行轨迹集合中执行轨迹的函数调用序列和函数执行时间，以定位分布式软件故障的原因。

[0049] 具体实施例的部署环境如图2所示，Console为管理组件，提供了测试参数配置、错误注入及监控等功能；Agent为负载发生代理，接受Console发送来的指令，模拟用户行为，访问网上书店服务；网上书店应用在应用服务器A和应用服务器B各部署一个实例；负载均衡器为应用服务器集群提供负载均衡，采用轮询负载策略；数据库提供存储服务；故障诊断系统为本文所提出方法的实现。

[0050] (1)执行轨迹获得与监测

[0051] 1)执行轨迹获得

[0052] 请求的处理是由若干服务组件协同完成，其执行轨迹是各服务组件的函数调用。采用函数调用树来刻画请求处理的执行轨迹，结点Mi用多元组(1)表示：

[0053] Mi＝(requestUID,methodUID,callerUID,calleeList,info)  (1)

[0054] 其中，requestUID为请求标识符，在请求入口处生成；methodUID为函数标识符；callerUID为父函数标识符；calleeList为子函数列表；info包含函数的其他信息，用多元组(2)表示：

[0055] info＝(callType,serviceUID,order,startTime,endTime,duration)  (2)[0056] 其中，callType为函数的调用类型，分为本地调用和远程过程调用(Remote ProcessCall，RPC)。serviceUID为函数所在服务组件的标识符；order为函数的调用顺序，子节点按照从左到右的顺序排序为函数的调用时序关系；startTime和endTime是函数开始、结束时间；duration为函数的执行时间，但不包括子函数的执行时间。

[0057] 2)执行轨迹的监测

[0058] 本发明采用一种动态插桩的方式获取执行信息，对JAVA应用程序进行了字节码注入，在虚拟机启动时通过增加代理的方式将监测代码插入到指定函数。分布式软件的函数调用包括本地和远程调用，执行轨迹的监测主要需要解决以下问题：

[0059] ①多服务组件的每个请求的区分及标识：在系统入口服务组件处为请求生成唯一标识requestUID，在调用远程函数时，调用函数将requestUID传递给被调用函数，被调用函数解析该字段，确定该函数调用属于哪个请求。

[0060] ②服务组件间的函数调用关系的确定：被调用函数维护调用函数的标识符callerUID，远程函数调用时，将本函数的标识符methodUID传递给远程函数，远程函数解析该字段，获得调用函数的标识符。

[0061] ③多服务组件的函数调用顺序的确定：在远程调用函数时，为远程函数分配一个调用顺序order字段，从而保证了分布式环境下监测函数调用顺序的正确性，解决了由于节点的时钟难以实现完全同步而导致的无法准确确定函数调用顺序的问题。

[0062] 各个服务组件以本地入口函数为根构建调用子树，确定函数的调用关系，然后根据请求标识符requestUID，并根据函数调用关系实现执行轨迹的调用树的构建。由于存在函数循环调用和递归调用，逻辑上等价的执行轨迹生成的调用树不同，将导致同一服务的执行轨迹种类难以确定，需要进行约简处理，因此增加了约简规则及函数，确保调用树中的循环和递归可以被识别出来，进而将循环和递归中的节点汇总为一个新节点消除循环和递归以实现约简，其中执行时间取结点的平均时间。

[0063] (2)执行轨迹的构建

[0064] 在覆盖测试阶段对软件系统的执行轨迹进行监测，以构建执行轨迹集合，将其作为检测系统故障的基准。服务的执行轨迹集合S构建过程如下：

[0065] ①初始阶段，轨迹集合S为空；

[0066] ②针对轨迹Ti，通过宽度优先搜索的树匹配算法与集合S中已有的轨迹Cj进行匹配；

[0067] ③如果匹配成功，则继续下一个执行轨迹的匹配；

[0068] ④如果匹配失败，则集合S新增执行轨迹Ci。

[0069] 测试的覆盖率越高，得到的基准执行轨迹集合就越全面，则异常诊断准确率越高。为了避免覆盖测试阶段遗漏的正确执行轨迹，在软件系统上线运行阶段，管理员发现异常的执行轨迹时，可以根据经验进行修正，发现、确认新的正确执行轨迹，并将其加入基准执行轨迹集合。

[0070] (3)异常诊断

[0071] 系统故障会导致执行轨迹发生偏离，表现为执行轨迹结构的变化和执行时间的波动，本发明中依次将其称为系统错误故障和性能异常故障，并针对这两类故障分别提出相应的异常诊断方法，实现了函数粒度的故障定位。

[0072] 1)系统错误诊断

[0073] 同一服务请求处理的执行轨迹集合包含了其可能的执行轨迹，以此为基准，将运行时监测到的执行轨迹与之对比分析，从而对某一请求进行系统错误定位。本发明中采用树编辑距离来评估执行轨迹的异常程度，对超过异常阀值的请求，实现了函数级别的故障定位。为了确定异常发生的函数调用，需要找出最相近的基准轨迹进行对比。本发明基于树的编辑距离的定义，使用式(3)来定义树的相似度：

[0074]

[0075] 其中，Ti为请求i的执行轨迹；Cj为其中一种基准轨迹；V(Ti)和V(Cj)分别为Ti和Cj的结点数；δ(Ti，Cj)为Ti和Cj的编辑距离。

[0076] 进一步，当树的相似度较较低时，则异常的程度越大，使用式(4)来评估执行轨迹Ti的异常程度：

[0077] AD＝1-max(Sim(Ti,Cj)),Cj∈Ti所属服务的执行轨迹集合S  (4)

[0078] 如果AD大于预置的阀值γ，则表示该请求发生了错误。阀值选取将影响异常诊断结果，如果阀值设置过大，则容易造成诊断遗漏；如果设置过小，则将导致误报率增加。通过比较Ti和C的轨迹差别，可以定位到错误出现在具体哪个函数，函数粒度的错误定位采用宽度优先的错误函数调用定位算法。

[0079] 2)性能异常诊断

[0080] 同一执行轨迹有相同函数调用树，执行时间也相对稳定，如果执行时间出现大幅度波动，则该请求处理出现性能异常。采用变异系数来衡量执行时间的异常程度：

[0081]

[0082] 其中：

[0083]

[0084]

[0085] 其中，xi为第i个请求的执行时间；μ为某类请求的平均执行时间；σ为标准差；CV为标准差与均值的比值。CV较大则表明系统在处理请求时响应时间波动幅度较大，性能异常程度较高，则需要进行性能分析。一个执行轨迹往往包含上百个函数调用，而函数间存在调用关系，也就是包含了冗余数据，需要从中选取引起性能异常的关键函数以缩小异常定位范围。主成分分析(PCA，Principle Component Analysis)是一种常用的多元分析方法，可以利用PCA可有效的降低原始数据的维度，从而缩小问题定位的范围。

[0086] 基于PCA的性能异常诊断步骤如下：

[0087] ①构建请求处理矩阵

[0088] PCA的输入为矩阵，首先需要将执行轨迹转换为执行序列。采用调用树表示执行轨迹，树结点满足一定父子关系和时序关系，因此可将调用树转换为等语义的执行序列。我们利用基于时间序列的深度优先搜索算法，将调用树T转换为执行序列。各个请求的执行序列按行排列，组成PCA分析的输入矩阵A：

[0089]

[0090] 其中，m为请求数量；n为执行轨迹的函数数量；列表示函数的执行时间，即tij为请求i执行轨迹中函数Mj的执行时间。

[0091] ②主成分分析

[0092] 执行轨迹序列中每个函数的执行时间是不同的，需要对原始矩阵X进行标准化转换，得到标准化矩阵Z：

[0093]

[0094] 其中：

[0095]

[0096]

[0097] 然后，求标准化矩阵Z的协方差矩阵Σ：

[0098]

[0099] 其中：

[0100]

[0101] 最后，求协方差矩阵Σ的特征值和特征向量，求解特征方程：

[0102] ∑X＝λX  (14)

[0103] 得到特征值λ1，λ2，...，λn及对应的特征向量μ1，μ2，…，，μn.[0104] ③主成分选取

[0105] 主成分的选取决定了数据压缩率，设选取的主成分个数为k。特别的，如果k＝n，相当于在原始数据上进行了转换，保留了原始数据的100％信息。那么在选择k值时，以k个主成分可以保留的方差百分比为参考依据，百分比越大，选取的主成分所表示的信息，与原始数据越近似，首先对特征值λ1，λ2，...，λn按照降序排序，然后计算主成分方差百分比，如式(15)：

[0106]

[0107] 其中β为常量。

[0108] ④异常函数的定位

[0109] 主成分实际上是原有维度的线性组合，而系数向量就是对应的特征向量，如式(16)：

[0110] p1＝a11t1+a12t2+…+a1ntn

[0111] p2＝a21t1+a22t2+…+a2ntn

[0112] …

[0113] pm＝am1t1+am2t2+…+amntn  (16)

[0114] 其中，pi表示主成分i；变量ti表示函数Mi执行时间；aij表示主成分pi对于变量ti的系数，表示了主成分与原始数据维度的相关性，系数越大，则表示该维度对主成分贡献越大，即该维度对应的函数即为引起性能问题的主要因素，于是给出性能异常故障的定位算法：性能异常故障定位算法。

[0115] 作为本发明实施例方法的使用环境，选取了中国科学院软件研究所自主研发的符合TPC-W规范的基准测试套件Bench4Q。系统架构如图2所示，Console为管理组件，提供了测试参数配置、错误注入及监控等功能；Bench4Q的Agent接受Console发送来的指令，模拟用户行为，访问应用服务；应用服务器Tomcat部署了Bench4Q的网上书店应用；负载均衡器Nginx为应用服务器集群提供负载均衡，采用轮询负载策略；数据库MySQL为应用提供存储服务；异常诊断系统为本发明所提出方法的实现。实验，数据库、负载均衡器和应用服务器均采用默认配置，Bench4Q设置10000件商品和1440000个用户。

[0116] 本发明实施例流程：

[0117] (1)执行轨迹构建

[0118] 选取Bench4Q其中典型的4种服务作为研究对象进行执行轨迹的构建，分别为Search request(查找)、Product detail(浏览)、Buy Request(购买)、Buy Confirm(付款)，从而得到选取的4种服务执行轨迹数如图3所示。

[0119] (2)异常诊断

[0120] 模拟生产环境中常见的故障，如表1所示。在实验过程中，我们将错误单独注入到系统，并在Console设置每次负载持续时间为90秒，并发数为100，同时异常诊断系统收集系统的执行信息，并进行异常诊断。

[0121] 表1注入故障列表

[0122]

[0123]

[0124] 选取其中三个典型的故障为例介绍：

[0125] 故障(1).通过TC工具造成应用服务器A网络丢包15％；

[0126] 故障(2).设置应用服务器A数据库连接数maxActive为10；

[0127] 故障(3).使用SELECT…FOR UPDATE语句给订单表加一个X锁；

[0128] 对于偶然性故障，比如模拟CPU、网络异常等，是可以恢复的，实验在第30秒注入，持续30秒，然后恢复正常。对于持久性故障，比如JVM配置、数据库连接等，需要重启服务器才能恢复，因此此类故障持续时间90秒。故障(1)和(3)在第30秒注入，持续30秒，然后恢复正常，而故障(2)持续时间90秒。

[0129] 1)系统错误的异常诊断

[0130] Search request(查找)、Product detail(浏览)、Buy Request(购买)、Buy Confirm(付款)等四种服务的异常程度变化如图4所示，选取与监测到的异常执行轨迹具有最大相似度的基准执行轨迹集合中的正常执行轨迹，将检测到的运行时执行轨迹与正常执行轨迹进行对比，当注入错误时，请求的执行轨迹相应发生了变化，因而异常程度增大。

[0131] 在第30秒注入故障(1)后，4种服务均发生请求失败，出现了服务违约，从图4可知，错误执行轨迹的异常程度分别超过了0.16、0.41、0.38和0.23.通过错误定位算法，得到发生错误的函数均与网络相关，且发生在应用服务器A的函数占比约95％，因此进一步，可以断定故障发生的位置为服务器A的网络。

[0132] 注入故障(3)后，Buy Request和Buy Confirm服务失效，从图7可知，相对于Search request和Product detail，Buy Request和Buy Confirm的执行轨迹异常程度较大，分别超过了0.63和0.61。采用通过错误异常诊断函数，定位出异常发生所在的位置为新增订单函数和修改订单函数，这样有效地缩小了故障排查范围。

[0133] 对于故障(2)，有意将应用服务器A的数据库连接数设置过小，在100个并发数下，结果只有少数执行轨迹结构发生变化，但服务响应时间延迟较大，为进一步确定问题发生在哪个环节，在下将以Buy Confirm服务为例进一步进行诊断性能异常。

[0134] 2)性能异常的异常诊断

[0135] Buy Confirm服务共有13种执行轨迹，在数据库连接数设置过小的时间段内，各执行轨迹的变异程度CV如图5所示。

[0136] 实验中选取变异系数最大的轨迹5作为分析对象，由图6可见，服务的响应时间波动很大，但CPU、内存等物理资源使用率并不是很高，仅依据资源利用率难以定位出问题的原因。

[0137] 执行轨迹5包含了57个函数调用，通过性能异常诊断，得到主成分占比如图7所示，主成分1、2、3分别占64.9389％、26.2608％和4.1277％，主成分1和2累计占91.1997％，因此，主成分1和2可以有效的表现了原有数据信息。

[0138] 表2列出了前三个主成分与其中6个函数的系数，系数越大则主成分与函数的相关性越强。从表4分析结果可以定位引起性能瓶颈的主要函数为Database.getConnection()，从异常诊断的输出结果中，应用服务器A和B此函数的平均执行时间为501.46ms和1.75ms，从中可以确定性能瓶颈发生在应用服务器A的创建数据库连接环节。

[0139] 表2主成分与函数的系数

[0140]

[0141] 提供以上实施例仅仅是为了描述本发明的目的，而并非要限制本发明的范围。本发明的范围由所附权利要求限定。不脱离本发明的精神和原理而做出的各种等同替换和修改，均应涵盖在本发明的范围之内。