一种Web应用系统的故障定位方法

专利名称：：一种Web应用系统的故障定位方法
技术领域：
：本发明涉及故障定位
技术领域：
，特别涉及一种Web应用系统中通过主动探测对应用层故障进行定位的方法。
背景技术：
：Web应用系统是指基于Web技术，通过浏览器提供用户接口，通过数据库服务器和应用服务器提供数据和业务逻辑，用户与服务器之间采用http(HyperTextTransportationProtocol,超文本fl车俞t办议)、https(SecureHypertextTransferProtocol,安全超文本传输协议)或其他标准协议交互的应用系统。目前，随着Web技术的发展、Web应用系统体系框架的成熟和网络条件的改善，Web应用系统得到广泛的应用，也变得越来越庞大复杂，而针对Web应用系统的故障诊断也日益得到广泛的关注。Web应用系统一般是多层次的分布式系统，面临的故障可能来自不同的方面，比如应用服务器故障、网络故障和业务逻辑故障等。前人研究表明Web应用系统服务提供失败大多源于维护过程中业务配置错误[3]。这样的错误一般不会导致整个系统瘫痪，而往往造成系统业务逻辑发生改变，从而导致某些Web应用语义发生错误，比如一个授权的用户无法登录，不能往购物车添加商品等。这种症状表现为语义错误的故障被称为应用层故障。应用层故障是最常见的故障，也是服务提供者最关注的故障。通过网络层的ping、和协议层的httprequest等手段无法检测应用层故障，必须采用语义级别的检测手段。当前的Web应用系统故障诊断方式主要通过监测系统内部的请求及其执行状况来推测发牛故障的模块位置，是一种被动方式，往往需要对系统进行改造或增加额外相关组件和系统状态数据传送链路，使系统能够向监测系统主动提供内部的状态，实现方式复杂、维护难度较大。本发明中的Web应用系统主动性的故障诊断方式是主动向Web应用系统发出业务请求以探测系统内部状态的一种故障诊断方式。根据应用层故障定义可知，Web应用业务请求结果是应用层故障的直接症状数据。通过探测采集的症状数据，结合业务请求的与提供业务逻辑系统组件之间的关联关系，可以推断Web应用系统的故障所在。其次，由于主动探测方式不需要改变Web应用系统本身架构或功能定义，因此对Web应用系统具有较强的独立性，能够构造代价较小、实施简单、快速适应Web应用系统业务逻辑配置变化的诊断系统，从而提高故障诊断的效率和准确件。《ProceedingsoftheInternationalConferenceonDependableSystemsandNetworks》，2002年公开了一篇名为《Pinpoint:problemdeterminationinlarge,dynamicInternetservices》的论文[l]，该论文论述了Pinpoint(定点法)，是一种基于数据挖掘的故障诊断方法，它监控所有的Internet服务模块间的消息传递来跟踪一个用户请求经历的模块，对每一个请求需要记录相关的数据包括用户请求ID，经历的模块和执行的结果；在故障发生时对记录的数据进行分析。Pinpoint有以下几个缺点1)需要更改Web应用系统的消息中间件以上报内部的消息，这需要修改被管系统，在实际使用中很多时候不可行，而且增加了故障诊断部署和维护的成本；2)在实际运行过程中，被管系统会产生大量的、错综复杂的消息数据，其中大部分是无用的，给诊断系统带来数据处理的上的负荷；3)被动的诊断系统是一种事后的诊断，无法在故障呈现给用户前诊断出故障。《26thIEEEInternationalSymposiumonReliableDistributedSystems》，2007年公开了一篇名为《DistributedDiagnosisofFailuresinaThreeTierE-CommerceSystem》的论文[2]，该论文论述了Monitor(监视法)方法。该方法不但监视所有的服务请求的执行结果，还追踪服务请求的执行过程。它为每个模块维护一个逻辑时钟，来记录模块在一个服务执行过程中调用或被调用时间顺序。根据这个逻辑时间能够生成一个模块之间的消息传递因果关系图。当失败发生时，依据当前的因果关系图进行概率推理。Monitor需要了解每个组件内部方法的调用情况，并为每个组件维护一个状态图，大大增加了算法的复杂性。Monitor的机制过于复杂，不易实现、部署和维护的开销都比较大。以弓1入方式将上述技术内容合并于本申请。
发明内容本发明的目的在于提供一种Web应用系统中通过主动探测对应用层故障进行定位的方法，能够在不改造Web应用系统的前提下，简单、有效对Web应用系统的应用层的故障模块进行快速定位，并能够快速适应Web应用系统的业务逻辑配置变化。为了实现上述目的，本发明提供了一种Web应用系统的故障定位方法，该方法是通过如下技术方案实现的一种Web应用系统的故障定位方法，该方法包括建立扩展依赖矩阵模型步骤抽象出系统中所有的故障点和可用探测，并确定所述故障点和所述探测之间的对应关系，建立扩展依赖矩阵进行描述。执行探测歩骤向目标Web应用系统发送探测请求，并分析返回结果，确定探测执行成功或失败，得出探测结果集合，作为故障推理分析的症状数据。故障推理分析步骤基于扩展依赖矩阵模型和症状数据探测结果集合，失败探测相关的故障点过滤为可能发生故障的故障点；成功探测相关的故障点排除发生故障的可能性。对所述过滤得出的故障点集合，分析每个故障的可能性大小，按从大到小的顺序进行排列。本发明的Web应用系统的故障定位方法是一种基于扩展依赖矩阵和主动探测获取症状数据后推理分析的故障定位方法。所述方法中扩展依赖矩阵除了抽象出传统依赖矩阵[4]中业务请求探测与模块的业务逻辑关联，还抽象出业务请求探测与模块间调用关系的业务逻辑关联，能够对应用层故障进行精度较高的故障诊断定位。所述方法中主动探测获取症状数据方式与Web应用系统具有较强的独立性，不需要跟踪Web应用系统内部的消息，不需要修改Web应用系统，使得诊断系统的易于维护；并能够快速适应Web业务逻辑的配置变化，实施简单。此处所说明的附图用来提供对本发明的进一歩理解，构成本申请的一部分，并不构成对本发明的限定。在附图中如图1所示为本发明一种Web应用系统故障定位方法流程图；如图2所示为本发明建立扩展依赖矩阵模型详细步骤流程图；如图3所示为本发明一个依赖关系实施例图；如图4所示为本发明过滤可能故障点详细歩骤流程图；如图5所示为木发明排序可能故障点详细步骤流程图。具体实施方式为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明的具体实施例进行详细说明。在此，本发明的示意性实施例及其说明用于解释木发明，但并不作为对本发明的限定。本发明提供一种Web应用系统模块的主动快速故障定位方法。图1为本发明一种Web应用系统故障定位方法流程图，如图1所示，本方法主要分为三个步骤步骤IOI，建立扩展依赖矩阵模型；步骤102，执行探测；步骤103，故障推理分析。下面分别予以说明。(一)歩骤IOI，建立扩展依赖矩阵模型大多数的故障定位方法通过建立故障传播模型作为故障定位的依据。在系统故障传播模型中，存在症状和故障两个重要概念(1)症状，当系统内部出现功能或业务逻辑的各种问题时，表现出来的各种反映系统当前状态的信息；(2)故障，所述症状出现的根本原因。虽然故障一般是不可观测的，但是可以根据外在的、可观测的症状进行推理以确定故障的根源所在。Web应用系统往往由一组相互独立的功能模块组成。模块之间相互协作实现系统的业务逻辑，所述模块一般对外提供有限的接口调用并往往通过标准的消息中间件来实现模块间交互。当Web系统模块发生故障时，与该模块相关Web业务请求结果为所述故障的一种能够直接被观测到的外在业务症状。在此前提下，本发明对具体Web应用系统进行建模，通过功能模块和业务请求二者之间的依赖关系，建立系统中可能的故障点和业务请求之间的对应关系模型，得到扩展依赖矩阵模型，以便于进行模块故障的定位。如图2本发明建立扩展依赖矩阵模型详细步骤流程图所示，主要包括以下步骤步骤201:获取Web应用系统的功能模块集合，各个模块之间相互独立。所述各个模块之间相互独立是指模块内部封装实现系统部分业务逻辑功能，具有独立的状态，对外仅提供有限的接口调用或者通过标准的消息中间件来实现模块间交互。步骤202:罗列所有可用的探测请求集合，各个探测之间相互独立，探测请求集合需尽可能覆盖所有的模块和模块之间的调用关系。所述探测是指在Web应用系统屮，客户端发起一次Web业务请求，服务器端对该Web业务请求事件进行处理并向客户端返回结果的一次端到端的完整交互。如果一次探测交互返回的结果符合系统的业务逻辑设计，则认定探测成功，否则认定探测失败。比如一个电子商务网站"添加一件商品到购物车"的探测实施例为用户在Web页面上选择一件商品，并点击"添加到购物车"，服务器响应该请求并返回结果添加成功或添加失败或其他异常。对返回结果，如果商品在架有货且结果为添加成功或者商品暂时缺货且结果为添加失败，则认定探测成功，否则认定探测失败。所述各个探测之间相互独立是指任意探测A的成功或失败不依赖于任意B探测，而仅与提供所述A探测业务逻辑的功能模块相关。即任一探测无论其执行结果如何，不会改变系统的后续行为。Web应用系统系统通常满足这个条件。所述探测请求集合是指针对一个具体的Web应用系统，实际用户可以向Web应用系统发出所有可能的Web请求。探测请求的种类越多，对Web应用系统的功能模块以及模块之间调用关系的覆盖就越全面，相应的对系统模块故障的定位准确性就越高。步骤203:从模块集合和模块间的调用关系分别抽象出单模块故障点和模块调用故障点。为了进行故障定位，需要从目标系统中抽象出一组故障点(故障定位的最小单位)。故障点之间应该相互独立，每个故障点具有两个独立状态发生故障或没有故障。本发明所述故障点分为两类单模块故障点和模块调用故障点；所述单模块故障点对应的单模块故障是指某个模块发生内部逻辑故障，使得任意其他模块对它的调用都会失败；所述模块调用故障点对应的模块调用故障是指某个模块的发生某个对外调用或被调用故障，使得特定模块对其调用或被调用失败。在本发明中，Web应用系统相互独立的功能模块映射为单模块故障点；模块间调用关系映射为模块调用故障点。当两个模块之间存在不同的调用关系时，即一个模块以不同的方式调用另一个模块，则对每种调用关系都抽象成模块调用故障点。比如模块A和B(A存在两种对B的调用关系)的实施例，抽象故障点时可以得出Fab.l，Fab.2这样的模块调用故障点。步骤204:确定探测请求集合和故障点集合之间的依赖关系。每个探测根据其实现的业务逻辑，总是固定地依赖于提供该业务逻辑的相关功能模块，而和其他模块无关。此时，所述探测与所述功能模块对应的故障点存在依赖关系。一方面，被依赖故障点的状态会影响探测的结果(成功或失败)；另一反面，探测的结果反映了其依赖的故障点的运行状态(发生故障或没有故障)，本发明所述的故障定位就是根据探测结果和探测与故障点的依赖关系来分析定位哪个模块存在故障。步骤205:根据探测请求集合与故障点依赖关系，建立扩展依赖矩阵；通过探测请求集合与故障点依赖关系，建立系统中可能发生故障的功能模块位置和业务请求之间的对应关系模型。传统的依赖矩阵是由探测请求集合与单模块故障点集合构成。<table>tableseeoriginaldocumentpage12</column></row><table>P411101根据表1所示，所述依赖矩阵包括F1~F5五个故障点和P1P4四个探测。矩阵交叉点取值为1时表示对应探测与故障点之间存在依赖，否则取值为0表示探测与故障点无依赖关系。Pl由Fl调用F3实现，即Pl依赖于Fl和F3。如果F1或F3发生故障，则P1很可能探测失败，反之如果P1探测失败，则说明Fl和F3中至少有一个故障点发生故障。根据依赖矩阵模型，如果探测失败，可以推断所述探测依赖的模块故障点必然存在至少一个模块发生故障。反之，探测成功，却不能推断所述探测依赖的模块故障点没有发生故障。比如模块调用故障只在某种特定的调用上下文中得以体现，不影响模块的其他业务提供。在这种情况下，无法从成功探测中获取故障定位信息。扩展依赖矩阵是传统依赖矩阵的扩展，由探测请求集合与故障点集合构成，故障点集合不仅包括单模块故障点，还包括模块调用故障点。如果探测依赖于某个功能模块，则所述探测依赖于所述功能模块对应的单模块故障点；如果探测会引起某些功能模块间的调用被执行，则所述探测依赖于所述功能模块对应的单模块故障点和所述调用对应的模块调用故障点。根据扩展依赖矩阵模型，如果探测失败，可以推断所述探测依赖的故障必然存在至少一个模块发生故障。反之，如果探测成功，由于探测的调用上下文关系确定，则可以推所述探测依赖的故障点都没有发生故障，相比传统的依赖矩阵，故障定位的精确度得到明显提高。如图3本发明一个依赖关系实施例图所示，所述实施例包括A，B，C三个模块和P1P3两个探测。Pl由A调用B实现；P2由A调用C接口1实现；P3由A调用C接口2实现。则Pl依赖单模块故障点Fa、Fb和调用故障点FabP2依赖单模块故障点Fa、Fc和调用故障点Facl;P3依赖单模块故障点Fa、Fc和调用故障点Fac2。如表2所示为根据图3依赖关系实施例生成的依赖矩阵。FaFbFcPl110P2101P3101如表3所示为根据图2依赖关系实施例生成的扩展依赖矩阵。FaFbFcFabFac2Fac2Pl110100P2101010P3101001根据表2和表3所示，当探测结果为P1成功、P2失败、P3成功时，则在依赖矩阵模型下，P2失败推断故障点Fa、FC至少一个发生故障；Pl成功说明A调用B成功；P3成功说明A调用C成功。Pl、P3成功如果可以推断Fa、Fb、Fc均未发生故障，则与P2失败推断的结论相斥。因为故障点中调用上下文没有在依赖矩阵中得到体现，依赖矩阵中的成功探测不可作为故障推断的依据。而在扩展依赖矩阵模型下，P2失败推断故障点Fa、Fc、Facl至少一个发生故障；Pl成功由于调用上下文确定，可以推断Pl依赖的故障点Fa、Fb、Fabl没有发生故障；P3成功由于调用上下文确定，可以推断P3依赖的故障点Fa、Fc、Fac2没有发生故障。结合探测结果集合的推断结果，可以推断出唯一可能发生故障的故障点为Facl，即模块A对模块C的接口1调用发生故障，反过来验证P1P3的结果是一致的。因此，扩展依赖矩阵模型相比依赖矩阵模型，故障定位精确度有很大提高。(二)步骤102，执行探测在建立好扩展依赖矩阵模型后，通过执行依赖矩阵中的探测请求集合，可以得到一组探测结果集合，反映系统当前状态，作为故障推理分析的依据。(三)歩骤103，故障推理分析在执行依赖矩阵中的探测请求集合后，本发明通过分析探测请求集合执行返回结果，根据扩展依赖矩阵中探测与故障点之间的依赖关系，过滤出一系列可能发生故障的故障点集合，并对所述故障点集合的所有可能故障点进行可能性计算，再按可能性大小对故障点进行降序排列输出，用户可选择其中前一个或多个结果作为最终的故障推理分析结果。本发明的推理分析方法主要包括如下两个步骤(O过滤可能故障点步骤:根据探测结果集合Ps和扩展依赖矩阵模型，过滤出所有可能发生故障的故障点和每个故障点对应的失败探测数。其中，失败探测推断可能发生故障的故障点，成功探测排除故障点发生故障的可能性。(2)排序可能故障点步骤根据每个故障点对应的失败探测数进行将故障点从高到低降序排列输出，通过所述失败探测数来体现每个故障点发牛发牛的的可能性大小。如图4所示为木发明过滤可能故障点洋细歩骤流程图步骤401，初始化一个二维过滤输出结果FS，将第一维故障点设为空，第二维计数器Cf清零，初始化一个成功探测依赖故障点集合Ss为空，进入歩骤402。步骤402，判断探测结果集合Ps是否为空，如果为空则进入歩骤408，否则进入歩骤403;步骤403，从探测结果集合Ps中取出一个探测结果P，进入歩骤404;步骤404，判断探测结果P是否为成功探测，如果为是则进入步骤405，否则进入步骤406;步骤405，根据扩展依赖矩阵模型，将P依赖的故障点加入到Ss，进入步骤407;步骤406，根据扩展依赖矩阵模型，将P依赖的故障点加入Fs，每个故障点对应计数器加l，进入步骤407;步骤407，将P从探测结果集合Ps中删除，并返回步骤402;步骤408，判断成功探测依赖故障点集合Ss是否为空，如果为是则进入步骤412，否则进入步骤409;步骤409，从成功探测依赖故障点集合Ss中取出一个故障点F，进入步骤412;步骤410，对应所述Ss中的F，将二维过滤输出结果Fs中对应取值为F的故障点清空，对应计数器清零，进入步骤411;步骤411，将F从成功探测依赖故障点集合Ss中删除，并返回步骤408;步骤412，结束故障过滤流程并返回故障过滤结果Fs。如图5所示为本发明排序可能故障点详细歩骤流程图步骤501，初始化一个二维排序结果队列Fq,将第一维故障点设为空，第二维失败探测数Cq清零，进入步骤502;步骤502，判断故障过滤结果Fs是否为空，如果为空则进入歩骤505，否则进入步骤503;步骤503，在Fs中选取一个计数器Cf值最大的故障点F，把该故障点F加入Fq队尾，并采用Cf对Cq赋值，进入步骤504;步骤504，在Fs中删除将该故障点F，对应计数器Cf清零，并返回到步骤502。步骤505，结束故障过滤流程并返回故障排序队列Fq。以下是一个电于商务Web应用系统的故障定位的实施例。该应用系统是一个简单的电子购物系统，所述实施例仅涉及顾客登录购物到提交购物车到订单再退出登录的一种购物车购物业务逻辑，因此所述实施例中的系统组件可能少于具体的电子购物系统。根据本发明所述故障定位方法，首先对这个系统进行建模，抽象出扩展依赖矩阵，执行探测后根据探测结果进行故障分析。(一)建立扩展依赖矩阵模型，包括以下五个歩骤步骤一获取Web应用系统相互独立的功能模块集合。本实施例相互独立相关组件或模块模块如下A——顾客模块存储处理顾客信息；B——仓库模块存储处理商品信息的模块；C——控制器模块接收外部用户接口消息，并向各个功能模块转发消息；D——购物车模块存储处理顾客本次会话的购物车信息；E——订单模块存储处理本次会话的订单信息；以上五个模块功能相互独立。步骤二罗列所有可用的相互独立的探测请求集合。根据电于商务购物的业务逻辑，确定可以执行且相互独立的探测集合将用户可以执行所有操作作为我们可以执行的探测，本实施例列探测请求集合如下..P0——顾客登入系统控制器模块(C)接收用户登录信息，发往顾客模块(A)验证，通过则创建顾客会话实例；PI——首次添加商品到购物车控制器模块(C)根据用户首次添加商品请求，调用购物车模块(D)，为顾客创建购物车会话实例；从仓库模块(B)获取商品信息并添加到购物车模块(D);P2——添加商品到购物车控制器模块(C)根据用户添加商品请求，从仓库模块(B)获取商品信息并添加到购物车模块(D);P3——从购物车移除商品控制器模块(C)根据用户移除商品请求，从购物车模块(D)中移除商品，并将移除商品数量信息返回仓库模块(B);P4——提交购物车控制器模块(C)根据用户提交购物车请求，向订单模块(E)提交购物车模块(D)中购物车会话实例中的商品、顾客模块(D)中顾客会话实例中的顾客信息，创建用户订单，商品提交后，购物车会话实例清空；P5——顾客退出系统控制器模块(C)根据用户请求，调用顾客模块(A)删除顾客会话实例和调用购物车模块(D)删除购物车会话实例。步骤三，从模块集合和模块间的调用关系抽象出故障点AE五个模块分别抽象为五个单模块故障点FaFe。控制器模块C对顾客模块A的控制登录验证创建顾客会话实例和登出删除顾客会话实例的调用逻辑抽象为模块调用故障点Fca;控制器模块C对仓库模块B的预占/取消预占商品调用逻辑抽象为模块调用故障点Feb;控制器模块C对购物车模块D的添加/移除商品、提交购物车方面购物车操作的调用逻辑抽象为模块调用故障点Fcdl;控制器模块C对购物车模块D的生成/删除购物车会话实例的调用逻辑抽象为模块调用故障点Fcd2控制器模块C对订单模块E的提交购物车生成订单的调用逻辑抽象为模块调用故障点Fee;步骤四，确定探测请求集合和故障点集合之间的依赖关系PO依赖单模块故障点Fa、Fc，依赖模块调用故障点Fca;Pl依赖单模块故障点Fb、Fc、Fd，依赖模块调用故障点Fcb、Fcd2;P2依赖单模块故障点Fb、Fc、Fd，依赖模块调用故障点Fcb、Fcdl;P3依赖单模块故障点Fb、Fc、Fd，依赖模块调用故障点Fcb、Fcdl;P4依赖单模块故障点Fa、Fc、Fd、Fe，依赖模块调用故障点Fca、FcdlPce;P4依赖单模块故障点Fa、Fc、Fd，依赖模块调用故障点Fca、Fcd2。歩骤五，建立扩展依赖矩阵根据所述探测请求集合与故障点集合之间的依赖关系，可以得出如下的扩展依赖模型。<table>tableseeoriginaldocumentpage19</column></row><table>(二)执行探测和故障推理分析一个购物车模块D的单模块故障点Fa发生故障的故障推理分析实施例如下所示执行所述探测请求集合后获取的探测结果集合为P0——成功，Pl——失败，P2——失败，P3——失败，P4——失败，P5——失败。步骤一过滤可能故障点。首先根据失败探测得到的Fs为《(Fa，2),(Fb,2)，(Fc,5),(Fd,5)，(Fe,l),(Fca,2),(Fcb,2),(Fcdl,3),(Fcd2,2),(Fce,l)}，接着根据成功探测依赖的故障点集合Ss为(Fa,Fc,Fca)，删除Fs中对应的故障点，所以故障过滤的最终结果Fs为{(Fb,2),(Fd,5),(Fe,l),(Fcb,2),(Fcdl,3),(Fcd2,2),(Fce，l)}。步骤二排序可能故障点。针对Fs为{(Fb,2),(Fd,5),(Fe,l),(Fcb，2),(Fcdl，3),(Fcd2,2)，(Fce,l)}，所以最终诊断结果Fq顺序为(Fd，5)，(Fcdl,3),(Fb，2),(Fcb，2)，(Fcd2,2),(Fe，l),(Fce,l)。因此，Fd发生故障的可能性最大，即模块D发生单模块故障的可能性最大，与前提购物车模块D的单模块故障点Fa发生故障一致。一个购物车模块D的模块调用故障点Fcdl发生故障的故障推理分析实施例如下执行所述探测请求集合后获取的探测结果集合为P0——成功，Pl——成功，P2——失败，P3——失败，P4——失败，P5——成功。步骤一过滤可能故障点。首先根据失败探测得到的Fs为《(Fa，l)，(Fb,2),(Fc,3),(Fd，3)，(Fe,l)，(Fca,2)，(Fcb,2),(Fcdl,3),(Fce，l)}接着根据成功探测依赖的故障点集合Ss为(Fa,Fc,Fd，Fca,Fcd2)，删除Fs中对应的故障点，所以故障过滤的最终结果Fs为{(Fb,2),(Fe,l),(Fcb,2),(Fcdl，3),(Fce,l)}。步骤二排序可能故障点。针对Fs为{(Fb,2),(Fe,l),(Fcb,2),(Fcdl,3)，(Fce,l)}，所以最终诊断结果Fq顺序为(Fcdl,3),(Fb,2),(Fcb,2),(Fe,l),(Fce,l)。Fcdl发生故障的可能性最大，与前提购物车模块D的模块调用故障点Fcdl发生故障一致。综合上述步骤，在一个具体电子商务网站中，针对一种购物车购物业务逻辑进行了的一次完整地建立扩展依赖矩阵模型、执行探测、故障分析推理的故障定位过程。在具体完整的Web应用系统应用层故障定位中，推理的基本原理与上述步骤相同，可根据本发明中提出的方法可以准确快速的进行故障定位。本发明的有益效果在于，首先，本发明提出的故障定位模型扩展依赖矩阵能够解决传统依赖矩阵探测和故障点不能形成确定性的关系(一个功能组件可能与多种故障或与多个故障相关)，故障诊断结果精度不高的情况，扩展了症状数据提供的推断依据，从而明显提高诊断的精确度。其次，本发明的故障定位方法是主动探测方式，不需要对所述系统进行改造或增加功能组件或系统状态数据传送链路来跟踪Web应用系统内部的消息，不需要额外的维护，具有实现代价较小，实施简单，易于维护的优点。另外，由于主动探测方式与被测的Web应用系统之间的独立性，能够快速适应Web业务逻辑的配置变化，同时在一定程度上保证症状数据的准确性，有利于故障定位的精确度，提高故障诊断的效率和准确性。以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。参考文献1MikeY.Chen，EmreKiciman,EugeneFratkin,ArmandoFox,EricBrewer:Pinpoint:problemdeterminationinlarge,dynamicInternetservices.ProceedingsoftheInternationalConferenceonD印endableSystemsandNetworks(DSN'02)IEEE,20022G—anKhanna,IgnacioLaguna，FahadA.Arshad,SaurabhBagchi:DistributedDiagnosisofFailuresinaThreeTierE-CommerceSystem.26thIEEEInternationalSymposiumonReliableDistributedSystems3DOppenheimer,AGanapathi,DAPatterson:whydointernetservicesfailandwhatcanbedoneaboutit.ProceedingsofUSITS'03:4thUSENIXSymposiumonInternettechnologiesandSystemsSeattle,WA,USAMarch26—28,20034IrinaRish，MarkBrodie，ShengMa,NataliaOdintsova,AlinaBeygelzimer，GenadyGrabarnik，KarinaHernandez:Adaptivediagnosisindistributedsystems.IEEETransactionsonneuralnetworks,vol.16,NO.5，September200权利要求1.一种Web应用系统的故障定位方法，其特征在于该方法包括建立扩展依赖矩阵模型步骤抽象出系统中所有的故障点和可用探测，并确定所述故障点和所述探测之间的对应关系，建立扩展依赖矩阵进行描述。执行探测步骤向目标Web应用系统发送探测请求，并分析返回结果，确定探测执行成功或失败，得出探测结果集合，作为故障推理分析的症状数据。故障推理分析步骤基于扩展依赖矩阵模型和症状数据探测结果集合，失败探测相关的故障点过滤为可能发生故障的故障点；成功探测相关的故障点排除发生故障的可能性。对所述过滤得出的故障点集合，分析每个故障的可能性大小，按从大到小的顺序进行排列。2.根据权利要求1所述的一种Web应用系统的故障定位方法，其特征在于，所述建立扩展依赖矩阵模型步骤包括获取功能模块集合歩骤获取Web应用系统的功能模块集合，各个模块之间相互独立。罗列探测请求集合步骤罗列所有可用的探测请求集合，各个探测之间相互独立，探测请求集合需尽可能覆盖所有的模块和模块之间的调用关系。抽象故障点步骤从模块集合和模块间的调用关系分别抽象出单模块故障点和模块调用故障点。故障点之间相互独立，每个故障点具有两个独立状态发生故障或没有故障。确定探测请求集合和故障点集合之间的依赖关系步骤探测根据其实现的业务逻辑，总是固定地依赖于提供该业务逻辑的相关功能模块，而和其他模块无关。此时，确定所述探测与所述功能模块对应的故障点存在依赖关系。建立扩展依赖矩阵步骤根据探测请求集合与故障点依赖关系，建立扩展依赖矩阵。3.根据权利要求2所述的一种Web应用系统的故障定位方法，其特征在于，所述各个模块之间相互独立是指模块内部封装实现系统部分业务逻辑功能，具有独立的状态，对外仅提供有限的接口调用或者通过标准的消息中间件来实现模块间交互。4.根据权利要求2所述的一种Web应用系统的故障定位方法，其特征在于，所述探测是指在Web应用系统中，客户端发起一次Web业务请求，服务器端对该Web业务请求事件进行处理并向客户端返回结果的一次端到端的完整交互。如果一次探测交互返回的结果符合系统的业务逻辑设计，则认定探测成功，否则认定探测失败。所述各个探测之间相互独立是指任意探测A的成功或失败不依赖于任意B探测，而仅与提供所述A探测业务逻辑的功能模块相关。即任一探测无论其执行结果如何，不会改变系统的后续行为。所述探测请求集合是指针对一个具体的Web应用系统，实际用户可以向Web应用系统发出所有可能的Web请求。5.根据权利要求2所述的一种Web应用系统的故障定位方法，其特征在于，所述单模块故障点对应的单模块故障是指某个模块发生内部逻辑故障，使得任意其他模块对它的调用都会失败。Web应用系统相互独立的功能模块映射为单模块故障点。所述模块调用故障点对应的模块调用故障是指某个模块的发生某个对外调用或被调用故障，使得特定模块对其调用或被调用失败。模块间调用关系映射为模块调用故障点。当两个模块之间存在不同的调用关系时，即一个模块以不同的方式调用另一个模块，则对每种调用关系都抽象成模块调用故障点。6.根据权利要求2所述的一种Web应用系统的故障定位方法，其特征在于，所述扩展依赖矩阵由探测请求集合与故障点集合构成，故障点集合包括所有的单模块故障点和模块调用故障点，矩阵取值为存在依赖和无依赖。7.根据权利要求1所述的一种Web应用系统的故障定位方法，其特征在于，所述故障推理分析步骤包括初始化故障过滤结果步骤初始化一个二维过》虑输出结果FS，将第一维故障点设为空，第二维计数器Cf清零，初始化一个成功探测依赖故障点集合Ss为空；判断探测结果集合歩骤，判断探测结果集合Ps是否为空，如果为空则返回失败探测过滤结果Fs'(Fs的中间结果)，否则从探测结果集合Ps中取出一个探测结果P;判断探测结果步骤，判断探测结果P是否为成功探测，如果为是则根据扩展依赖矩阵模型，将P依赖的故障点加入到Ss，否则根据扩展依赖矩阵模型，将P依赖的故障点加入Fs，每个故障点对应计数器加1;删除探测结果歩骤，将P从探测结果集合Ps中删除，并继续判断探测结果隹A.朱口；8.根据权利要求7所述的一种Web应用系统的故障定位方法，其特征在于，所述故障推理分析步骤还包括判断成功探测依赖故障点集合步骤，判断成功探测依赖故障点集合Ss是否为空，如果为是则将失败探测过滤结果Fs'作为故障过滤结果Fs返回；否则从成功探测依赖故障点集合Ss中取出一个故障点F，将失败探测过滤结果Fs'中对应取值为F的故障点清空，对应计数器清零；删除成功探测步骤，将F从成功探测依赖故障点集合Ss中删除，并继续判断成功探测依赖故障点集合；9.根据权利要求8所述的一种Web应用系统的故障定位方法，其特征在于，所述故障推理分析步骤还包括初始化故障排序结果步骤，初始化一个二维排序结果队列Fq，将第一维故障点设为空，第二维失败探测数Cq清零；判断故障过滤结果步骤，判断故障过滤结果Fs是否为空，如果为空则返回故障排序队列Fq，否则在Fs屮选取一个计数器Cf值最大的故障点F，把该故障点F加入Fq队尾，并采用Cf对Cq赋值；删除故障点步骤，在Fs中删除将该故障点F，对应计数器Cf清零，并继续判断故障过滤结果。全文摘要一种Web应用系统的故障定位方法，包括建立扩展依赖矩阵模型步骤抽象出系统中所有的故障点和可用探测，并确定所述故障点和所述探测之间的对应关系，建立扩展依赖矩阵进行描述；执行探测步骤向目标Web应用系统发送探测请求，并分析返回结果，确定探测执行成功或失败，得出探测结果集合，作为故障推理分析的症状数据；故障推理分析步骤基于扩展依赖矩阵模型和症状数据探测结果集合，失败探测相关的故障点过滤为可能发生故障的故障点；成功探测相关的故障点排除发生故障的可能性。对所述过滤得出的故障点集合，分析每个故障的可能性大小，按从大到小的顺序进行排列。文档编号H04L29/08GK101394314SQ20081011997公开日2009年3月25日申请日期2008年10月20日优先权日2008年10月20日发明者峰亓,刘会永,孟洛明,璐成,颖王,邱雪松,龙会湖申请人:北京邮电大学