CN110795357A

CN110795357A - 程序监控方法及装置

Info

Publication number: CN110795357A
Application number: CN201911065045.6A
Authority: CN
Inventors: 黄俊文; 杨卓俊; 谢林洁
Original assignee: Industrial and Commercial Bank of China Ltd ICBC
Current assignee: Industrial and Commercial Bank of China Ltd ICBC
Priority date: 2019-11-04
Filing date: 2019-11-04
Publication date: 2020-02-14
Anticipated expiration: 2039-11-04
Also published as: CN110795357B

Abstract

本发明提供的一种程序监控方法及装置，通过将待监控程序和监控程序均编译为类文件，然后通过加载器加载的特性，将第一类文件和第二类文件委派到同一顶层进行加载，采用重新编译的方式，将第二类文件的代码注入到第一类文件中，然后通过加载的方式得到第一类文件对应运行程序的系统性能数据，可以在不对系统进行改造，不需要加入额外的监控组件，无感知且高效精准的性能监控并自动化预测分析性能问题，进行高效的性能测试对系统的侵入和影响更小，在不修改源代码的情况，获取系统的性能指标情况和更为细粒度的方法执行和内存分配情况，获取的数据可以进行代码分析和数据挖掘。

Description

程序监控方法及装置

技术领域

本发明涉及程序监控技术领域，更具体的，涉及一种程序监控方法及装置。

背景技术

在高速发展的互联网业务时代。各项目组采用敏捷、迭代等开发方法保证开发效率，在这种快速上线快速交付的模式下，如何使用高效的测试方法保证项目中的性能测试环节，缩短项目测试周期显得尤为重要。目前对Java软件系统进行性能监控存在多种常规方法，如对程序加入监控语句、使用过滤器或拦截器，通过日志等获取监控到的数据进行性能分析。但这无一例外的，上述方法都需要对系统进行某种改造，在代码层面引入监控的组件，并且还要对大量的日志和监控数据进行分析进行性能评定。这无疑对系统的代码管理造成了额外的负担，也对开发测试的数据分析，测试时间大大增加。极大的加重了开发测试的工作。如何在不改变项目代码的前提下，无感知且高效精准的性能监控并自动化预测分析性能问题，进行高效的性能测试是一个亟待解决的问题。

发明内容

为了解决上述问题中的至少一个，本申请实施例提供一种程序监控方法，包括：

将待监控程序代码编译为第一类文件，监控程序代码编译为第二类文件；

将所述第一类文件的加载请求发送至第一子类加载器，第二类文件的加载请求发送至第二子类加载器，以使所述第一子类加载器和第二子类加载器对应地将所述第一类文件和所述第二类文件委派至顶层的父类加载器进行加载；

当监测到所述第一类文件被加载时，拦截并获取所述第一类文件的代码，将所述第二类文件的代码注入到第一类文件的代码中，重新编译形成合并类文件；

通过加载所述合并类文件获取所述第一类文件中的系统性能数据；

根据所述系统性能数据监控所述程序在系统中的运行状态。

某些实施例中，所述将所述第二类文件的代码注入到第一类文件的代码中，包括：

利用Asm框架将第二类文件中的代码插入到第一类文件中。

某些实施例中，所述根据所述系统性能数据监控所述程序在系统中的运行状态，包括：

将所述系统性能数据中对应的数据输入预设的内存泄漏模型、大对象分配模型、内存溢出模型以及耗时增长模型中的至少一个，根据至少一个模型的输出结果监控所述程序。

某些实施例中，将所述系统性能数据中对应的数据输入内存泄漏模型，根据所述内存泄漏模型的输出结果监控所述程序，包括：

将所述程序所在系统每个设定时长执行内存回收操作后的内存释放量和使用量输入所述内存泄漏模型；

根据所述内存泄漏模型输出的泄漏内存，确定泄漏风险；其中所述内存泄漏模型基于不同时间点的内存释放量和内存使用量确定内存总量，并根据所述内存总量的线性回归线的趋势确定内存是否存在泄漏。

某些实施例中，将所述系统性能数据中对应的数据输入大对象分配模型，根据所述大对象分配模型的输出结果监控所述程序，包括：

将内存的分配数据输入至所述大对象分配模型，以使所述大对象分配模型根据预定义的内存阈值，将内存分配高于内存阈值的对象确定为大对象，触发大对象预警。

某些实施例中，将所述系统性能数据中对应的数据输入耗时增长模型，包括：

将所述系统性能数据中的程序耗时数据输入所述耗时增长模型；

根据所述耗时增长模型输出的耗时曲线，监控运行耗时。

某些实施例中，所述方法还包括：

基于预设的深度学习性能分析模型，对所述系统性能数据进行分析，得到程序诊断结果；其中，

所述深度学习性能分析模型根据所述程序的历史系统性能数据训练得到。

某些实施例中，还包括：

建立所述深度学习性能分析模型；

将所述程序的历史系统性能数据和对应的导致数据异常的原因作为训练集数据，对所述深度学习性能分析模型进行训练。

本申请实施例还提供一种程序监控装置，包括：

文件编译模块，将待监控程序代码编译为第一类文件，监控程序代码编译为第二类文件；

加载模块，将所述第一类文件的加载请求发送至第一子类加载器，第二类文件的加载请求发送至第二子类加载器，以使所述第一子类加载器和第二子类加载器对应地将所述第一类文件和所述第二类文件委派至顶层的父类加载器进行加载；

合并模块，当监测到所述第一类文件被加载时，拦截并获取所述第一类文件的代码，将所述第二类文件的代码注入到第一类文件的代码中，重新编译形成合并类文件；

系统性能数据获取模块，通过加载所述合并类文件获取所述第一类文件中的系统性能数据；

程序监控模块，根据所述系统性能数据监控所述程序在系统中的运行状态。

某些实施例中，所述合并模块利用Asm框架将第二类文件中的代码插入到第一类文件中。

某些实施例中，所述程序监控模块将所述系统性能数据中对应的数据输入预设的内存泄漏模型、大对象分配模型、内存溢出模型以及耗时增长模型中的至少一个，根据至少一个模型的输出结果监控所述程序。

某些实施例中，所述程序监控模块，包括：

内存泄漏模型输入单元，将所述程序所在系统每个设定时长执行内存回收操作后的内存释放量和使用量输入所述内存泄漏模型；

泄漏确定单元，根据所述内存泄漏模型输出的泄漏内存，确定泄漏风险；其中所述内存泄漏模型基于不同时间点的内存释放量和内存使用量确定内存总量，并根据所述内存总量的线性回归线的趋势确定内存是否存在泄漏。

某些实施例中，所述程序监控模块，包括：

大对象分配模型输入单元，将内存的分配数据输入至所述大对象分配模型，以使所述大对象分配模型根据预定义的内存阈值，将内存分配高于内存阈值的对象确定为大对象，触发大对象预警。

某些实施例中，所述程序监控模块，包括：

耗时增长曲线输入单元，将所述系统性能数据中的程序耗时数据输入所述耗时增长模型；

运行耗时监控单元，根据所述耗时增长模型输出的耗时曲线，监控运行耗时。

某些实施例中，还包括：

诊断分析模块，基于预设的深度学习性能分析模型，对所述系统性能数据进行分析，得到程序诊断结果；其中，

某些实施例中，还包括：

深度学习性能分析模型建立模块，建立所述深度学习性能分析模型；

模型训练模块，将所述程序的历史系统性能数据和对应的导致数据异常的原因作为训练集数据，对所述深度学习性能分析模型进行训练。

本申请还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上所述的方法的步骤。

本申请还提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上所述的方法的步骤。

本发明具有如下有益效果：

本发明提供的一种程序监控方法及装置，通过将待监控程序和监控程序均编译为类文件，然后通过加载器加载的特性，将第一类文件和第二类文件委派到同一顶层进行加载，然后采用重新编译的方式，将第二类文件的代码注入到第一类文件中，然后通过加载的方式得到第一类文件对应运行程序的系统性能数据，通过该方式可以在不对系统进行改造，不需要加入额外的监控组件，能够在在不改变项目代码的前提下，无感知且高效精准的性能监控并自动化预测分析性能问题，进行高效的性能测试，本申请的方案对系统的侵入和影响更小，同时更具扩展性和维护性，在不修改源代码的情况，获取系统的性能指标情况和更为细粒度的方法执行和内存分配情况，获取的数据可以进行代码分析和数据挖掘，避免了通过人工去进行性能测试的检验和分析。通过程序可以智能的预测和分析问题，相比目前监控机制的各种常规方案，不仅能获取到更多的性能容量测试数据，而且具备智能分析无需人工作业，去人力且高效的优势。

附图说明

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

图1示出了本申请中实现程序监控方法的场景架构示意图。

图2示出了本申请中AGENT包在JVM中的加载图。

图3示出了本申请中代码注入示意图。

图4示出了本申请中AGENT端的结构图。

图5示出了本申请中AGENT端注入方法插入图。

图6示出了本申请SERVER端的结构图。

图7示出了本申请中CLIENT端的结构图。

图8示出了本申请提供的一种程序监控方法流程示意图。

图9示出了本申请提供的一种程序监控装置的结构示意图。

图10示出适于用来实现本申请实施例的计算机设备的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本申请旨在如何在不改变项目代码的前提下，无感知且高效精准的性能监控并自动化预测分析性能问题，其主体构思是通过将待监控程序和监控程序均编译为类文件，然后通过加载器加载的特性，将第一类文件和第二类文件委派到同一顶层进行加载，然后采用重新编译的方式，将第二类文件的代码注入到第一类文件中，然后通过加载的方式得到第一类文件对应运行程序的系统性能数据，通过该方式可以在不对系统进行改造，不需要加入额外的监控组件，能够在在不改变项目代码的前提下，无感知且高效精准的性能监控并自动化预测分析性能问题，进行高效的性能测试。

下面结合附图对本申请的发明构思进行详细说明。

图8示出了本申请实施例中一种程序监控方法的流程示意图，如图8所示，具体包括：

S1：将待监控程序代码编译为第一类文件，监控程序代码编译为第二类文件；

S2：将所述第一类文件的加载请求发送至第一子类加载器，第二类文件的加载请求发送至第二子类加载器，以使所述第一子类加载器和第二子类加载器对应地将所述第一类文件和所述第二类文件委派至顶层的父类加载器进行加载；

S3：当监测到所述第一类文件被加载时，拦截并获取所述第一类文件的代码，将所述第二类文件的代码注入到第一类文件的代码中，重新编译形成合并类文件；

S4：通过加载所述合并类文件获取所述第一类文件中的系统性能数据；

S5：根据所述系统性能数据监控所述程序在系统中的运行状态。

本发明提供的一种程序监控方法，通过将待监控程序和监控程序均编译为类文件，然后通过加载器加载的特性，将第一类文件和第二类文件委派到同一顶层进行加载，然后采用重新编译的方式，将第二类文件的代码注入到第一类文件中，然后通过加载的方式得到第一类文件对应运行程序的系统性能数据，通过该方式可以在不对系统进行改造，不需要加入额外的监控组件，能够在在不改变项目代码的前提下，无感知且高效精准的性能监控并自动化预测分析性能问题，进行高效的性能测试，本申请的方案对系统的侵入和影响更小，同时更具扩展性和维护性，在不修改源代码的情况，获取系统的性能指标情况和更为细粒度的方法执行和内存分配情况，获取的数据可以进行代码分析和数据挖掘，不在是通过人工去进行性能测试的检验和分析。通过程序可以智能的预测和分析问题，相比目前监控机制的各种常规方案，不仅能获取到更多的性能容量测试数据，而且具备智能分析无需人工作业，去人力且高效的优势。

本申请中，代码注入的可行性源于系统的一些特性，代码注入的目的就是在不修改源码且不重启系统(或进程)的情况下，改变系统(或进程)的功能。

本申请实施例中，第一类文件是待监控程序代码编译形成的，将第二类文件的代码注入到第一类文件的代码中，第二类文件的代码是监控程序的代码，通过代码注入的方式得到合并类文件，然后进行加载，进而得到系统性能数据。

系统性能数据包括内存、CPU等各种类型的使用数据、程序执行某一事件时的耗时数据(例如解压一文件的耗时等)，当然，系统性能数据不局限于上述的示例，只要是程序运行过程中能够通过现有技术采集到的并且能够客观反映程序运行状态的数据都可以视为本申请中的系统性能数据。

在具体操作时，通过JVM tool interface(java5.0开始开放的新特性，用于jvm相关开发、监控工具的接口)，可以探视(inspect)jvm内部状态并可以控制jvm运行，基于JVMTI的客户端(称为agent,JVMTI基于事件模型)，在jvm事件发生时agent会收到通知，Agent可以在事件发生时或者随时通过JVMTI查询和控制应用的运行，Agent与应用jvm运行在同一个进程内，通过JVMTI通信，Agent受另一个独立的进程控制，此进程实现了监控工具的主要功能，这个结构保证了工具与应用互不干扰，通过增加agent的启动参数来启动javaagent，如：

-javaagent:/data/monitorAgent/monitor-agent.jar

应用程序与agent的隔离与通信如图2所示，BootstrapClassLoader引导类加载器加载的是JVM自身需要的类，这个类加载使用C++语言实现的，是虚拟机自身的一部分；

ExtClassLoader负责加载<JAVA_HOME>/lib/ext目录下或者由系统变量-Djava.ext.dir指定位路径中的类库；

AppClassLoader负责加载系统类路径java-classpath或-D java.class.path指定路径下的类库，即classpath路径；Agent和相关的lib会放到AppClassLoader这一层去加载。同级加载的方式，一定程度保证了类的隔离，防止冲突与污染。双亲委派模型不同的ClassLoader之间的类不能相互访问，也不需要返回结果，所以可以通过Instrument API拿到这个类加载器。

首先，启动一个应用时，将代码的类放到类加载器去加载，如图2将应用程序代码放到ApplicationClassLoad加载器中进行加载，基于类加载的特性，当一个类加载器收到类的加载请求时会委派给父类加载器去完成，也即所有类最后都会传送到顶层加载器去加载，例如：ApplicationSelfClassLoad委派给AppClassLoader，AppClassLoader再委派给ExtClassLoader，ExtClassLoader最后委派给BootstrapClassLoader，然后当父类加载器无法完成这个加载请求时，子类加载器才会尝试自己去加载。如图2的结构中，agent采用自己的类加载器，agent的代码由agentclassload加载，虽然在同一个jvm里，却在不同的classload上实现了代码的隔离被监控应用在进行类加载时大部分java常用的类对象都是由父类加载的。如：java.lang.object是由BootstrapClassLoader来进行加载的，所以被监控应用和agent使用同样的BootstrapClassLoader，agent就能获取到被监控应用使用java.lang.object这个类的相关情况，例如Java.lang.object这个类就和应用使用的内存息息相关，Java.util.date时间类也是如此。

如图3，代码注入首先需要编写的注入代码类Monitor.java将其编译为monitor.class，在启动一个监听程序ListenHandle用来监听JVM的类加载执行，当监听到需要加载的类时将其拦截，使用asm将monitor.class中的代码插入到应用代码中，再给JVM去加载执行，整个执行如图3，首先应用会将自己编译后的代码application.class(如TomcatClassLoad)去给加载器加载，当监听程序发现application.class加载时将其截获。监听程序获得application.class的内容，然后再将编写的monitor.class插入到application.class当中，在进行重新编译给虚拟机进行类加载，这样编写的代码就植入到应用程序中。

在某些实施例中，步骤S5具体包括：将所述系统性能数据中对应的数据输入预设的内存泄漏模型、大对象分配模型、内存溢出模型以及耗时增长模型中的至少一个，根据至少一个模型的输出结果监控所述程序。

具体的，内存泄漏模型获取到了应用节点内存数据，然后进行分析可以得知，在一段时间内，如果多次内存释放下存在之前内存使用无法释放的内存，对其方法内存情况做标记。在从JMX获取的内存进行分析，如果内存在这段时间内的线性回归线是呈上升趋势的模型，则可初步预测，应用使用内存存在内存泄露风险，并将之前的标记点抛出直接定位到内存使用不当的方法和对象是什么，这样就达到一个在无人监控下自动完成应用系统的内存分析，并找出原因的自动化装置。解决目前性能容量测试结果需要压力测试花费大量时间重现，分析问题的痛点。

该实施例中，步骤S5具体包括：

S511：将所述程序所在系统每个设定时长执行内存回收操作后的内存释放量和使用量输入所述内存泄漏模型；

S512：根据所述内存泄漏模型输出的泄漏内存，确定泄漏风险；其中所述内存泄漏模型基于不同时间点的内存释放量和内存使用量确定内存总量，并根据所述内存总量的线性回归线的趋势确定内存是否存在泄漏。

大对象分配模型是为完善应用系统内存分析的模型，在应用系统中，还有一种内存使用风险是大对象，在之前的性能容量测试当中，往往会因为项目组的数据量评估不准确，测试环境数据量不足，导致程度代码中去获取大对象，而内存不足造成严重的生产问题。这种问题在生产中会时有发生。而这个模型就是为了解决这个问题。1、通常测试情况下，当数据量足够的时候，单个对象超出某个设定的阈值时。则会报警。2、配合性能容量测试，在应用代码中进行改造。获取本地编写的一个大对象将其注入到应用中。看应用是否回去正常处理，如果正常处理和监控到对象存在。则预警，并可提出请对代码处理进行限流或者是分块处理建议。

该实施例中，步骤S5包括：

S521：将内存的分配数据输入至所述大对象分配模型，以使所述大对象分配模型根据预定义的内存阈值，将内存分配高于内存阈值的对象确定为大对象，触发大对象预警。

内存溢出模型是一种简单模型，在整体内存使用中，通过系统GC，内存总使用量无法下降至70％以下，说明为应用分配总体内存不合理或者是程序存在内存泄露情况。当程序存在严重的内存泄露情况时，最终可能导致内存溢出使应用处于瘫痪状态。并且内存使用量的不足会导致频繁换页等问题，会大大影响程序执行效率。此模型配合以上两个模型可以完整的监控分析应用内存使用情况，达到无人值守的目的。

耗时增长模型通过对对象方法耗时的收集分析，应用方法的执行耗时情况如果耗时曲线呈现上升趋势，则进行性能预警，如果方法执行会出现波动情况，则预警。

该实施例中，步骤S5具体包括：

S531：将所述系统性能数据中的程序耗时数据输入所述耗时增长模型；

S532：根据所述耗时增长模型输出的耗时曲线，监控运行耗时。

在某些实施例中，可以结合上述的结果对已经产生性能问题的数据进行分析，精准定位到性能问题出现的原因。例如，a.方法耗时产生的耗时波动情况，结合jmx收集回来的信息和系统信息一同进行分析，排除在测试环境中因为环境因素产生的干扰，如cpu使用过高，网络不稳定等因素，在综合分析，如果是系统原因则略过，若分析为程序原因，则生成性能问题点推送项目组。b.方法耗时呈现上升趋势，则获取方法处理对象大小，看队列长度和相乘数进行分析，这种情况一般是程序出现性能瓶颈导致，对象大小变大，队列阻塞，线程数上升，cpu使用率高，根据不同情况，推算出程序性能瓶颈，解决程序中因为多种因素产生的短板效应。c.内存溢出结果分析。当应用出现内存溢出时，根据内存泄露和大对象的结果可以分析出，应用程序是如何使用内存的，从而定位是否是内存泄露引起，还是内存分配不合理导致，给应用程序作出直接的诊断。

此外，某些实施例中，本申请实施的程序监控方法进一步包括：

S6：基于预设的深度学习性能分析模型，对所述系统性能数据进行分析，得到程序诊断结果；其中，所述深度学习性能分析模型根据所述程序的历史系统性能数据训练得到。

该实施例中，通过长时间的监控和数据收集，问题分析，可以获得很多具有价值的数据，这些数据可以帮助形成智能预测分析模型，通过深度神经网络算法对数据进行挖掘和分析。通过挑选特征值的方法，首先将所有收集到的性能指标数据格式化作为特征值参数，将所有问题的结果进行分类，分为无性能影响，程序逻辑方法执行时间长，使用大对象内存未对齐进行限制等，作为结果集，将海量的数据(去杂后，因为大多数情况下系统是正常的，去除长时间的正常数据才能使模型获得更好的特征学习)利用python的深度学习算法进行分析，可以得到一个性能问题，预测分析模型。通过深度学习算法，模型可以运用到分析海量的性能数据中，当监控程序收集到的指标开始出现性能异常时，模型就能进行报警和问题分析。通过训练好的模型算出对应的问题，给出智能的指导意见，并可以发现因为数据不足，压力不够等而未测试露出的深层性能容量问题，可以很好的守护生产安全，且在人力和成本上大大降低投入。

深度学习性能分析模型可以在线或者离线建立和训练，在某些实施例中，本申请进一步包括：

S01：建立所述深度学习性能分析模型；

S02：将所述程序的历史系统性能数据和对应的导致数据异常的原因作为训练集数据，对所述深度学习性能分析模型进行训练。

图1示出了实现本申请实施方式的场景架构示意图，如图1所示，其具体包括agent端、server端以及client端。

其中agent端负责收集软件系统的性能数据，将agent部署到应用服务器中，在启动加载项中添加启动参数，agent启动成功后，将收集JVM层性能指标，这些数据包括内存、CPU等各种类型。AGENT端会对数据进行暂存，然后批量发送给SERVER端。

通过增加agent的启动参数来启动javaagent，如：

-javaagent:/data/monitorAgent/monitor-agent.jar

应用程序与agent的隔离与通信如图2所示，同级加载的方式，一定程度保证了类的隔离，防止冲突与污染。

代码注入如图3，首先需要编写的注入代码类Monitor.java将其编译为monitor.class，在启动一个监听程序ListenHandle用来监听JVM的类加载执行，当监听到需要加载的类时将其拦截，使用asm将monitor.class中的代码插入到应用代码中。在给JVM去加载执行。

SERVER端2通过与agent连接接收来自多个AGENT端的数据，获取influxdb时序数据库的连接池，在进行数据格式化之后存储到时序存储数据库中。同时server端也同时获取mysql的数据库连接池，将格式化的数据同时放到mysql中性能存储。并同步一份数据给hadoop大数据平台进行智能分析。

CLIENT端3从时序存储数据库读取数据，根据配置的相关项目应用名按时序特征进行筛选，前台通过访问时序数据库查询，进行数据的图形化展示。

参见图4本方案的AGENT端的内部结构图。数据收集组件41、数据发送组件42。

数据收集组件41：对系统的各类性能数据进行收集。可以收集多种类型的数据。这样形成了一个完整的性能视图，表1示出了性能数据类别表。

表1-性能数据类别表

通过javaagent的方式加载后，Cpu、内存、线程、GC通过JMX的api接口进行性能数据的获取。

方法和对象的监控通过如图5的方式使用instrument来实现，BEFORE在方法执行前事件、throws抛出事件异常、return返回事件。这三类事件可以在方法执行前、返回和抛出异常这三种情况进行代码编制。被监控应用程序代码如下：

Public返回类型方法名(参数){

/*插入点Kind.ENTRY*/

Try{

//应用程序代码

Return；

/*插入点Kind.RETURN*/

}catch{

/*插入点Kind.THROW*/

}

通过编写如下代码进行耗时的获取，在方法开前后进行系统时间记录，计算获取方法执行时间duration，同样的可以获取到各方法对象创建的大小并记录给数据发送组件。监控代码编写实例如下：

MyInstrument{

Long start；

@OnMethod(method＝”方法名”，location＝location＝@Location(Kind.ENTRY))

public void doBefore(){

start＝System.currentTimeMillis()；

}

@OnMethod(name＝”方法名”，location＝location＝@Location(Kind.RETURN))

public void doAfter(@ProbeClassName String className,@ProbeMethodName(fqn＝true)String methodName){

long duration＝System.currentTimeMillis()-start；

String[]tokens＝methodName.split("#")；

ThreadTracer.enterMethod(className+"#"+tokens[1]，duration)；

}

同理可以用于监控程序创建对象的大小。

数据发送组件42：对收集的性能数据进行序列化，然后通过网络接口发送给SERVER端。这里采用的TCP的网络通讯方式，以及JSON的数据化格式。

参见图6本方案的SERVER端的内部结构图。数据接收组件61、数据处理组件62、数据存储组件63、数据分析组件64。

数据接收组件61：接收AGENT的数据，进行反序列化。与AGENT一致，采用TCP的网络通讯方式，按JSON格式进行数据的反序列化。

数据处理组件62：将接收的数据转为存储的时序格式。

数据存储组件63：将数据存储到时序存储数据库。同步持久化数据到mysql中和同步到hadoop平台。

数据分析组件64：根据各种数据分析模型，从数据中挖掘信息，提前预测问题。

主要使用的模型如表2所示：

表2数据分析模型列表

参见图7本方案的CLIENT端的内部结构图。数据提取组件71、数据展示组件72。

数据提取组件71：从时序数据库按查询规则提取数据。

数据展示组件72：按图形或者表格样式形象展示数据变化和规律。

通过上述场景架构的详细说明，可以理解，本申请通过将待监控程序和监控程序均编译为类文件，然后通过加载器加载的特性，将第一类文件和第二类文件委派到同一顶层进行加载，然后采用重新编译的方式，将第二类文件的代码注入到第一类文件中，然后通过加载的方式得到第一类文件对应运行程序的系统性能数据，通过该方式可以在不对系统进行改造，不需要加入额外的监控组件，能够在在不改变项目代码的前提下，无感知且高效精准的性能监控并自动化预测分析性能问题，进行高效的性能测试，本申请的方案对系统的侵入和影响更小，同时更具扩展性和维护性，在不修改源代码的情况，获取系统的性能指标情况和更为细粒度的方法执行和内存分配情况，获取的数据可以进行代码分析和数据挖掘，不在是通过人工去进行性能测试的检验和分析。通过程序可以智能的预测和分析问题，相比目前监控机制的各种常规方案，不仅能获取到更多的性能容量测试数据，而且具备智能分析无需人工作业，去人力且高效的优势。

下面从虚拟装置层面对本申请进行详细说明。

图9示出了本申请实施例提供的一种程序监控装置，包括：文件编译模块91，将待监控程序代码编译为第一类文件，监控程序代码编译为第二类文件；加载模块92，将所述第一类文件的加载请求发送至第一子类加载器，第二类文件的加载请求发送至第二子类加载器，以使所述第一子类加载器和第二子类加载器对应地将所述第一类文件和所述第二类文件委派至顶层的父类加载器进行加载；合并模块93，当监测到所述第一类文件被加载时，拦截并获取所述第一类文件的代码，将所述第二类文件的代码注入到第一类文件的代码中，重新编译形成合并类文件；系统性能数据获取模块94，通过加载所述合并类文件获取所述第一类文件中的系统性能数据；程序监控模块95，根据所述系统性能数据监控所述程序在系统中的运行状态。

基于相同的发明构思，本申请实施例提供的程序监控装置，通过将待监控程序和监控程序均编译为类文件，然后通过加载器加载的特性，将第一类文件和第二类文件委派到同一顶层进行加载，然后采用重新编译的方式，将第二类文件的代码注入到第一类文件中，然后通过加载的方式得到第一类文件对应运行程序的系统性能数据，通过该方式可以在不对系统进行改造，不需要加入额外的监控组件，能够在在不改变项目代码的前提下，无感知且高效精准的性能监控并自动化预测分析性能问题，进行高效的性能测试，本申请的方案对系统的侵入和影响更小，同时更具扩展性和维护性，在不修改源代码的情况，获取系统的性能指标情况和更为细粒度的方法执行和内存分配情况，获取的数据可以进行代码分析和数据挖掘，不在是通过人工去进行性能测试的检验和分析。通过程序可以智能的预测和分析问题，相比目前监控机制的各种常规方案，不仅能获取到更多的性能容量测试数据，而且具备智能分析无需人工作业，去人力且高效的优势。

基于相同的发明构思，一实施例中，所述合并模块利用Asm框架将第二类文件中的代码插入到第一类文件中。

基于相同的发明构思，一实施例中，所述程序监控模块将所述系统性能数据中对应的数据输入预设的内存泄漏模型、大对象分配模型、内存溢出模型以及耗时增长模型中的至少一个，根据至少一个模型的输出结果监控所述程序。

基于相同的发明构思，一实施例中，所述程序监控模块，包括：内存泄漏模型输入单元，将所述程序所在系统每个设定时长执行内存回收操作后的内存释放量和使用量输入所述内存泄漏模型；泄漏确定单元，根据所述内存泄漏模型输出的泄漏内存，确定泄漏风险；其中所述内存泄漏模型基于不同时间点的内存释放量和内存使用量确定内存总量，并根据所述内存总量的线性回归线的趋势确定内存是否存在泄漏。

基于相同的发明构思，一实施例中，所述程序监控模块，包括：大对象分配模型输入单元，将内存的分配数据输入至所述大对象分配模型，以使所述大对象分配模型根据预定义的内存阈值，将内存分配高于内存阈值的对象确定为大对象，触发大对象预警。

基于相同的发明构思，一实施例中，所述程序监控模块，包括：耗时增长曲线输入单元，将所述系统性能数据中的程序耗时数据输入所述耗时增长模型；运行耗时监控单元，根据所述耗时增长模型输出的耗时曲线，监控运行耗时。

基于相同的发明构思，一实施例中，还包括：诊断分析模块，基于预设的深度学习性能分析模型，对所述系统性能数据进行分析，得到程序诊断结果；其中，所述深度学习性能分析模型根据所述程序的历史系统性能数据训练得到。

基于相同的发明构思，一实施例中，还包括：深度学习性能分析模型建立模块，建立所述深度学习性能分析模型；模型训练模块，将所述程序的历史系统性能数据和对应的导致数据异常的原因作为训练集数据，对所述深度学习性能分析模型进行训练。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机设备，具体的，计算机设备例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

在一个典型的实例中计算机设备具体包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上所述的由客户端执行的方法，或者，所述处理器执行所述程序时实现如上所述的由服务器执行的方法。

下面参考图10，其示出了适于用来实现本申请实施例的计算机设备的结构示意图。

如图10所示，计算机设备包括中央处理单元(CPU)601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储部分608加载到随机访问存储器(RAM))603中的程序而执行各种适当的工作和处理。在RAM603中，还存储有系统操作所需的各种程序和数据。CPU601、ROM602、以及RAM603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

以下部件连接至I/O接口605：包括键盘、鼠标等的输入部分606；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分607；包括硬盘等的存储部分608；以及包括诸如LAN卡，调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至I/O接口605。可拆卸介质611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器610上，以便于从其上读出的计算机程序根据需要被安装如存储部分608。

特别地，根据本发明的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明的实施例包括一种计算机程序产品，其包括有形地包含在机器可读介质上的计算机程序，所述计算机程序包括用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分609从网络上被下载和安装，和/或从可拆卸介质611被安装。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

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

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims

1.一种程序监控方法，其特征在于，包括：

根据所述系统性能数据监控所述程序在系统中的运行状态。

2.根据权利要求1所述程序监控方法，其特征在于，所述将所述第二类文件的代码注入到第一类文件的代码中，包括：

利用Asm框架将第二类文件中的代码插入到第一类文件中。

3.根据权利要求1所述程序监控方法，其特征在于，所述根据所述系统性能数据监控所述程序在系统中的运行状态，包括：

4.根据权利要求1所述程序监控方法，其特征在于，将所述系统性能数据中对应的数据输入内存泄漏模型，根据所述内存泄漏模型的输出结果监控所述程序，包括：

5.根据权利要求3所述程序监控方法，其特征在于，将所述系统性能数据中对应的数据输入大对象分配模型，根据所述大对象分配模型的输出结果监控所述程序，包括：

6.根据权利要求3所述程序监控方法，其特征在于，将所述系统性能数据中对应的数据输入耗时增长模型，包括：

根据所述耗时增长模型输出的耗时曲线，监控运行耗时。

7.根据权利要求1所述程序监控方法，其特征在于，所述方法还包括：

8.根据权利要求7所述程序监控方法，其特征在于，还包括：

建立所述深度学习性能分析模型；

9.一种程序监控装置，其特征在于，包括：

10.根据权利要求9所述程序监控装置，其特征在于，所述合并模块利用Asm框架将第二类文件中的代码插入到第一类文件中。

11.根据权利要求9所述程序监控装置，其特征在于，所述程序监控模块将所述系统性能数据中对应的数据输入预设的内存泄漏模型、大对象分配模型、内存溢出模型以及耗时增长模型中的至少一个，根据至少一个模型的输出结果监控所述程序。

12.根据权利要求11所述程序监控装置，其特征在于，所述程序监控模块，包括：

13.根据权利要求11所述程序监控装置，其特征在于，所述程序监控模块，包括：

14.根据权利要求11所述程序监控装置，其特征在于，所述程序监控模块，包括：

15.根据权利要求9所述程序监控装置，其特征在于，还包括：

16.根据权利要求15所述程序监控装置，其特征在于，还包括：

17.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至8任一项所述的方法。

18.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至8任一项所述的方法。