一种基于端到端的应用系统故障定位方法及装置与流程

本发明涉及计算机网络系统的性能监测和维护技术，具体涉及一种基于端到端的应用系统故障定位方法及装置。

背景技术：

计算机网络系统，一般包括安装应用程序的客户端(简称客户端)和应用系统所在的应用服务器端(简称服务器端)，客户端和服务器端就组合成常见的基于端到端的应用系统。其中的客户端可以是基于b/s模型的浏览器，也可以是基于c/s模型的客户(client)端软件，还可以是现有的基于移动终端的应用(app)客户端；而服务器端除了内部设置有主程序外，绝大多数都还设置有数据库，数据库也可称之为数据库端。

当前的基于端到端的应用系统存在故障频发、故障定位困难的问题，业界给出了很多解决方案，但是，解决方案大都侧重在对服务器端软件的性能监控及日志数据收集，而服务器端软件的性能监控一般都是基于单节点的监控，即：在客户端、服务器端和数据库端各部署一个独立的应用或监控系统，中间的网络部署及底层的物理机部分也分别选择独立的监控。但是，由于每个节点的应用或监控系统涉及到不同的厂商，数据的格式可能并不一致，性能出现问题时，由于数据孤岛的原因，无法实现数据的连贯分析，往往需要逐个节点的排查，并且诊断的结果会出现各个系统节点对故障定位说法不一，故障位置难以快速准确找到，不能支持基于一个具体的业务关联的多个节点的性能故障的联合诊断。

随着基于端到端的应用系统的设计向着基于web的分布式系统发展、移动设备的大量出现和业务竞争越来越激烈的现状，使得争夺业务的流量入口变得 愈发重要，进而使得计算机网络系统更关注用户的使用体验。但故障定位困难的问题，会大大降低用户的使用体验。因此，故障定位困难的问题，是亟待解决的问题。

技术实现要素：

有鉴于此，本发明实施例期望提供一种基于端到端的应用系统故障定位方法及装置，能快速准确地找到故障位置，提高用户的使用体验。

为达到上述目的，本发明的技术方案是这样实现的：

本发明实施例提供了一种基于端到端的应用系统故障定位方法，所述方法包括：

客户端发起任务请求后，记录任务完成过程中各个执行环节的响应时间；

根据所述各个执行环节的响应时间，确定所述各个执行环节的任务性能状况；

根据所述任务性能状况，提取任务性能状况差的执行环节的异常事件数据，确定故障原因和位置。

优选的，所述各个执行环节的响应时间，包括：

所述客户端发起的请求到达服务器端的时间；

服务器端接收所述客户端的任务请求后到与所述数据库开始交互的时间；

所述数据库端与所述服务器端开始交互后到开始向所述服务器端反馈数据的时间；

所述服务器端接收所述数据库端反馈的数据后到开始向客户端发送的时间；

所述服务器端向客户端发送的数据全部加载到客户端的时间。

优选的，所述方法还包括：

所述客户端发起任务请求后，在服务器启动前，加载web代理程序；

当客户端访问服务器端时，所述服务器探测到所述客户端的联络信息后，将js脚本注入到客户端展示层，跟踪到客户端的请求任务类型；

识别每一个客户端请求标记，并在服务器端增加新的标记，标示服务器端的任务逻辑处理的开始时间；

服务器端与数据库端交互时，标记和数据库交互的开始时间，并标记数据库端将该任务处理完后将数据反馈至服务器端的时间。

优选的，所述根据所述各个执行环节的响应时间，确定所述各个执行环节的任务性能状况，包括：

通过以下三种方法的任一种或其任意组合，来确定所述各个执行环节的任务性能状况：

设置响应时间阈值，对所述各个执行环节的响应时间大于预设阈值的任务，确定为性能状况差；

采集同一任务在多次执行中的多个响应时间，计算应用性能指数，对小于预设阈值的任务，确定为性能状况差；

采集同一任务在多次执行中的多个响应时间，计算算术平均值，将偏离所述算术平均值一定值的任务，确定为性能状况差。

优选的，所述提取所述任务性能状况差的执行环节的异常事件数据，包括提取下述数据中的异常事件数据：

客户端的页面端的渲染质量数据和网络加载传输质量数据；

或服务器端的应用系统的调用数据、应用系统和数据库系统的交互数据、应用系统和其他系统的交互数据；

或数据库端的自身性能质量指标和运行状态数据、支持数据库运行的操作系统性能指标数据。

优选的，所述方法还包括：

预先在客户端的页面展示层，植入常规的js脚本代码，来跟踪应用的请求任务类型及检查页面端的渲染质量数据和网络加载传输质量数据；

预先在服务器端部署所述web代理程序，获取应用系统的调用数据、获取应用系统和数据库系统的交互数据以及应用系统和其他系统的交互数据；

预先在数据库端部署数据库代理程序，获取数据库本身的性能质量指标和 运行状态数据、支持数据库运行的操作系统性能指标数据。

本发明实施例还提供了一种基于端到端的应用系统故障定位装置，所述装置包括时间记录模块、性能状况确定模块和故障定位模块；其中，

所述时间记录模块，用于客户端发起任务请求后，记录任务完成过程中各个执行环节的响应时间；

所述性能状况确定模块，用于根据所述各个执行环节的响应时间，确定所述各个执行环节的任务性能状况；

所述故障定位模块，用于根据所述任务性能状况，提取任务性能状况差的执行环节的异常事件数据，确定故障原因和位置。

优选的，所述时间记录模块具体用于，记录各个执行环节的响应时间，包括：

所述客户端发起的请求到达服务器端的时间；

所述服务器端接收所述客户端的任务请求后到与所述数据库开始交互的时间；

所述数据库端与所述服务器端开始交互后到开始向所述服务器端反馈数据的时间；

所述服务器端接收所述数据库端反馈的数据后到开始向客户端发送的时间；

所述服务器端向客户端发送的数据全部加载到客户端的时间；

所述时间记录模块还包括执行如下任务：

所述客户端发起任务请求后，在服务器启动前，加载web代理程序；

当客户端访问服务器端时，所述服务器探测到所述客户端的联络信息后，将js脚本注入到客户端展示层，跟踪到客户端的请求任务类型；

识别每一个客户端请求标记，并在服务器端再增加一个新的标记，以标示服务器端的任务逻辑处理的开始时间；

服务器端与数据库端交互时，标记和数据库交互的开始时间，再标记数据库端将该任务处理完后将数据反馈至服务器端的时间。

优选的，所述性能状况确定模块具体用于：通过以下三种方法的任一种或其任意组合，来确定所述各个执行环节的任务性能状况：

设置响应时间阈值，对所述各个执行环节的响应时间大于预设阈值的任务，确定为性能状况差；

采集同一任务在多次执行中的多个响应时间，计算应用性能指数，对小于预设阈值的任务，确定为性能状况差；

采集同一任务在多次执行中的多个响应时间，计算算术平均值，将偏离所述算术平均值一定值的任务，确定为性能状况差。

优选的，所述故障定位模块具体用于：对性能状况差的任务，提取如下数据中的异常事件数据：

客户端的页面端的渲染质量数据和网络加载传输质量数据；

或服务器端的应用系统的调用数据、应用系统和数据库系统的交互数据、应用系统和其他系统的交互数据；

或数据库端的自身性能质量指标和运行状态数据、支持数据库运行的操作系统性能指标数据；

所述故障定位模块还用于：

预先在客户端的页面展示层，植入常规的js脚本代码，来跟踪应用的请求任务类型及检查页面端的渲染质量数据和网络加载传输质量数据；

预先在服务器端部署所述web代理程序，获取应用系统的调用数据、获取应用系统和数据库系统的交互数据以及应用系统和其他系统的交互数据；

预先在数据库端部署数据库代理程序，获取数据库本身的性能质量指标和运行状态数据、支持数据库运行的操作系统性能指标数据。

通过上述技术方案，本发明实施例提供的基于端到端的应用系统故障定位方法及装置，客户端发起任务请求后，记录任务完成过程中各个执行环节的响应时间；根据所述各个执行环节的响应时间，确定所述各个执行环节的任务性能状况；根据所述任务性能状况，提取任务性能状况差的执行环节的异常事件数据，确定故障原因和位置；可见，本发明实施例根据客户端用户体验最明显 的响应时间这一指标来判断任务性能状况，直接提取任务性能状况差的执行环节的异常事件数据，这样，不用提取很多执行环节的详细数据，大大减轻了服务器端的工作负载；而且，也能快速准确的找到故障位置，提供更好的用户使用体检。

附图说明

图1为本发明实施例基于端到端的应用系统故障定位方法的实现流程示意图；

图2为本发明实施例基于端到端的应用系统故障定位方法中的各个执行环节的响应时间的示意图；

图3为本发明实施例基于端到端的应用系统故障定位装置的示意图。

具体实施方式

下面将结合附图及具体实施例对本发明再做进一步的说明。

如图1所示，本发明实施例的一种基于端到端的应用系统故障定位方法，包括：

步骤101：客户端发起任务请求后，记录任务完成过程中各个执行环节的响应时间；

这里，所述客户端可以是基于b/s模型的浏览器，也可以是基于c/s模型的客户端软件，还可以是现有的基于移动终端的app客户端；

所述任务为一个业务中的一个独立的进程，例如网购是一个业务，则用户登录、选择商品、下单和付款等均是其中的一个任务。

本发明实施例中，任务的执行会涉及到客户端、服务器端和数据库端；其中，所述服务器端是为所述客户端的应用程序提供服务的应用系统所在的应用服务器端；所述客户端和服务器端通过网络连接，可以是局域网连接，也可以是广域网连接；而服务器端除了内部设置有主程序外，还设置有数据库，数据 库也可称之为数据库端。

这里的执行环节，是指客户端到服务器端、服务器端到数据库端等的交互及处理环节，其中数据库端由于处理时间比较长，所以数据库端内部的处理过程也是一个执行环节，各个执行环节之间是连续的，没有其它间隔和停留时间。

具体的，本步骤中，所述各个执行环节的响应时间，如图2所示，包括：

所述客户端发起的请求到达服务器端的时间21；

所述服务器端接收所述客户端的任务请求后到与所述数据库开始交互的时间22；

所述数据库端与所述服务器端开始交互后到开始向所述服务器端反馈数据的时间23；

所述服务器端接收所述数据库端反馈的数据后到开始向客户端发送的时间24；

所述服务器端向客户端发送的数据全部加载到客户端的时间25；

这样，也就可以知道任务完成的总时间，即：完成任务的总时间＝时间21+时间22+时间23+时间24+时间25。

为了对上述的时间了解的更清楚，也可以将完成任务的总时间表示为以下三个：

客户端请求的网络传输时间：所述客户端发起的请求到达服务器端的时间+所述服务器端向客户端发送的数据全部加载到客户端的时间；

服务器端的任务处理时间：服务器端接收所述客户端的任务请求后到与所述数据库开始交互的时间+所述服务器端接收所述数据库端反馈的数据后到开始向客户端发送的时间；

数据库端的响应及处理时间：所述数据库端与所述服务器端开始交互后到开始向所述服务器端反馈数据的时间。

更进一步的，为了准确记录上述时间，步骤101还包括：

所述客户端发起任务请求时，在服务器启动前，加载代理应用程序；

当客户端访问服务器端时，所述服务器探测到所述客户端的联络信息后， 将js脚本注入到客户端展示层，跟踪到客户端的请求任务类型；

识别每一个客户端请求标记，并在服务器端再增加一个新的标记，标示服务器端的任务逻辑处理的开始时间；

服务器端与数据库端交互时，标记和数据库交互的开始时间，再标记数据库端将该任务处理完后将数据反馈至服务器端的时间。

其中，服务器探测所述客户端的联络信息，为通过tcp信号探测到所述客户端的联络信息，所述联络信息为客户端的ip地址及随机端口。

步骤102：根据所述各个执行环节的响应时间，确定所述各个执行环节的任务性能状况；

目前常用的度量应用系统性能状况的方法有两种：

a.基于单个节点的资源使用情况的定量分析；

b.基于任务响应时间的定量分析。

具体的，基于单个节点的资源使用情况的定量分析，涉及的分析指标比较多，举例如下：

1)前端的入口处，主要指标包括：并发用户请求数量；用户在线数量；用户请求行为；前端页面的研发质量，每一个页面窗口的加载等性能；用户请求业务类型等；

2)业务处理端的性能指标包括：应用程序的代码质量；应用程序的配置运行模型；应用程序与数据库之间的交互质量；代码逻辑；网络配置对系统的性能影响；服务器硬件配置对性能的影响等；

3)后端数据库的性能指标包括：数据库事务处理的性能；数据库本身的优化模型及配置模型对性能的影响；数据库所在操作系统对性能的配置影响；网络配置对性能的影响等。

但从基于任务响应时间的定量分析来看，涉及的指标只有一个，即响应时间，响应时间能将上面的所有指标的性能集中展示出来。

而且，从客户端用户的角度看待应用系统性能状况，客户端用户对应用系统的性能状况的度量采用的是定性分析，影响定性的主要指标是响应时间，即： 依据对应用系统使用的响应时间快慢来判断应用系统的好与差。也就是基于任务响应时间的定量分析，能更好的测量客户端用户体验。

所以，本发明实施例采用任务响应时间来确定所述各个执行环节的任务性能状况；这样，比基于单个节点的资源使用情况，更节省资源，能更快速准确地找到故障位置，也能更好的测量客户端用户体验。

本发明实施例中，基于任务响应时间来定量分析的方法可以采用以下三种方法中的任一种或其任意组合：

第一种方法是预先设置响应时间阈值，对获取的响应时间大于预设阈值的任务，确定为任务性能状况差；

进一步的，可根据实际测试，预先设置响应时间和任务性能状况的对应关系；具体可根据网络和任务类型，模拟实际使用环境进行一些测试，再根据测试结构设置响应时间和任务性能状况的对应关系，如：响应时间小于3秒，设置为满意，确定为任务性能状况好；响应时间在3～12秒之间，设置为容忍，确定为任务性能状况一般；响应时间大于12秒，设置为失望，确定为任务性能状况差；这里，可将12秒设置为响应时间阈值。

第二种方法是使用应用性能指数(apdex，applicationperformanceindex)：采集同一任务在多次执行中的多个响应时间，计算应用性能指数；

设置应用性能指数阈值，对小于预设阈值的任务，确定为性能状况差。

这里，apdex联盟是一个由众多网络分析技术公司和测量工业组成的联盟组织，它们联合开发了应用性能指数，应用性能指数是用户对应用性能满意度的量化值，应用性能指数提供了一种统一的测量和报告用户体验的方法，将用户的体验和应用性能联系在一起。对应用性能指数的具体计算方法属于本领域的现有技术，在此不再赘述。

其中，应用性能指数的计算值所对应的含义如下：0.94～1为优异；0.85～0.94为好；0.7～0.85为一般；0.5～0.7为差；0.5以下为无法接受；这里，可设置0.5为应用性能指数阈值。

进一步的，可根据网络和任务类型，设置应用性能指数与任务性能状况的 对应关系，如将应用性能指数小于0.5确定为性能状况差。

第三种方法是借助统计学的原理：采集同一任务在多次执行中的多个响应时间，计算算术平均值，将偏离所述算术平均值一定值的任务，确定为性能状况差；

具体的，计算算术平均值的步骤：

假设有一组数值x1，x2,x3,......xn(x1表示一个任务第一次执行的响应时间，x2表示该任务第二次执行的响应时间，以此类推，xn表示该任务第n次执行的响应时间)，设所述任务的响应时间的算术平均值为μ，则得到：

为了更科学的反映该任务响应时间的波动情况和波动范围，进一步计算响应时间的标准差，设标准差为σ，则得到：

根据6σ的统计学原理，可知：

(μ-σ<x≤μ+σ)＝68.3％(3)

(μ-2σ<x≤μ+2σ)＝95.4％(4)

(μ-3σ<x≤μ+3σ)＝99.7％(5)

可见，在同一任务中，绝大多数的响应时间与所述算术平均值的偏差都在2σ内；因此，本发明实施例将响应时间与所述算术平均值的偏差超过2σ的任务确定为性能状况差。

进一步的，上述三种定量分析的方法，在实际使用中，还是有一定的区别的，第一种方法比较简单，可使用在很小或在测试阶段的应用系统，并且访问业务比较少，响应时间的数据呈离散分布；第三种方法则建议使用在比较大的应用系统，访问业务非常多且没有间断，响应时间的数据比较连续，这样统计出的数据比较准确；而第二种方法则介于两者之间。

本发明实施例中，上述响应时间指的是一个执行环节的响应时间，如果某个执行环节的响应时间异常，直接提取该环节的异常事件数据，能更快的找到故障原因和位置；

如果有多个执行环节的响应时间均异常，则首先提取与服务器端有关的执行环节的异常事件数据。

另外，在所有执行环节的响应时间都正常的情况下，还需要对完成该任务的总时间再做定量分析，因为理论上，多个执行环节的小问题累积起来，对完成该任务的总时间可能就是一种异常，即：执行任务过程中总的响应时间异常；针对完成任务的总时间的异常，就需要提取所有的执行环节的异常事件数据，可以先提取与服务器端有关的执行环节的异常事件数据，也可以先提取各个执行环节中响应时间相对更长的执行环节。

步骤103：根据所述任务性能状况，提取任务性能状况差的执行环节的异常事件数据，确定故障原因和位置。

根据所述任务性能状况，提取异常事件数据，这样就比较有目的性和针对性，例如，如果时间23响应时间长，就直接提取数据库端的异常事件数据，这样就不需要提取所有执行环节的异常事件数据，减轻了服务器端的负载，也能更快的找到故障原因和位置。

通常，所述异常事件数据为通过预先设置在各终端的监控程序采集，根据这些数据判断执行环节的故障原因和位置；这里，所述终端包括服务器端、客户端、数据库端，还包括中间的网络部署及底层的物理机部分；

本发明实施例中，优先提取的数据包括：

客户端的页面端的渲染质量数据和网络加载传输质量数据；

服务器端的应用系统的调用数据、应用系统和数据库系统的交互数据、应用系统和其他系统的交互数据；

数据库端的自身性能质量指标和运行状态数据、支持数据库运行的操作系统性能指标数据。

进一步的，上述数据中还包括：对判断故障位置有重要帮助的用户请求的 时间、任务类型等客户端访问行为，应用系统的异常事件、网络的异常事件以及与整个应用系统的性能状况相关的异常事件。

本发明实施例中，预先设置在所述终端的监控程序，包括：

预先在客户端的页面展示层植入常规的js脚本代码，来跟踪应用的请求任务类型及检查页面端的渲染质量数据和网络加载传输质量数据；

预先在服务器端部署web代理程序，获取应用系统的调用数据、获取应用系统和数据库系统的交互数据、以及应用系统和其他系统的交互数据；

预先在数据库端部署数据库代理程序，获取数据库本身的性能质量指标和运行状态数据、支持数据库运行的操作系统性能指标数据。

更具体的，所述web代理程序为webtracker程序，所述数据库代理程序为dbtracker程序。

如图3所示，本发明实施例的一种基于端到端的应用系统故障定位装置，包括：时间记录模块31、性能状况确定模块32和故障定位模块33；其中，

所述时间记录模块31，用于客户端发起任务请求后，记录任务完成过程中各个执行环节的响应时间；

这里，所述客户端可以是基于b/s模型的浏览器，也可以是基于c/s模型的客户端软件，还可以是现有的基于移动终端的app客户端；

所述任务为一个业务中的一个独立的进程，例如网购是一个业务，则用户登录、选择商品、下单和付款等均是其中的一个任务。

本发明实施例中，任务的执行会涉及到客户端、服务器端和数据库端；其中，所述服务器端是为所述客户端的应用程序提供服务的应用系统所在的应用服务器端；所述客户端和服务器端通过网络连接，可以是局域网连接，也可以是广域网连接；而服务器端除了内部设置有主程序外，还设置有数据库，数据库也可称之为数据库端。

这里的执行环节，是指客户端到服务器端、服务器端到数据库端等的交互环节，其中数据库端由于处理时间比较长，所以数据库端内部的处理过程也是一个执行环节，各个执行环节之间是连续的，没有其它间隔和停留时间。

具体的，所述各个执行环节的响应时间，如图2所示，包括：

所述客户端发起的请求到达服务器端的时间21；

所述服务器端接收所述客户端的任务请求后到与所述数据库开始交互的时间22；

所述数据库端与所述服务器端开始交互后到开始向所述服务器端反馈数据的时间23；

所述服务器端接收所述数据库端反馈的数据后到开始向客户端发送的时间24；

所述服务器端向客户端发送的数据全部加载到客户端的时间25；

这样，也就可以知道任务完成的总时间，即：完成任务的总时间＝时间21+时间22+时间23+时间24+时间25。

为了对上述的时间了解的更清楚，也可以将完成任务的总时间表示为以下三个：

客户端请求的网络传输时间：所述客户端发起的请求到达服务器端的时间+所述服务器端向客户端发送的数据全部加载到客户端的时间；

服务器端的任务处理时间：服务器端接收所述客户端的任务请求后到与所述数据库开始交互的时间+所述服务器端接收所述数据库端反馈的数据后到开始向客户端发送的时间；

数据库端的响应及处理时间：所述数据库端与所述服务器端开始交互后到开始向所述服务器端反馈数据的时间。

更进一步的，为了准确记录上述时间，时间记录模块还用于：

所述客户端发起任务请求时，在服务器启动前，加载web代理程序；

当客户端访问服务器端时，所述服务器探测到所述客户端的联络信息后，将js脚本注入到客户端展示层，跟踪到客户端的请求任务类型；

识别每一个客户端请求标记，并在服务器端再增加一个新的标记，标示服务器端的任务逻辑处理的开始时间；

服务器端与数据库端交互时，标记和数据库交互的开始时间，再标记数据 库端将该任务处理完后将数据反馈至服务器端的时间。

其中，服务器探测所述客户端的联络信息，为通过tcp信号探测到所述客户端的联络信息，所述联络信息为客户端的ip地址及随机端口

所述性能状况确定模块32，用于根据所述各个执行环节的响应时间，确定所述各个执行环节的任务性能状况；

目前常用的度量应用系统性能状况的方法有两种：

a.基于单个节点的资源使用情况的定量分析；

b.基于任务响应时间的定量分析。

具体的，基于单个节点的资源使用情况的定量分析，涉及的分析指标比较多，举例如下：

1)前端的入口处，主要指标包括：并发用户请求数量；用户在线数量；用户请求行为；前端页面的研发质量，每一个页面窗口的加载等性能；用户请求业务类型等；

2)业务处理端的性能指标包括：应用程序的代码质量；应用程序的配置运行模型；应用程序与数据库之间的交互质量；代码逻辑；网络配置对系统的性能影响；服务器硬件配置对性能的影响等；

3)后端数据库的性能指标包括：数据库事务处理的性能；数据库本身的优化模型及配置模型对性能的影响；数据库所在操作系统对性能的配置影响；网络配置对性能的影响等。

但从基于任务响应时间的定量分析来看，涉及的指标只有一个，即响应时间，而且响应时间能将上面的所有指标的性能集中展示出来。

而且，从客户端用户的角度看待应用系统性能状况，客户端用户对应用系统的性能状况的度量采用的是定性分析，影响定性的主要指标是响应时间，即：依据对应用系统使用的响应时间快慢来判断应用系统的好与差。也就是基于任务响应时间的定量分析，能更好的测量客户端用户体验。

所以，本发明实施例采用任务响应时间来确定所述各个执行环节的任务性能状况；这样，比基于单个节点的资源使用情况，更节省资源，能更快速准确 地找到故障位置，也能更好的测量客户端用户体验。

本发明实施例中，基于任务响应时间来定量分析的方法可以采用以下三种方法中的任一种或其任意组合：

第一种方法是预先设置响应时间阈值，对获取的响应时间大于预设阈值的任务，确定为任务性能状况差；

进一步的，可根据实际测试，预先设置响应时间和任务性能状况的对应关系；具体可根据网络和任务类型，模拟实际使用环境进行一些测试，再根据测试结构设置响应时间和任务性能状况的对应关系，如：响应时间小于3秒，设置为满意，确定为任务性能状况好；响应时间在3～12秒之间，设置为容忍，确定为任务性能状况一般；响应时间大于12秒，设置为失望，确定为任务性能状况差；这里，可将12秒设置为响应时间阈值。

第二种方法是使用应用性能指数(apdex，applicationperformanceindex)：采集同一任务在多次执行中的多个响应时间，计算应用性能指数；

设置应用性能指数阈值，对小于预设阈值的任务，确定为性能状况差。

这里，apdex联盟是一个由众多网络分析技术公司和测量工业组成的联盟组织，它们联合开发了应用性能指数，应用性能指数是用户对应用性能满意度的量化值，应用性能指数提供了一种统一的测量和报告用户体验的方法，将用户的体验和应用性能联系在一起。对应用性能指数的具体计算方法属于本领域的现有技术，在此不再赘述。

其中，应用性能指数的计算值所对应的含义如下：0.94～1为优异；0.85～0.94为好；0.7～0.85为一般；0.5～0.7为差；0.5以下为无法接受；这里，可设置0.5为应用性能指数阈值。

进一步的，可根据网络和任务类型，设置应用性能指数与任务性能状况的对应关系，如将应用性能指数小于0.5确定为性能状况差。

第三种方法是借助统计学的原理：采集同一任务在多次执行中的多个响应时间，计算算术平均值，将偏离所述算术平均值一定值的任务，确定为性能状况差；

具体的，计算算术平均值的步骤：

假设有一组数值x1,x2,x3,......xn(x1表示一个任务第一次执行的响应时间，x2表示该任务第二次执行的响应时间，以此类推，xn表示该任务第n次执行的响应时间)，设所述任务的响应时间的算术平均值为μ，则得到表达式(1)。

为了更科学的反映该任务响应时间的波动情况和波动范围，进一步计算响应时间的标准差，设标准差为σ，则得到表达式(2)。

根据6σ的统计学原理，可知表达式(3)、(4)、(5)。

可见，在同一任务中，绝大多数的响应时间与所述算术平均值的偏差都在2σ内；因此，本发明实施例将响应时间与所述算术平均值的偏差超过2σ的任务确定为性能状况差。

进一步的，上述三种定量分析的方法，在实际使用中，还是有一定的区别的，第一种方法比较简单，可使用在很小或在测试阶段的应用系统，并且访问业务比较少，响应时间的数据呈离散分布；第三种方法则建议使用在比较大的应用系统，访问业务非常多且没有间断，响应时间的数据比较连续，这样统计出的数据比较准确；而第二种方法则介于两者之间。

本发明实施例中，上述响应时间指的是一个执行环节的响应时间，如果某个执行环节的响应时间异常，直接提取该环节的异常事件数据，能更快的故障定位；

如果有多个执行环节的响应时间均异常，则首先提取与服务器端有关的执行环节的异常事件数据。

另外，在所有执行环节的响应时间都正常的情况下，还需要对完成该任务的总时间再做定量分析，因为理论上，多个执行环节的小问题累积起来，对完成该任务的总时间可能就是一种异常，即：执行任务过程中总的响应时间异常；针对这种异常，就需要提取所有的执行环节的异常事件数据，可以先提取与服务器端有关的执行环节的异常事件数据，也可以先提取各个执行环节中响应时间相对更长的执行环节。

所述故障定位模块33，用于根据所述任务性能状况，提取任务性能状况差 的执行环节的异常事件数据，确定故障原因和位置。

根据所述任务性能状况，提取异常事件数据，这样就比较有目的性和针对性，例如，如果时间23响应时间长，就直接提取数据库端的异常事件数据，这样就不需要提取所有执行环节的异常事件数据，减轻了服务器端的负载，也能更快的找到故障原因和位置。

通常，所述异常事件数据为通过预先设置在各终端的监控程序采集，根据这些数据判断执行环节的故障原因和位置；这里，所述终端包括服务器端、客户端、数据库端，还包括中间的网络部署及底层的物理机部分；

本发明实施例中，优先提取的数据包括：

客户端的页面端的渲染质量数据和网络加载传输质量数据；

服务器端的应用系统的调用数据、应用系统和数据库系统的交互数据、应用系统和其他系统的交互数据；

数据库端的自身性能质量指标和运行状态数据、支持数据库运行的操作系统性能指标数据。

进一步的，上述数据中还包括：对判断故障位置有重要帮助的用户请求的时间、任务类型等客户端访问行为，应用系统的异常事件、网络的异常事件以及与整个应用系统的性能状况相关的异常事件。

本发明实施例中，预先设置在所述终端的监控程序，包括：

预先在客户端的页面展示层植入常规的js脚本代码，来跟踪应用的请求任务类型及检查页面端的渲染质量数据和网络加载传输质量数据；

预先在服务器端部署web代理程序，获取应用系统的调用数据、获取应用系统和数据库系统的交互数据、以及应用系统和其他系统的交互数据；

预先在数据库端部署数据库代理程序，获取数据库本身的性能质量指标和运行状态数据、支持数据库运行的操作系统性能指标数据。

更具体的，所述web代理程序为webtracker程序，所述数据库代理程序为dbtracker程序。

在实际应用中，所述时间记录模块31、性能状况确定模块32和故障定位 模块33均可由位于服务器端的中央处理器(cpu)、微处理器(mpu)、数字信号处理器(dsp)、或现场可编程门阵列(fpga)等实现。

以上，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。