代码故障定位方法、装置、设备及存储介质与流程

本发明涉及通信技术领域，尤其涉及一种代码故障定位方法、装置、设备及存储介质。

背景技术：

中国移动的第三代业务支撑系统已经完成了系统解耦、分布式改造等互联网架构建设，新的系统架构对应用处理能力、动态能力扩充等都带来了很大提升，但是同时也给系统运维带来了全新的挑战：

(1)技术架构的转变、开源软件的引入、中心化改造，使第三代业务支撑系统架构复杂化，业务主机x86化及虚拟化技术的应用，使得主机的设备数量成倍数增加，系统规模庞大，使得当出现系统性能问题时，问题根源定位变得非常困难。

(2)新应用架构下，在日常的运维中发现当前的应用版本对主机资源需求较高、资源消耗较多，但相应的，应用性能并没有得到明显提升，用户感知反而出现下降的情况。对于如何快速定位应用中可能的性能瓶颈，在现有的运维监控手段下，没有很好的解决办法。

为保障业务支撑系统稳定运行，当发生故障前，可以提前对可能引起故障的性能指标进行监控，设定阀值并预警，达到相应阀值即告警通知相关人员进行处理。当发生故障时，可以快速通知相关人员，并帮助快速定位系统问题，找到系统瓶颈所在，快速准确定位性能问题根源、对系统进行持续性能优化与统一监控，以达到帮助业务系统快速恢复，快速提升应用响应速度，快速处理故障问题。

然而，目前it系统运维工作中，主要存在以下缺点和问题：

第一，多数工作任务为手工或脚本执行，可视化操作欠缺，且脚本方法较为分散不利于管理，脚本运行没有把过程或场景进行固化，不能跟踪、追溯问题。

第二，主机、数据库、基础软件等巡检任务需人工执行生成附件发送日报邮件，效率有待提升。

第三，应用故障之前的性能瓶颈没有进行预警，没有良好的性能监控方法，或者采集到的一些指标没有可视化、图形化的展现。

第四，对设备、业务集群、应用部署、资源使用情况等没有统一的、集中的基础数据库进行管理。也没有整体架构的拓扑展现。

第五，调整变更时需投入较大的人力和精力。

综上所述，虽然在日常运维工作中，已逐步开展一些运维自动化或半自动化工作，并取得一定的效率提升，但是众多分散的工具以及自动化脚本，随着运维场景的增多会让我们的管理过程比较困难，同时也对我们的人员稳定性和人员个人意识存在较大的依赖性。

技术实现要素：

本发明实施例提供了一种代码故障定位方法、装置、设备及存储介质，可以摆脱对人员稳定性和人员个人意识的依赖，自动定位到源代码中，快速地发现性能问题代码，以方便对代码进行调优，找到应用性能问题的解决方法。

第一方面，本发明实施例提供了一种代码故障定位方法，方法包括：

基于预设周期，定时扫描所有线程业务执行耗时；

当所述所有线程业务执行耗时中存在任一线程业务执行耗时大于预设阈值时，则采集执行耗时大于预设阈值的线程业务调用堆栈信息；

将所述执行耗时大于预设阈值的线程业务调用堆栈信息与业务跟踪信息进行绑定，得到跟踪业务采集到的信息；

按照业务应用调用顺序，将所述跟踪业务采集到的信息组织为业务调用链；

根据所述业务调用链，进行代码故障定位。

根据本发明所述的代码故障定位方法，所述方法还包括：

当应用启动时，对多个关键信息类进行字节码注入，得到所述业务跟踪信息，其中，所述业务跟踪信息包括业务逻辑和监控代码；

对所述多个关键信息类进行业务耗时计时。

根据本发明所述的代码故障定位方法，所述多个关键信息类包括：

java服务器页面jsp、服务连接器servlet、企业级的javabeanejb、java命名和目录接口jndi、java数据库连接jdbc。

根据本发明所述的代码故障定位方法，所述对所述多个关键信息类进行业务耗时计时，包括：

当发出业务请求后，对所述jsp或servlet进行业务耗时计时；

当业务调用所述ejb、jndi或jdbc时，对所述ejb、jndi或jdbc进行业务耗时计时；

其中，所述线程用于执行所述业务请求。

根据本发明所述的代码故障定位方法，所述根据所述业务调用链，进行代码故障定位，包括：

基于预设阈值，判断业务请求是否超时；

当判定所述业务请求超时，则保存业务请求超时的业务调用链；

根据所述业务请求超时的业务调用链，进行代码故障定位。

根据本发明所述的代码故障定位方法，所述根据所述业务请求超时的业务调用链，进行代码故障定位，包括：

通过请求调用栈信息，查看所述业务请求超时的业务调用链；

通过请求统一资源定位符url，查看所述业务请求超时的业务调用链信息中的线程堆栈完整调用信息；

根据所述线程堆栈完整调用信息，进行代码故障定位。

根据本发明所述的代码故障定位方法，所述方法还包括：

判断资源是否关闭；

当判定资源未关闭时，则抓取堆栈信息；

根据所述堆栈信息，进行代码故障定位。

根据本发明所述的代码故障定位方法，所述判断资源是否关闭，包括：

对所述创建资源方法返回的资源进行包装，并将包装好的资源放入引用队列中；

当对资源对象进行垃圾回收时，所述引用队列获取包装；

根据所述包装，判断是否调用了资源的关闭方法，得到判定结果；

根据所述判定结果，判断资源是否关闭。

根据本发明所述的代码故障定位方法，所述方法还包括：

判断应用是否发生异常；

当判定应用发生异常时，则抓取堆栈信息；

根据所述堆栈信息，进行代码故障定位。

根据本发明所述的代码故障定位方法，所述根据所述堆栈信息，进行代码故障定位，包括：

当业务代码发生异常时，则抓取异常调用堆栈信息；

在所述异常调用堆栈信息中找到与业务相关的调用类；

根据所述调用类，判定所述业务代码发生异常的具体代码的行号信息。

第二方面，本发明实施例提供了一种代码故障定位装置，装置包括：

扫描模块，用于基于预设周期，定时扫描所有线程业务执行耗时；

采集模块，用于当所述所有线程业务执行耗时中存在任一线程业务执行耗时大于预设阈值时，则采集执行耗时大于预设阈值的线程业务调用堆栈信息；

绑定模块，用于将所述执行耗时大于预设阈值的线程业务调用堆栈信息与业务跟踪信息进行绑定，得到跟踪业务采集到的信息；

组织模块，用于按照业务应用调用顺序，将所述跟踪业务采集到的信息组织为业务调用链；

定位模块，用于根据所述业务调用链，进行代码故障定位。

根据本发明所述的代码故障定位装置，还包括：

注入模块，用于当应用启动时，对多个关键信息类进行字节码注入，得到所述业务跟踪信息，其中，所述业务跟踪信息包括业务逻辑和监控代码；

计时模块，用于对所述多个关键信息类进行业务耗时计时。

根据本发明所述的代码故障定位装置，所述多个关键信息类包括：

java服务器页面jsp、服务连接器servlet、企业级的javabeanejb、java命名和目录接口jndi、java数据库连接jdbc。

根据本发明所述的代码故障定位装置，计时模块具体用于：

当发出业务请求后，对所述jsp或servlet进行业务耗时计时；

当业务调用所述ejb、jndi或jdbc时，对所述ejb、jndi或jdbc进行业务耗时计时；

其中，所述线程用于执行所述业务请求。

根据本发明所述的代码故障定位装置，定位模块具体用于：

基于预设阈值，判断业务请求是否超时；

当判定所述业务请求超时，则保存业务请求超时的业务调用链；

根据所述业务请求超时的业务调用链，进行代码故障定位。

根据本发明所述的代码故障定位装置，定位模块具体用于：

通过请求调用栈信息，查看所述业务请求超时的业务调用链；

通过请求统一资源定位符url，查看所述业务请求超时的业务调用链信息中的线程堆栈完整调用信息；

根据所述线程堆栈完整调用信息，进行代码故障定位。

根据本发明所述的代码故障定位装置，还包括：

第一判断模块，用于判断资源是否关闭；

第一抓取模块，用于当判定资源未关闭时，则抓取堆栈信息；

第一定位模块，用于根据所述堆栈信息，进行代码故障定位。

根据本发明所述的代码故障定位装置，第一判断模块具体用于：

对所述创建资源方法返回的资源进行包装，并将包装好的资源放入引用队列中；

当对资源对象进行垃圾回收时，所述引用队列获取包装；

根据所述包装，判断是否调用了资源的关闭方法，得到判定结果；

根据所述判定结果，判断资源是否关闭。

根据本发明所述的代码故障定位装置，还包括：

第二判断模块，用于判断应用是否发生异常；

第二抓取模块，用于当判定应用发生异常时，则抓取堆栈信息；

第二定位模块，用于根据所述堆栈信息，进行代码故障定位。

根据本发明所述的代码故障定位装置，第二定位模块具体用于：

当业务代码发生异常时，则抓取异常调用堆栈信息；

在所述异常调用堆栈信息中找到与业务相关的调用类；

根据所述调用类，判定所述业务代码发生异常的具体代码的行号信息。

第三方面，本发明实施例提供了一种代码故障定位设备，包括：至少一个处理器、至少一个存储器以及存储在存储器中的计算机程序指令，当计算机程序指令被处理器执行时实现如上述实施方式中第一方面的方法。

第四方面，本发明实施例提供了一种计算机可读存储介质，其上存储有计算机程序指令，当计算机程序指令被处理器执行时实现如上述实施方式中第一方面的方法。

本发明实施例提供的代码故障定位方法、装置、设备及存储介质，能够自动定位到源代码中，快速地发现性能问题代码，以方便对代码进行调优，找到应用性能问题的解决方法，利用本发明可以摆脱对人员稳定性和人员个人意识的依赖。

附图说明

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

图1示出了本发明实施例的代码故障定位方法的流程示意图；

图2示出了本发明实施例的代码故障定位装置的结构示意图；

图3示出了本发明实施例的监控平台源代码定位流程示意图；

图4示出了本发明实施例的字节码注入流程示意图；

图5示出了本发明实施例的字节码操纵技术流程示意图；

图6示出了本发明实施例的关于资源未关闭的堆栈抓取和代码定位能力示意图；

图7示出了本发明实施例的关于应用异常发生的堆栈抓取和代码定位能力示意图；

图8示出了本发明实施例的请求调用链跨主机、跨jvm的调用分析示意图；

图9示出了本发明实施例的端到端展现整个业务请求各个环节的调用拓扑图自动映射关系示意图；

图10示出了本发明实施例的树形拓扑示意图；

图11示出了本发明实施例的扁平式拓扑示意图；

图12示出了本发明实施例的实例运行状态示意图；

图13示出了本发明实施例的自定义扫描周期、多种指标设定告警阀值操作示意图；

图14示出了本发明实施例的指定应用指标告警阀值适用于其中哪类应用的操作示意图；

图15示出了本发明实施例的可自定义告警时执行脚本，并配置重启策略的操作示意图；

图16示出了本发明实施例的通过图形化界面配置应用java类的监控范围示意图；

图17示出了本发明实施例的使实例的监控范围按配置进行示意图；

图18示出了本发明实施例的通过界面查看已经监控的java类数量及类的详细情况示意图；

图19示出了本发明实施例的代码故障定位设备的硬件结构示意图。

具体实施方式

下面将详细描述本发明的各个方面的特征和示例性实施例，为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细描述。应理解，此处所描述的具体实施例仅被配置为解释本发明，并不被配置为限定本发明。对于本领域技术人员来说，本发明可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本发明的示例来提供对本发明更好的理解。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本发明实施例可提供一种代码故障定位方法，参考图1，图1示出了本发明实施例的代码故障定位方法100的流程示意图，该方法包括：

s110，基于预设周期，定时扫描所有线程业务执行耗时；

s120，当所有线程业务执行耗时中存在任一线程业务执行耗时大于预设阈值时，则采集执行耗时大于预设阈值的线程业务调用堆栈信息；

s130，将执行耗时大于预设阈值的线程业务调用堆栈信息与业务跟踪信息进行绑定，得到跟踪业务采集到的信息；

s140，按照业务应用调用顺序，将跟踪业务采集到的信息组织为业务调用链；

s150，根据业务调用链，进行代码故障定位。

利用本发明提供的上述方案，可以摆脱对人员稳定性和人员个人意识的依赖，自动定位到源代码中，快速地发现性能问题代码，以方便对代码进行调优，找到应用性能问题的解决方法。

本发明实施例可提供一种代码故障定位装置，参考图2，图2示出了本发明实施例的代码故障定位装置200的结构示意图，该装置包括：

扫描模块210，用于基于预设周期，定时扫描所有线程业务执行耗时；

采集模块220，用于当所有线程业务执行耗时中存在任一线程业务执行耗时大于预设阈值时，则采集执行耗时大于预设阈值的线程业务调用堆栈信息；

绑定模块230，用于将执行耗时大于预设阈值的线程业务调用堆栈信息与业务跟踪信息进行绑定，得到跟踪业务采集到的信息；

组织模块240，用于按照业务应用调用顺序，将跟踪业务采集到的信息组织为业务调用链；

定位模块250，用于根据业务调用链，进行代码故障定位。

利用本发明提供的上述方案，可以摆脱对人员稳定性和人员个人意识的依赖，自动定位到源代码中，快速地发现性能问题代码，以方便对代码进行调优，找到应用性能问题的解决方法。

以下通过具体的实例，描述本发明实施例的可选的具体处理过程。需要说明的是，本发明的方案并不依赖于具体的算法，在实际应用中，可选用任何已知或未知的硬件、软件、算法、程序或其任意组合等来实现本发明的方案，只要是采用了本发明方案的实质思想，均落入本发明的保护范围。

基于前述现有技术，综合考虑，由运维人员从自身的需求和体验出发构建一个针对it系统运行情况的监控运维平台显得尤为重要，通过平台将运维工具以及运维过程中的一些经验进行沉淀，借助这个平台实现未来的智能化运维，从而提升运维价值。

以下通过具体实例对系统总体架构进行说明，具体如下：

在一些实施例中，构建“分布式、去中心化、模块化”的it系统性能监控系统。

作为一个示例，性能监控系统在架构设计上采用分布式、去中心化和模块化设计，平台各组件之间松散耦合，各核心组件均可任意水平扩展；系统具备高度的可用性，不存在因某单一组件单点故障而导致整个系统不可用的情况。同时平台也保持了高度的开放性，可以比较容易地和第三方或既存系统进行整合。对用户的应用系统提供一站式的性能数据收集、计算、存储、分析、告警和展示服务。

参考图3，图3示出了本发明实施例的监控平台源代码定位流程示意图。

作为一个示例，监控基础架构中，当应用系统通过浏览器或外部接口系统进行请求访问时，监控服务器的采集器对代理(agent)探针采集到的指标数据进行收集，并通过管理服务器中的大数据组件进行分析，输出到监控管理界面供用户查看。

在一些实施例中，在agent探针过程中，会对java服务器页面(javaserverpages，jsp)/服务连接器(serverapplet，servlet)、java数据库连接(javadatabaseconnectivity，jdbc)、企业级的javabean(enterprisejavabean，ejb)、javabean等代码类型进行监控采集。实现机制是通过二进制字节码注入方法，对java虚拟机(javavirtualmachine，jvm)中加载的类进行包装，采集所需的异常、资源未关闭等信息。

以下通过具体实例对系统核心模块功能和原理进行介绍，具体如下：

在一些实施例中，it系统监控平台采用的基于源代码的问题快速定位技术原理如下：

作为一个示例，针对代码级别故障定位：对于应用异常、资源未关闭、线程请求超时等问题，通过分析堆栈信息，可以直接定位到源代码中具体某一块程序代码，快速的发现性能问题代码，方便对代码进行调优，找到应用性能问题的解决方法。

以下通过具体实例对字节码注入的实现原理的各个步骤进行详细介绍，具体如下：

参考图4，图4示出了本发明实施例的字节码注入流程示意图。

作为一个示例，1、2、3：类加载器(classloader)将a.class装载入jvm，期间调用java代理(javaagent)在a.class的字节码中嵌入监控代码后，生成a’.class；

4、5、6、7：当request请求需调用a.class，引擎(engine)会找到并执行a’.class，a’.class执行a.class正常的业务逻辑；其中，a’.class包括：业务逻辑和监控代码。

8：a’.class执行结束，engine会将监控数据(data)写入监控数据暂存区；

9、10、11：每隔诸如60s(秒)，agent线程向server发送数据，并清理暂存区。

在一些实施例中，在监控系统的字节码插码技术(bytecodeinstrumentation，bci)实现方法中，可以选取几个重要的点进行字节码注入，例如servlet、ejb、file、端口号(socket)、jdbc等。

参考图5，图5示出了本发明实施例的字节码操纵技术流程示意图。

在一些实施例中，当字节码被classloader加载到内存时，agent会对字节码进行拦截，可以拦截到类名，以及字节码的字节(byte)数组，对加载的类进行分析，如果是要修改的类，则利用诸如字节码修改工具，修改类，修改完之后加载到内存中。以后被调用的时候，就是被修改后的字节码。

以下对问题源代码的定位方法进行详细介绍，具体可分为以下三个方面：

第一方面，请求超时的抓取和代码定位能力。

以下通过具体示例对请求超时的抓取和代码定位能力进行详细介绍，具体如下：

首先，请求超时的判断方法有两种，具体地：

第一种：是当程序代码执行时间太长，已经达到了java程序本身超时(timeout)异常的，可以在catch块中捕捉到。

第二种：是在监控平台中可以配置应用请求的超时时间，并且每一种应用的请求超时时间可以配置不同，例如移动总机(crm)系统可以配置超过5秒认为是超时，电渠网厅可以配置超过3秒认为是超时。

在一些实施例中，当应用程序的请求方法执行完以后，在把采集的数据信息发送到监控服务采集端之前，会比对请求的执行时间和配置的超时时间。如果超过配置的时间，则标注为超时。

第一步，用户实例启动时，agent会对jsp/servlet、ejb、jndi、jdbc(connectionpool，driver、connection、statement、preparestatement、callablestatement、resulset)等关键信息类做字节码注入，得到业务跟踪信息，业务跟踪信息包括业务逻辑和监控代码，以方便agent程序对关键业务代码执行跟踪。

第二步，对多个关键信息类进行业务耗时计时。

作为一个示例，用户访问实例业务请求后，从jsp/servlet页面开始，agent程序会开始对业务耗时开始计时，对用户发出请求地址、请求方式、参数等信息进行采集。并且，当业务调用ejb、jndi、jdbc等关键业务时程序会对业务都做单独耗时计时、同时采集相关参数信息。

例如，jdbc业务程序会采集驱动、连接统一资源定位符(uniformresourcelocator，url)地址、执行结构化查询语言(structuredquerylanguage，sql)、数据库类型、版本、jdbc版本等信息。

第三步，agent在后台会单独启动一个活动线程扫描线程，会基于预设周期(例如3s)定时扫描系统中所有线程业务执行耗时，如果某个业务执行耗时超过agent配置模板中jsp.threshold配置阈值，则采集该线程中线程业务调用堆栈信息，将执行耗时大于预设阈值的线程业务调用堆栈信息绑定到程序检测的jsp/servlet跟踪entry信息中，随后同业务跟踪信息一起上报，得到跟踪业务采集到的信息。

第四步，当业务访问完毕后，agent程序将跟踪业务采集到的信息通过业务应用调用顺序组织为一个完整的业务调用链，判断该业务请求是否超过jsp.threshold配置阈值，超过则认为该次业务请求属于超时业务，上报至collector将超时业务请求链保存。

第五步，在console端访问质量分析->响应超时应用，选择实例查询出超时业务请求列表，点击请求可以查看业务调用详细信息，点击请求调用栈信息可以查看业务调用链信息，在请求超时上可以点击请求url查看该请求超时后业务调用链信息中具体的线程堆栈完整调用信息，可以判断到应用业务耗时较长代码类、方法和具体行号。

第二方面，资源未关闭的抓取和代码定位能力。

以下通过具体示例对资源未关闭的抓取和代码定位能力进行详细介绍，具体如下：

首先，对资源类进行了包装处理。

在一些实施例中，支持的未关闭资源检查有connection、statement、preparestatement、resultset、file、socket等。在执行创建资源方法的时候，可以记录当前的代码堆栈，我们在创建资源方法返回的资源做了包装，将包装好的资源放入特殊的引用队列(referencequeue)中。

当资源对象被垃圾回收(garagecollection，gc)的时候，前述引用队列才能获取到我们的包装，如果资源调用了close方法关闭，包装类里就会记录，否则没有记录。

当资源对象被垃圾回收掉，但是没有调用资源的关闭方法，就被判定为资源未关闭。并且把创建资源的堆栈发送出去。

参考图6，图6示出了本发明实施例的关于资源未关闭的堆栈抓取和代码定位能力示意图。

例如，图6的堆栈信息中定位到professordao.java的57行，可以看到通过跳转直接跳转到源程序的这一行上，真正准确的实例源代码定位能力。

第三方面，应用异常发生的堆栈抓取和代码定位能力。

以下通过具体示例对应用异常发生的堆栈抓取和代码定位能力进行详细介绍，具体如下：

第一步，用户访问业务请求，业务代码执行到某处逻辑时抛出异常，此时agent会检测到该异常，并将抛出异常的业务执行调用顺序堆栈采集上报。

第二步，collector端接收到agent上报的异常堆栈内容后，将异常内容一方面存储至监控管理服务器系统存储，另一方面对异常类型做同类聚合分析操作，统计一段时间内容该异常发生次数并存储，方便用户从汇总上观察异常发生次数。

第三步，在console端可以访问质量分析->异常功能，点击用户需要关注的异常，进入到异常访问列表详细页面，在此用户可以查看异常堆栈内容，该异常调用堆栈信息即为实际业务系统逻辑执行时抛出异常后的调用顺序信息；在堆栈调用中，用户可以找到与用户业务相关的调用类，在调用类后可以查看到具体调用到的方法以及在该业务类方法内部执行到抛出异常的具体业务行的行号信息。即可帮助用户定位异常发生位置。

参考图7，图7示出了本发明实施例的关于应用异常发生的堆栈抓取和代码定位能力示意图。

如图7所示，可以在异常抓取的堆栈里面找到对应的源代码行，通过双击可以直接转到源代码对应的行号上面，比如下图的堆栈信息中定位到studentdao.java的118行，可以看到通过跳转直接跳转到源程序的这一行上，真正准确的实例源代码定位能力。

以下对it系统监控平台新特性的三个方面进行详细介绍，具体如下：

第一方面，以下对端对端监控及拓扑展现进行详细介绍。

以下通过具体实例对端对端监控及拓扑展现进行介绍，具体如下：

参考图8，图8示出了本发明实施例的请求调用链跨主机、跨jvm的调用分析示意图。

作为一个示例，如图8所示，可以获取请求调用链跨主机、跨jvm的调用分析。

参考图9，图9示出了本发明实施例的端到端展现整个业务请求各个环节的调用拓扑图自动映射关系示意图。

作为一个示例，如图9所示，只要双击中间件(例如，应用服务器(bes)、应用服务器(weblogic)、应用服务器(tomcat)等)可以查看整体上调用链路的个环节消耗时长，并且可以分别查看每个中间件内部的每个步骤耗时，包括具体方法和sql语句执行间。此外，还可以看到weblog基于t3的ejb调用步骤，bes基于spark的ejb调用步骤等。

在一些实施例中，通过对标签之间关系，将监控系统中所有实例以诸如组织层级架构形式拓扑图或扁平平铺拓扑图等方式展示给用户，使用户可以清晰掌握各个分组实例整体运行状态，从整体上全局把控系统健康状态。

其中，拓扑图可分为：树形拓扑图、扁平式拓扑图。

参考图10和图11，其中图10示出了本发明实施例的树形拓扑示意图；图11示出了本发明实施例的扁平式拓扑示意图。

参考图12，图12示出了本发明实施例的实例运行状态示意图。

第二方面，以下对故障自愈进行详细介绍。

在一些实施例中，支持自定义联动策略的可视化配置，当发生故障告警时，可以自动完成应用重启或执行自定义脚本的操作，其中重启可以配置重试次数。

第一步，自定义扫描周期、多种指标设定告警阀值。

参考图13，图13示出了本发明实施例的自定义扫描周期、多种指标设定告警阀值操作示意图。

第二步，指定应用指标告警阀值适用于其中哪类应用。

参考图14，图14示出了本发明实施例的指定应用指标告警阀值适用于其中哪类应用的操作示意图。

第三步，可自定义告警时执行脚本，并配置重启策略。

参考图15，图15示出了本发明实施例的可自定义告警时执行脚本，并配置重启策略的操作示意图。

第三方面，以下对动态性能诊断进行详细介绍，具体如下：

在一些实施例中，首先，能够通过图形化界面配置应用java类的监控范围，可以包含应用包名、java类名匹配，支持排除匹配出的结果，也支持方法作用域public、private的配置，支持方法的匹配和排出配置。

参考图16，图16示出了本发明实施例的通过图形化界面配置应用java类的监控范围示意图。

其次，提供默认配置模板，同时支持针对不同的实例配置不同的模板，使实例的监控范围按配置进行。

参考图17，图17示出了本发明实施例的使实例的监控范围按配置进行示意图。

再次，支持图形化界面配置监控数据采集率，可以配置响应比较快的请求只是抽样采集，支持设定请求响应时间的阀值，大于此时间阀值的请求处理过程完全采集，低于此时间阀值的请求处理过程按设置的百分比进行随机采集，此两项配置实时生效，无需重启java进程。

最后，支持在不重启被监控实例的情况下，动态调整监控实例的java类范围，并支持界面查看已经监控的java类数量及类的详细情况。

参考图18，图18示出了本发明实施例的通过界面查看已经监控的java类数量及类的详细情况示意图。

综上所述，本发明实施例提供了一种通用的应用系统日志数据采集监控方案，同时满足了集团对微服务化架构下的it支撑系统的性能和问题监控功能的相关要求，主要包括以下几方面技术方案：

(1)对于应用异常、资源未关闭、线程请求超时等问题，可以提供堆栈信息，根据堆栈信息，可以直接定位到源代码中，定位到源代码中具体某一块程序代码，快速的发现性能问题代码，方便对代码进行调优，找到应用性能问题的解决方法。

(2)可以获取请求调用链跨主机、跨jvm的调用分析，端到端展现整个业务请求各个环节的调用拓扑图自动映射关系。

因此，本发明实施例提供的技术方案包括：

1、使用堆栈信息分析，定位系统源代码问题块，找到代码级应用性能问题解决方法；

2、实现应用系统全流程业务请求各个环节的调用关系图形化展示。

此外，本发明实施例通过对应用实施完全无侵入式的监控，无论是正在开发还是已经生产部署的应用系统，都无需做任何改变，自动采集应用的性能指标，快速定位应用性能瓶颈，快速找到故障原因，快速自动化故障恢复。

目前，贵州移动已在电子渠道系统部署使用，帮助电子渠道系统找到性能问题35处，找到可优化的超时请求58个，找到应用系统异常32处，定位资源未关闭问题12起，帮助电子渠道商城应用，在1分钟内自动化对故障告警实例进重启恢复。

通过集中收集和实时分析，对应用的性能提供全方位的诊断分析。

本发明实施例提供的技术方案可以取得如下多方面的技术效果：

1、可以根据堆栈信息，直接定位到源代码中某一块代码，实现代码级别故障定位

2、端对端监控及拓扑展现，可以获取请求调用链跨主机、跨jvm的调用分析，实现端对端监控的每个环节拓扑展现图。

3、故障自愈能力，支持自定义联动策略的可视化配置，当发生故障告警时，可以自动完成应用重启或执行自定义脚本的操作，其中重启可以配置重试次数。

4、动态性能诊断，支持在不重启被监控实例的情况下，动态调整监控实例的java类范围，并支持界面查看已经监控的java类数量及类的详细情况。

5、可以预先发现应用系统存在的潜在的性能问题；

6、可以及时分析问题并解决；

7、可以24小时实时监控整个应用系统；

8、可以保存实时性能数据(性能报告)；

9、可以定量的分析当前系统性能，科学的决策是否需要升级系统硬件；

10、节省系统维护费用，提高维护效率；

11、可以保证系统长期稳定的运行。

另外，结合图1描述的本发明实施例的代码故障定位方法可以由代码故障定位设备来实现。图19示出了本发明实施例提供的代码故障定位设备的硬件结构示意图。

代码故障定位设备可以包括处理器1003以及存储有计算机程序指令的存储器1004。

图19是示出能够实现根据本发明实施例的通信方法和网络服务器的计算设备的示例性硬件架构的结构图。如图19所示，计算设备1000包括输入设备1001、输入接口1002、处理器1003、存储器1004、输出接口1005、以及输出设备1006。

其中，输入接口1002、处理器1003、存储器1004、以及输出接口1005通过总线1010相互连接，输入设备1001和输出设备1006分别通过输入接口1002和输出接口1005与总线1010连接，进而与计算设备1000的其他组件连接。

具体地，输入设备1001接收来自外部的输入信息，并通过输入接口1002将输入信息传送到处理器1003；处理器1003基于存储器1004中存储的计算机可执行指令对输入信息进行处理以生成输出信息，将输出信息临时或者永久地存储在存储器1004中，然后通过输出接口1005将输出信息传送到输出设备1006；输出设备1006将输出信息输出到计算设备1000的外部供用户使用。

计算设备1000可以执行本申请上述的通信方法中的各步骤。

处理器1003可以是一个或多个中央处理器(英文：centralprocessingunit，cpu)。在处理器1003是一个cpu的情况下，该cpu可以是单核cpu，也可以是多核cpu。

存储器1004可以是但不限于随机存储存储器(ram)、只读存储器(rom)，可擦除可编程只读存储器(eprom)、光盘只读存储器(cd-rom)、硬盘等中的一种或多种。存储器1004用于存储程序代码。

可以理解的是，在本申请实施例中，图2提供的扫描模块至定位模块中任一模块或全部模块的功能可以用图19所示的中央处理器1003实现。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用全部或部分地以计算机程序产品的形式实现，所述计算机程序产品包括一个或多个计算机指令。在计算机上加载或执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输)。所述计算机可读取存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solidstatedisk(ssd))等。

本说明书的各个部分均采用递进的方式进行描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点介绍的都是与其他实施例不同之处。尤其，对于装置和系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例部分的说明即可。