CN109933492A - 一种软件异常溯源方法、系统、设备及存储介质 - Google Patents

Abstract

本发明实施例公开了一种软件异常溯源方法、系统、设备及存储介质，涉及软件异常溯源技术领域，本发明实施例对各个关系数据库性能视图进行周期性数据扫描，并在扫描过程中根据事先设定的数据阀值判断扫描到的数据是否存在异常；一旦在这种周期性数据扫描中发现有性能数据出现异常，则第一时间触发针对这类异常的信息收集，这样就能保证在异常事件的开始阶段将需要的分析信息进行一次全面的收集；然后，再将收集回来信息以特定的算法进行加工，实现这类问题的直观的结论性分析。

Description

一种软件异常溯源方法、系统、设备及存储介质

技术领域

本发明涉及软件异常溯源技术领域，具体涉及一种软件异常溯源方法、系统、设备及存储介质。

背景技术

当前，在企业信息化建设与管理中，突发性的软件类问题往往是一个主要的管理痛点。对于企业来说，这一类问题总是难以确定问题的原因或责任方，原因主要有以下几点：

一、相当一部分软件类问题在事后是无法再重现的，这就造成分析问题缺少准确的可分析数据，造成诊断这类问题的原因往往是凭经验猜测，而猜测的结论是难以获得问题相关方认可的。

二、软件类问题的产生往往是多因素共同作用的结果，并不能简单认定某单一原因即为问题源。例如：最常见的堵塞类性能事件其产生的原因，往往是同时与业务程序的性能质量、当前的业务访问量或正在执行的某一特定操作都有关系。这种多因素共同作用的情况使得软件类问题的溯源要比硬件类问题复杂的多。

三、真正对业务造成影响的严重软件问题，会迅速造成系统死机或挂起，而进行原因分析的IT管理人员自身也将无法访问系统。更不用说查找原因了。

发明内容

本发明实施例的目的在于提供一种软件异常溯源方法、系统、设备及存储介质，用以解决目前软件类问题引起的异常无法准确溯源的问题。

为实现上述目的，本发明实施例提供了一种软件异常溯源方法，所述溯源方法包括：在预定短时间内对各个关系型数据库的性能视图信息进行周期性数据扫描；在周期性扫描过程中根据事先设定的数据阀值判断扫描到的数据是否存在异常；如果发现某一数据库的性能计数器或数据库状态信息异常，则第一时间触发针对此类异常事件的信息收集；将收集到的异常事件信息存放在后台数据库中；在使用者需要查看该类异常事件时，以针对此类异常事件的内置特定呈现算法进行异常事件溯源分析；及利用所述特定呈现算法匹配的特定呈现方法对此类异常事件的结论性溯源分析进行可视化展示。

进一步地，所述性能视图信息包括各类关系型数据库中的各项性能计数器详细记录的各项运行指标和数据库状态信息。

进一步地，所述第一时间触发针对此类异常事件的信息收集之前，还包括：根据发生异常的性能计数器或数据库状态信息判断异常事件类型。

进一步地，所述异常事件信息按照异常事件类型存放在后台数据库中不同的信息列表中。

进一步地，所述第一时间触发针对此类异常事件的信息收集通过触发开关的控制仅在发现异常事件的第一个扫描周期中触发一次针对此类异常事件信息的收集，其包括：记录每个扫描周期的触发开关的状态；发现某一数据库的性能计数器或数据库状态信息异常时，触发开关开启；触发开关开启时，检测前一扫描周期的触发开关的状态；如果前一扫描周期的触发开关关闭，则判断为发现异常事件的第一个扫描周期，触发一次针对此类异常事件的信息收集；及如果前一扫描周期的触发开关开启，则禁止触发再次针对此类异常事件的信息收集。

进一步地，所述异常事件类型包括：长时间锁等待事件/堵塞类事件、连接数激增事件、大资源占用的会话事件、大资源占用的SQL事件和程序解析量过大事件；所述异常事件类型、针对各类异常事件收集的性能视图信息、针对各类异常事件的呈现算法以及呈现方法的对应关系如下表所示：

本发明实施例的另外一方面，还提供的一种软件异常溯源系统，所述溯源系统包括：数据库扫描模块，用于在预定短时间内对各个关系型数据库的性能视图信息进行周期性数据扫描；异常监控模块，用于在周期性扫描过程中根据事先设定的数据阀值判断扫描到的数据是否存在异常；数据采集模块，用于在发现某一数据库的性能计数器或数据库状态信息异常的第一时间触发针对此类异常事件的信息收集；数据存储模块，用于将收集到的异常事件信息存放在后台数据库中；数据分析模块，用于在使用者需要查看该类异常事件时，以针对此类异常事件的内置特定呈现算法进行异常事件溯源分析；及可视化展示模块，用于利用所述特定呈现算法匹配的特定呈现方法对此类异常事件的结论性溯源分析进行可视化展示。

进一步地，所述数据采集模块包括：触发开关，用于在发现某一数据库的性能计数器或数据库状态信息异常时开启；触发开关状态记录单元，用于记录每个扫描周期的触发开关的开启状态；触发开关状态检测单元，用于在触发开关开启时检测前一扫描周期的触发开关的开启状态；和信息收集单元，用于前一扫描周期的触发开关关闭情况下触发一次针对此类异常事件的信息收集；及在前一扫描周期的触发开关开启情况下禁止触发再次针对此类异常事件的信息收集。

本发明实施例的另外一方面，还提供了一种计算机设备，所述设备包括：一个或多个处理器；存储器，用于存储一个或多个程序；当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上所述的方法。

本发明实施例的另外一方面，还提供了一种计算机存储介质，所述计算机存储介质存储有计算机程序指令，所述计算机程序指令用于执行如上所述的方法。

本发明实施例具有如下优点：

本发明实施例对各个关系数据库性能视图进行周期性数据扫描，并在扫描过程中根据事先设定的数据阀值判断扫描到的数据是否存在异常；一旦在这种周期性数据扫描中发现有性能数据出现异常，则第一时间触发针对这类异常的信息收集，这样就能保证在异常事件的开始阶段将需要的分析信息进行一次全面的收集；然后，再将收集回来信息以特定的算法进行加工，实现这类问题的直观的结论性分析。

附图说明

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

图1为本发明实施例提供的一种软件异常溯源系统的逻辑结构示意图。

图2为本发明实施例提供的一种软件异常溯源方法的流程框图。

图3为本发明实施例提供的第一时间触发针对此类异常事件的信息收集的流程框图。

图4为本发明实施例提供的长时间锁等待事件/堵塞类事件的一个示例的桑基图。

1-数据扫描模块、2-异常监控模块、3-数据采集模块、31-触发开关、32-触发开关状态记录单元、33-触发开关状态检测单元、34-信息收集单元、4-数据加工模块、5-指标比对模块、6-结果展示模块。

具体实施方式

以下由特定的具体实施例说明本发明的实施方式，熟悉此技术的人士可由本说明书所揭露的内容轻易地了解本发明的其他优点及功效，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例

软件类问题与硬件机能类问题有一点非常不同。软件类问题通常会有一个发展过程，问题一开始只是一个异常的征兆，然后逐步发展，当占用的资源达到一个临界点时，才会影响到系统运行，才会被使用者感知。比如，一次堵塞类问题一开始可能只是影响堵塞了两、三个系统进程，但5分钟后，超过100个进程被堵塞，这期间是有一个随时间的发展过程的。而硬件机能类问题发生通常是瞬时的，一个CPU在前1秒是好的，1秒钟后就坏了，这种变化是瞬时的。

本发明的基本原理是利用软件类问题存在一个发展过程的特征，参考图1，本发明实施例提供了一种软件异常溯源系统包括：数据库扫描模块1、异常监控模块2、数据采集模块3、数据加工模块4、指标比对模块5、结果展示模块6，其中，数据采集模块3包括触发开关31、触发开关状态记录单元32、触发开关状态检测单元33和信息收集单元34。

参考图2，本发明实施例提供了一种软件异常溯源方法包括：数据库扫描模块1在预定短时间内对各个关系型数据库的性能视图信息进行周期性数据扫描，性能视图信息包括各类关系型数据库中的各项性能计数器详细记录的各项运行指标和数据库状态信息，并将扫描数据发送至异常监控模块2；异常监控模块2在周期性扫描过程中根据事先设定的数据阀值判断扫描到的数据是否存在异常，并将异常监控结果发送至数据采集模块3；数据采集模块3在发现某一数据库的性能计数器或数据库状态信息异常的第一时间触发针对此类异常事件的信息收集，并将收集到的异常事件的信息发送至数据存储模块4；数据存储模块4将收集到的异常事件信息存放在后台数据库中；在使用者需要查看该类异常事件时，数据分析模块5从后台数据库中调取收集到的异常事件信息，以针对此类异常事件的内置特定呈现算法进行异常事件溯源分析，并将分析结果发送至可视化展示模块6；及可视化展示模块6利用特定呈现算法匹配的特定呈现方法对此类异常事件的结论性溯源分析进行可视化展示。

本发明实施例是针对业务类应用程序，异常监控模块2借助收集分析到的大量应用程序运行数据以及一系列指标，当被测试的软件符合这套指标时，说明该软件目前的状态是优良的。

具体地，本发明实施例中，异常监控模块2在周期性扫描过程中根据事先设定的数据阀值判断扫描到的数据是否存在异常，包括：首先对采集到的信息按照预先存放在算法库中的逻辑进行数据加工；然后利用加工过的数据与预先设置的各类关系型数据库对应的检测项指标的推荐值进行比对，其中，检测项指标即为事先设定的数据阀值。

本发明实施例是针对业务类程序系统的软件异常溯源方法，所谓业务类程序系统即通常被称为OLTP(On-Line Transaction Processing，联机事务处理)，OLTP旨在处理同时输入的成百上千的事务。这类系统的主要特点如下：并发性要求高并且严格的要求事务的完整、安全性；实时性要求高；支持大量并发用户定期添加和修改数据，每单个事务通常能够很快地完成，并且只需访问相对较少的数据。

本发明实施例的基本方法是借助对关系数据库性能视图中数据的定期采集，通过分析、比对实现程序性能质量的评估。当前，几乎所有行业的业务类程序系统，其业务数据源端均是关系型数据库，如Oracle数据库、Sqlserver数据库、DB2数据库、Mysql数据库等，这些关系型数据库在自身内存的性能视图中都会详细记录数据库各项运行指标和被程序访问的细节，并在一段时间内持续保存，即，性能视图信息包括各类关系型数据库中的各项性能计数器详细记录的各项运行指标和数据库状态信息，本发明实施例正是借助这些保存在数据库内存性能视图中的原始运行数据，通工加工分析，实现性能质量的评估的。

涉及到软件异常溯源的数据需要经过一次或多次的数据加工以使数据成为阅读的直观内容，本发明实施例采用了一级数据加工、二级数据加工和三级数据加工的三层次数据加工类型。即将获取到的大量目标数据库的原始运行数据进行时间切片、算法箍选等一系列数据加工，采样到的原始数据最多会进行三轮的箍选和加工，从而为软件前端的功能显示准备好直观明确的呈现内容，这使本发明实施例系统各项功能直观、便于专业和非专业人员阅读的核心关键。

一级数据加工：对采集到的原始数据进行时间切片，获得某一运行时间段内的信息数据的检测项指标。由于数据库性能视图中保存的大量性能统计数据均为累积计数器，即原始数值是从数据库启动以来累积计数的结果，而程序质量的分析往往是对某一运行时间段内的分析，因此，一级数据加工实际上是对这些累积计数器的时间切片工作。举例来说：程序若以一小时为一个采集周期，某日上午09:01采集的数据库性能视图中登录计数器值为100000，当一小时后，10:01再次采集时为101234，则一级数据加工实现的功能就是对这一个周期内登录数据的时间切片，即101234-100001＝1234，该值就是09:01～10:01这一时间区间内，数据库的登录总次数。

二级数据加工：主要功能是对一级加工后的数据进行各种算法计算，从而获得更为直观的信息，在二级数据加工中，不同的检测项指标，其加工的算法是完全不同的，这与一级数据加工不同，一级数据加工中，各种数据主要都是做时间切片。举例：在上例中，通过一级数据加工我们获得了9:01～10:01这一时间区间内的数据库登录总次数，而二级数据加工对这一指标的需求是计算一个时间区间内的每秒登录次数，如果一个时间区间为1小时(3600秒)，则计算公式为一个区间内数据库登录总次数/3600。

三级数据加工：部分指标数据，经过二级数据加工后仍可进一步加工已获得更直观的信息体现，例如：一部分时间区间内的命中率指标数据，需要在二级加工后的数据的基础上再进行一次计算才能得出，这时就会进行三级数据加工。三级数据加工就是对二级数据加工后的数据进行各种算法计算，从而获得直观的检测项指标。

总结来说，一级数据加工的工作就是对各种数据进行时间切片，这是由于各种数据库性能计数器都是累积值计数器决定的，所以要看某一时间区间内的数值就得做时间切片。而二、三级数据加工的目标都是使最终数据尽可能直观化，都是利用不同的算法对数据进行计算，如果二级加工后的数据还不够直观，那就再进行第三次数据加工。

本发明实施例最终形成的关系型数据库、检测项指标以及数据加工类型的对应关系如下表所示：

需要说明的是：上表是一个检测项指标全集。在面向不同厂商的关系型数据库时，这些检测项指标会稍有区别，即有些指标在某些数据库上是不存在或与另一种指标来体现的。

进一步地，检测项指标与推荐值及比对方法的对应关系如下表所示：

需要说明的是，推荐值适用于绝大多数程序应用，但并不是推荐值适用于所有的程序应用，一些业务类型特殊的程序，部分指标会稍有区别，所以只能叫推荐值。

本发明实施例对程序性能质量的评估是覆盖程序的整个生命周期的，软件程序的交付过程不同于实物产品，实物产品的交付可以在出厂前，简单增加一个质检环节来实现，即通过一次性的检测确定产品是否质检过关。但程序的交付往往是贯穿程序使用的整个生命周期的，每一次程序的升级或改造都可能带来新的问题，因此，对程序性能质量的评估和考核也应该覆盖程序的整个生命周期。

本发明实施例公开的溯源方法适用于业务类程序系统应用软件的全生命周期，具体来说，在业务类程序系统软件研发和运维的不同阶段，所述溯源方法有不同的着重点，其包括：开发后期/测试前期阶段，进行源程序性能质量评估，对源程序自身的执行逻辑和语句解析性能进行精确性能质量评估，确保实现程序代码自身的高质量；压力测试/试运行阶段，进行压力测试/试运行阶段性能质量评估，在前期源程序质量已优化的基础上，通过规范的程序压力测试或试运行，利用程序的执行逻辑、语句解析性能、查询性能和事务等待检测维度的各检测项指标，精确的评估出程序在预计的环境压力下的性能质量表现和系统资源需求；及实际运行阶段，进行实际生产环境性能质量评估，关注程序性能质量评估中的所有检查项进行持续的评估与观测，实现真实复杂环境下的持续优化调整。

进一步地，业务类程序系统应用软件的全生命周期的不同阶段与检测项指标之间的对应关系如下表所示：

其中，打勾项为该阶段重点检测指标。

本发明实施例是以结果为导向的性能评估方法。当前，各个行业所采用的各种软件质量评估和优化方法，本质上都是以过程为导向的，即通过严格的开发过程管理来验证程序开发的规范性和质量是否过关。这些方法并不能从结果上确定软件是否已达至较优化的水平，因此在现实中通过这些管理方法开发出来的软件常常与用户的真实体验相差甚远。软件的性能质量评估的结果毫无疑问应当与用户体验相一致或相接近，因此，本发明实施例中衡量性能质量的各个检测项指标，反映的是以用户体验相对应的各个维度。

进一步地，数据采集模块3在第一时间触发针对此类异常事件的信息收集之前，还包括：异常监控模块2根据发生异常的性能计数器或数据库状态信息判断异常事件类型。

进一步地，参考图3，在数据采集模块3第一时间触发针对此类异常事件的信息收集中，通过触发开关31的控制仅在发现异常事件的第一个扫描周期中触发一次针对此类异常事件信息的收集，其包括：异常监控模块2发现某一数据库的性能计数器或数据库状态信息异常时，触发开关31开启；此时，触发开关状态记录单元32将触发开关的开启状态记录在事件日志中，另外，触发开关状态记录单元32会记录每个扫描周期的触发开关的状态；触发开关状态检测单元33，在触发开关开启时，根据事件日志中记录的每个扫描周期的触发开关的状态，检测前一扫描周期的触发开关的开启状态，并将检测结果发送至信息收集单元34；如果前一扫描周期的触发开关关闭，信息收集单元34则判断为发现异常事件的第一个扫描周期，信息收集单元34触发一次针对此类异常事件的信息收集；及如果前一扫描周期的触发开关开启，信息收集单元34则禁止触发再次针对此类异常事件的信息收集。

上述第一时间触发针对此类异常事件的信息收集环节中，触发开关31的主要作用是确保对持续时间超过一个扫描周期的异常事件，只会在发现异常的第一个扫描周期中触发一次针对这类异常事件的信息收集，而不会在之后的每个连续检测到异常的扫描周期内再次触发信息收集。另外，如果在发现异常的第一个扫描周期之后，间隔若干扫描周期后，检测到的异常事件恢复正常，之后重新发现异常，根据上述判断逻辑，信息收集单元34则重新判断为发现异常事件的第一个扫描周期，此时，信息收集单元34再触发一次针对此类异常事件的信息收集。

各种软件类问题遵循以上流程实现信息的收集、存放和展现，但不同类型的异常事件，其对应要收集的性能视图信息、存放位置、针对各类异常事件的呈现算法以及呈现方法是不一样，其中，关于存放位置，数据存储模块4将异常事件信息按照异常事件类型存放在后台数据库中不同的信息列表中，下表体现了主要几类异常事件在收集、呈现算法以及呈现方法上的差别：

异常事件分类处理表

以下本发明实施例以长时间锁等待事件/堵塞类事件为例描述一下针对异常事件的信息采集、存储和呈现的方法。在预定短时间(如每分钟一次)内周期性扫描各个关系型数据库性能视图中的各项性能计数器和状态信息；在周期性扫描中，一旦发现与堵塞类事件相关的锁等待计数器指标超过阀值，则触发针对堵塞类事件的信息采集。对于堵塞类事件重点是收集数据库性能视图中的各种当前会话数据和事务类数据；将采集到的信息存入后台数据库中；在使用者需要查看堵塞类事件的主要分析结果时，以递归算法对存入后台数据库中的数据进行箍选和排列，再以桑基图的方式进行呈现。

具体来说，我们采用递归算法获取绘制堵塞桑基图的各个节点值，以及各个节点之间的能量值(节点之间的连接线粗细程度)，桑基图最明显的特征就是：始末端的分支宽度总和相等，即所有主支宽度的总和应与所有分出去的分支宽度的总和相等，保持能量的平衡。

将堵塞的链路关系采用桑基图来显示，即能表现出堵塞关系图中的各个堵塞进程，又可清晰的体现出是哪些进程是其中影响最大的关键进程。这种展示方式使使用者一目了然的知道堵塞类事件的源头、来龙去脉和影响范围等。

参考图4，图4中数字为系统自动分配的每个进程的进程编号，图4中描述的是堵塞类事件的发展过程和影响范围，图4中任一曲线两端的编号进程，位于左侧的是堵塞者，右侧的为被堵塞者，而每一张桑基图中最左侧的编号进程即为此次堵塞类事件的源头进程。举例：编号为3050的进程与编号为2386的进程组成的曲线和两个端，位于左侧的2386为堵塞者，位于右侧的3050为被堵塞者。而在编号939和编号2386进程之间，前者是堵塞者，后者在此两者关系中成为被堵塞者，图4中最左侧的编号为2531的进程即为造成此次堵塞的源头进程。图4中曲线的粗细程度代表堵塞时间的长短，即堵塞时间越长，曲线越粗，堵塞时间短，则相应的曲线就比较细。

以下本发明实施例以连接数激增事件为例描述一下针对异常事件的信息采集、存储和呈现的方法。在预定短时间(如每分钟一次)内周期性扫描各个关系型数据库性能视图中的各项性能计数器和状态信息；在周期性扫描中，一旦发现与连接数激增事件相关的锁等待计数器指标超过阀值，则触发针对连接数激增事件的信息采集，对于这类问题重点是收集数据库性能视图中的各种当前会话数据；将采集到的信息存入后台数据库中；在使用者需要查看连接数激增事件的主要分析结果时，对采集到的客户端连接数激增事件相关信息进行排序，以表格的方式呈现造成最多连接的相关信息。例如以下数据库活动连接数统计表和数据库总连接数统计表所示：

数据库活动连接数统计表

客户端	程序名	活动连接数
			x3850x6-1	OMS	9
x3850x6-1	oracle@x3850x6-1(ARC0)	1
			x3850x6-1	oracle@x3850x6-1(ARC1)	1
x3850x6-1	oracle@x3850x6-1(ARC2)	1
			x3850x6-1	oracle@x3850x6-1(ARC3)	1

数据库总连接数统计表

其中，数据库活动连接数统计表和数据库总连接数统计表中均列出了排在前五名的客户端以及程序名，数据库活动连接数：当一个数据库连接正处于活动期间(如正在执行SQL语句)，则该连接此刻为活动连接，上述数据库活动连接数统计表中的数据库活动连接数即为按照访问的客户端和程序分类统计的当前活动连接数量值。数据库总连接数：一个客户每次访问就要创建一个数据库连接，执行SQL获取结果，然后关闭、释放掉数据库连接，上述数据库总连接数统计表中的数据库总连接数即为按照访问的客户端和程序分类统计的当前连接数量值。

本发明实施例中大资源占用的会话事件以及大资源占用的SQL事件的信息采集、存储和呈现的方法与上述连接数激增事件的信息采集、存储和呈现的方法基本相同，在此不再赘述。

以下本发明实施例以程序解析量过大事件为例描述一下针对异常事件的信息采集、存储和呈现的方法。在预定短时间(如每小时一次)内周期性扫描各个关系型数据库性能视图中的各项性能计数器和状态信息；在周期性扫描中，一旦发现语句解析计数器指标超过阀值，则触发针对程序解析量过大事件的信息采集，对于这类问题重点是收集数据库性能视图中的SQL语句信息数据；在采集的同时会对SQL语句的文本进行哈希运算，首先是生成每条SQL语句的哈希值，然后是对相同哈希值的SQL进行分组统计，从而统计出哪些哈希值对应的SQL语句数量是最多的，将采集到的性能视图信息和生成的哈希统计值存入后台数据库中；在使用者需要查看程序解析过量的主要分析结果时，对采集到的信息进行从大至小的排序，以表格的方式呈现造成解析过量的主要语句信息。例如以下SQL文本解析频度统计表所示：

SQL文本解析频度统计表

其中，SQL文本：对数据库进行访问的具体SQL语句内容，SQL(Structured QueryLanguage)即结构化查询语言；解析频度：语句被解析的总次数。哈希Hash，也翻译做散列、杂凑，是把任意长度的输入(又叫做预映射pre-image)通过散列算法变换成固定长度的输出，该输出就是散列值。这种转换是一种压缩映射，也就是，散列值的空间通常远小于输入的空间，不同的输入可能会散列成相同的输出，所以不可能从散列值来确定唯一的输入值。简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数。

采用本发明实施例对业务类程序进行软件异常溯源有以下几大特征：

本发明实施例的基本方法是借助对关系数据库性能视图中数据先进行周期性采集分析；

本发明实施例的数据采集方式为：先周期性检测，后依靠阀值触发的的二级采样方式；

本发明实施例的呈现方式，用一个内置的算法库以应对不同问题以不同的方式进行呈现的需求。

当前，几乎所有行业的业务类系统，其业务数据源端均是关系型数据库(如Oracle、Sqlserver、DB2、Mysql等)，这些关系型数据库在自身内存的性能视图中都会详细记录数据库各项运行指标和被程序访问的细节，并在一段时间内持续保存，本发明正是借助这些保存在数据库内存性能视图中的原始运行数据，通工加工分析，实现软件类异常溯源的。

上述二级的采样方式有以下优点：

对被管理的目标数据库系统性能影响小，系统正常时只是周期性的采样一些最基本的状态信息和性能计数器，只有在这些状态或性能计数器返回值异常时，才会触发采集信息量较大的问题追溯收集，即异常事件分类处理表中收集的性能视图信息列的内容；

前文有提到，软件类问题的一大痛点是如果不能在问题发生时刻收集到相关信息，事后是完全看不到的，本发明实施例采样方式能有效的确保在问题发生时，第一时间进行一次针对性的信息收集，确保拥有问题溯源的准确资料；

解决了当问题严重影响系统运行时，管理者无法分析问题的难题。软件类问题的发生和发展是有一个过程的；通常，即使最严重的软件类问题也需要几分钟时间的发展过程，之后才会造成系统无法访问。而该采样方式确保问题在刚刚出现时(一分钟内触发)就进行一次信息采集，因此，即使不久之后系统无法访问，管理者也可借助之前收集到的信息进行问题分析。

另外，本发明实施例相配套拥有一个可配置的呈现算法库，可根据不同的需求进行不同的效果呈现，这个算法库可不断添加，以应对不断发现的新问题所需要的新的呈现方式。

另外，本发明实施例提出的一种计算机设备，所述设备包括：一个或多个处理器；存储器，用于存储一个或多个程序；当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上所述的方法。

另外，本发明实施例提出的一种计算机存储介质，所述计算机存储介质存储有计算机程序指令，所述计算机程序指令用于执行如上所述的方法。

在本发明的实施例中，各个模块或系统可以是由计算机程序指令形成的处理器，处理器可以是一种集成电路芯片，具有信号的处理能力。处理器可以是通用处理器、数字信号处理器(Digital Signal Processor，简称DSP)、专用集成电路(Application SpecificIntegrated Circuit，简称ASIC)、现场可编程门阵列(FieldProgrammable GateArray，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。处理器读取存储介质中的信息，结合其硬件完成上述方法的步骤。

存储介质可以是存储器，例如可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。

其中，非易失性存储器可以是只读存储器(Read-Only Memory，简称ROM)、可编程只读存储器(Programmable ROM，简称PROM)、可擦除可编程只读存储器(Erasable PROM，简称EPROM)、电可擦除可编程只读存储器(Electrically EPROM，简称EEPROM)或闪存。

易失性存储器可以是随机存取存储器(RandomAccess Memory，简称RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，简称SRAM)、动态随机存取存储器(Dynamic RAM，简称DRAM)、同步动态随机存取存储器(Synchronous DRAM，简称SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data RateSDRAM，简称DDRSDRAM)、增强型同步动态随机存取存储器(EnhancedSDRAM，简称ESDRAM)、同步连接动态随机存取存储器(Synchlink DRAM，简称SLDRAM)和直接内存总线随机存取存储器(DirectRambus RAM，简称DRRAM)。

本发明实施例描述的存储介质旨在包括但不限于这些和任意其它适合类型的存储器。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件与软件组合来实现。当应用软件时，可以将相应功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

虽然，上文中已经用一般性说明及具体实施例对本发明作了详尽的描述，但在本发明基础上，可以对之作一些修改或改进，这对本领域技术人员而言是显而易见的。因此，在不偏离本发明精神的基础上所做的这些修改或改进，均属于本发明要求保护的范围。

Claims (10)

1.一种软件异常溯源方法，其特征在于，所述溯源方法包括：

在预定短时间内对各个关系型数据库的性能视图信息进行周期性数据扫描；

在周期性扫描过程中根据事先设定的数据阀值判断扫描到的数据是否存在异常；

如果发现某一数据库的性能计数器或数据库状态信息异常，则第一时间触发针对此类异常事件的信息收集；

将收集到的异常事件信息存放在后台数据库中；

在使用者需要查看该类异常事件时，以针对此类异常事件的内置特定呈现算法进行异常事件溯源分析；及

利用所述特定呈现算法匹配的特定呈现方法对此类异常事件的结论性溯源分析进行可视化展示。

2.如权利要求1所述的溯源方法，其特征在于，所述性能视图信息包括各类关系型数据库中的各项性能计数器详细记录的各项运行指标和数据库状态信息。

3.如权利要求1所述的溯源方法，其特征在于，所述第一时间触发针对此类异常事件的信息收集之前，还包括：根据发生异常的性能计数器或数据库状态信息判断异常事件类型。

4.如权利要求3所述的溯源方法，其特征在于，所述异常事件信息按照异常事件类型存放在后台数据库中不同的信息列表中。

5.如权利要求1所述的溯源方法，其特征在于，所述第一时间触发针对此类异常事件的信息收集通过触发开关的控制仅在发现异常事件的第一个扫描周期中触发一次针对此类异常事件信息的收集，其包括：

发现某一数据库的性能计数器或数据库状态信息异常时，触发开关开启；

记录每个扫描周期的触发开关的状态；

触发开关开启时，检测前一扫描周期的触发开关的状态；

如果前一扫描周期的触发开关关闭，则判断为发现异常事件的第一个扫描周期，触发一次针对此类异常事件的信息收集；及

如果前一扫描周期的触发开关开启，则禁止触发再次针对此类异常事件的信息收集。

6.如权利要求3所述的溯源方法，其特征在于，所述异常事件类型包括：长时间锁等待事件/堵塞类事件、连接数激增事件、大资源占用的会话事件、大资源占用的SQL事件和程序解析量过大事件；所述异常事件类型、针对各类异常事件收集的性能视图信息、针对各类异常事件的呈现算法以及呈现方法的对应关系如下表所示：

7.一种软件异常溯源系统，其特征在于，所述溯源系统包括：

数据库扫描模块，用于在预定短时间内对各个关系型数据库的性能视图信息进行周期性数据扫描；

异常监控模块，用于在周期性扫描过程中根据事先设定的数据阀值判断扫描到的数据是否存在异常；

数据采集模块，用于在发现某一数据库的性能计数器或数据库状态信息异常的第一时间触发针对此类异常事件的信息收集；

数据存储模块，用于将收集到的异常事件信息存放在后台数据库中；

数据分析模块，用于在使用者需要查看该类异常事件时，以针对此类异常事件的内置特定呈现算法进行异常事件溯源分析；及

可视化展示模块，用于利用所述特定呈现算法匹配的特定呈现方法对此类异常事件的结论性溯源分析进行可视化展示。

8.如权利要求7所述的溯源系统，其特征在于，所述数据采集模块包括：

触发开关，用于在发现某一数据库的性能计数器或数据库状态信息异常时开启；

触发开关状态记录单元，用于记录每个扫描周期的触发开关的开启状态；

触发开关状态检测单元，用于在触发开关开启时检测前一扫描周期的触发开关的开启状态；和

信息收集单元，用于前一扫描周期的触发开关关闭情况下触发一次针对此类异常事件的信息收集；及在前一扫描周期的触发开关开启情况下禁止触发再次针对此类异常事件的信息收集。

9.一种计算机设备，其特征在于，所述设备包括：

一个或多个处理器；

存储器，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1至6中任一所述的方法。

10.一种计算机存储介质，其特征在于，所述计算机存储介质存储有计算机程序指令，所述计算机程序指令用于执行如权利要求1至6中任一项所述的方法。