CN106250292B - 一种办公管理系统性能监控平台 - Google Patents

Abstract

本发明公开了一种办公管理系统性能监控平台，包括日志采集子系统、日志分析子系统和警告、干预子系统；日志采集子系统分为内存日志采集模块、线程日志采集模块和SQL执行日志采集模块；日志分析子系统包括性能瓶颈分析模块、线程执行分析模块和内存分析模块；警告、干预子系统，包括警告模块和强制干预模块。本发明可以对正在运行的生成系统进行及时分析，不需要部署，不用引入第三方的特殊依赖，只需要使用系统本来就运行其上的jdk的自带工具就可以实现，同时通过开发一下的日志分析工具，可以时候对日志进行智能分析，协助排查宕机问题和性能问题的原因，完成数据的监控和采集，对系统性能影响很小，保证生产系统不会受到监控工具本身的影响。

Description

一种办公管理系统性能监控平台

技术领域

本发明涉及一种基于java代理的一种sql语句的监控方法，以及继续线程日志的性能、宕机分析方法，尤其是指一种办公管理系统性能监控平台。

背景技术

由于现有的公司的办公管理系统越来越复杂，用户的并发量也越来越大，使系统不稳定，容易宕机。因此系统的稳定性变得越来越重要，需要有一套好的机制来监控系统的运行状况，同时也需要有一套分析方法，能够事后快速定位宕机问题的原因，及时的修补标准产品的重大宕机bug，以保证系统的稳定性。当前已有的用于解决该稳定的工具为：第三方的jprofiler、btrace，这些工具比较重量级，部署复杂，甚至需要大量开发。现有技术中，由于没有很好的图形化界面，主要是通过命令行以及一些日志分析工具进行问题分析，主要通过用户技术开发人员分析系统宕机和性能问题。

发明内容

为了解决上述问题，本发明提供了一种办公管理系统性能监控平台，其目的在于解决现有技术不能很好地对办公管理系统的稳定性进行监控、分析的问题。

一种办公管理系统性能监控平台，包括日志采集子系统、日志分析子系统和警告、干预子系统；

所述日志采集子系统分为内存日志采集模块、线程日志采集模块和SQL执行日志采集模块；

其中，内存日志采集模块，使用JVM Management API采集当前办公管理系统的JVM的内存信息，采集的信息包括：采集时间、临时代、年轻代、年老代、持久代、各代GC的次数和时间。

SQL执行日志采集模块，采用java代理，动态修改字节码。考虑到要监控系统运行的sql语句，必须修改系统的数据库包装类，而不同的OA软件版本该包装类可能不一样，如果直接修改，就没办法通过直接覆盖的方式部署性能监控平台，因此通过字节码方式，动态的在运行期在保障类的excelSql的方法前后加上统计代码，统计SQL语句执行的时间，以及返回的数据量，通过两个过滤条件来过滤日志：执行时间超过10秒的sql语句和返回数据量超过10000条的sql语句，其中10和10000都是可配置的，打印日志的同时打印出当时的线程堆栈，判断sql语句具体在代码的位置。

以上的日志采集的信息包含了系统运行的所有状态信息，通过分析这些日志就可以判断出当前办公管理系统运行的状态，以及系统性能和宕机问题的原因。

所述日志分析子系统包括性能瓶颈分析模块、线程执行分析模块和内存分析模块；

其中，性能瓶颈分析模块，基于Jprofiler工具通过分析一段时间的线程日志，判断程序执行的瓶颈点，一次来协助开发人员对程序进行优化。

算法使用的基本原理是：通过统计一段时间的线程日志中和某个程序（要分析的程序）的相关线程，找到这些线程正在运行的代码行（正在运行的点），然后统计出这些运行点的数量，由于线程基本上是随机获取的，因此有如下原理：某个运行点（代码行）出现的次数越多，代表其运行的越慢（或者运行的次数越多），瓶颈度越大，按照数量倒排序就可以统计出上面的瓶颈参考信息，同时结合堆栈的层级结构，就可以把瓶颈信息以树形的结构展示出来。

线程执行分析模块，基于longtime工具进行分析。给定一段时间的线程日志，分析出这段时间运行比较慢的程序，以及这些运行较慢的程序的相关信息，通过图形的方式直观表现，统计出程序连续的执行时间。

算法的基本原理是：如果在同一个线程里（线程号相等）而且连续的两个线程日志中发现相同的程序，则认为这个程序在这两个线程日志中间的时间里也一直存在于这个线程内，因为web应用服务器的线程池里一般有1000多个线程，新的请求是随机的，一个请求第一次在某个线程，结束后下个请求会随机再分配一个线程处理，如果是两个不同的程序，连续紧接着被分配到同一个线程的概率只有1/1000*1000，如果连续三次，则概率为1/1000*1000*1000，概率极小，因此通过离散的线程日志，可以统计出程序连续的执行时间。

内存分析模块，分析JVM内存，根据内存的老年代的变化曲线判定系统是否已经内存溢出，计算老年代的占比是否正常，若垃圾回收后占比大于90%，则表示内存即将溢出，进行预警，若垃圾回收后占比大于99%，则系统已经宕机，需要立即通知或强制干预重启系统。

所述警告、干预子系统，包括警告模块和强制干预模块，

其中，警告模块通过SMS短信发送至代理接口进行短信的提醒发送，通过办公管理系统提供的webservice接口动态创建内部流程进行提醒。

强制干预模块通过Resin提供的Resin.restart() 方法进行web应用服务器的重启操作。

通过警告和强制干预，可以最小化的降低系统异常对用户造成的影响。

本发明对比现有技术具有以下优势：1、可以对正在运行的生成系统进行及时分析，2、不需要部署，不用引入第三方的特殊依赖，只需要使用系统本来就运行其上的 jdk的自带工具就可以实现，同时通过开发一下的日志分析工具，可以时候对日志进行智能分析，协助排查宕机问题和性能问题的原因，完成数据的监控和采集，3、对系统性能影响很小，保证生产系统不会受到监控工具本身的影响。

附图说明

图1为办公管理系统性能监控平台的示意图。

具体实施方式

本发明的具体实施方式如下：

一种办公管理系统性能监控平台，包括日志采集子系统、日志分析子系统和警告、干预子系统；

所述日志采集子系统分为内存日志采集模块1、线程日志采集模块2和SQL执行日志采集模块3；

其中，内存日志采集模块1，使用JVM Management API采集当前办公管理系统的JVM的内存信息，采集的信息包括：采集时间、临时代、年轻代、年老代、持久代、各代GC的次数和时间。

使用如下方法即可获得：

ManagementFactory.getMemoryPoolMXBeans().get(0);

List beans = ManagementFactory.getMemoryPoolMXBeans();

String bname;

for (MemoryPoolMXBean bean : beans) {

bname = bean.getName().toLowerCase();

if (bname.indexOf("Eden Space".toLowerCase()) != -1) {

MemoryUsage usage = bean.getUsage();

this.mb.setECommitted(usage.getCommitted() / 1024L);

this.mb.setEUsed(usage.getUsed() / 1024L);

} else if (bname.indexOf("Survivor Space".toLowerCase()) != -1) {

MemoryUsage usage = bean.getUsage();

this.mb.setSCommitted(this.mb.getSCommitted() +usage.getCommitted() / 1024L);

this.mb.setSUsed(this.mb.getSUsed() + usage.getUsed() /1024L);

} else if ((bname.indexOf("Tenured Gen".toLowerCase()) != -1) ||(bname.indexOf("Old Gen".toLowerCase()) != -1)) {

MemoryUsage usage = bean.getUsage();

this.mb.setTCommitted(this.mb.getTCommitted() +usage.getCommitted() / 1024L);

this.mb.setTUsed(this.mb.getTUsed() + usage.getUsed() /1024L);

} else {

if (bname.indexOf("Perm Gen".toLowerCase()) == -1)

continue;

MemoryUsage usage = bean.getUsage();

this.mb.setPCommitted(usage.getCommitted() / 1024L);

this.mb.setPUsed(usage.getUsed() / 1024L);

}

}

获取到的信息以如下的格式存放：

其中临时（S）、年轻（E）、年老（O）、持久（P）：为百分比。

YGC：年轻带E进行垃圾回收的次数；

YGCT：年轻带E进行垃圾回收耗费的总时间；

FGC：年老带O进行垃圾回收的次数；

FGCT：年老带O进行垃圾回收耗费的总时间；

GCT：垃圾回收耗费的总时间。

以上信息使用文本文件存储，文件名称为 memory-日期.txt 每天对应一个文件。

线程日志采集模块2，通过ManagementFactory.getThreadMXBean().getAllThreadIds() 可得到所有线程的信息；然后按照如下的格式输出到文本文件： "http--80-3$902494946" id="1362" CPU Time=460000000

java.lang.Thread.State: RUNNABLE

at java.net.PlainSocketImpl.socketAccept(Native Method)

at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)

at java.net.ServerSocket.implAccept(ServerSocket.java:462)

at java.net.ServerSocket.accept(ServerSocket.java:430)

at com.caucho.vfs.QServerSocketWrapper.accept(QServerSocketWrapper.java:91)

at com.caucho.server.port.Port.accept(Port.java:1179)

at com.caucho.server.port.TcpConnection.run(TcpConnection.java:659)

at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:730)

at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:649)

at java.lang.Thread.run(Thread.java:662)

其中包括日志生成时间、线程号、线程占用的cpu时间、线程的堆栈、线程的运行状态。

其他剩余信息都可以通过对应的api 获得，线程日志每个5分钟生成一个文件，每天生成一个thread-日期 名字的目录。

SQL执行日志采集模块3，采用java代理，动态修改字节码。考虑到要监控系统运行的sql语句，必须修改系统的数据库包装类，而不同的OA软件版本该包装类可能不一样，如果直接修改，就没办法通过直接覆盖的方式部署性能监控平台，因此通过字节码方式，动态的在运行期在保障类的excelSql的方法前后加上统计代码，统计SQL语句执行的时间，以及返回的数据量，通过两个过滤条件来过滤日志：执行时间超过10秒的sql语句和返回数据量超过10000条的sql语句，其中10和10000都是可配置的，打印日志的同时打印出当时的线程堆栈，判断sql语句具体在代码的位置。

日志分别输出在下面两个文件：

时间超时：sqltime-日期.txt；

日期超时：sqlcount-日期.txt；

日志格式如下：

2016-03-14 00:02:24 time=18736:count=1:[这里显示具体的sql语句]

java.lang.Throwable

at weaver.monitor.monitor.SQLExeMonitor.logCount(SQLExeMonitor.java:49)

at weaver.conn.aop.RecordSetAop.executeSql_after(RecordSetAop.java:23)

at weaver.conn.RecordSet.executeSql(RecordSet.java:259)

at weaver.login.LicenseCheckLogin.setOutLineDate(LicenseCheckLogin.java:83)

at weaver.workflow.msg.MsgUtil.getPopupMsg(MsgUtil.java:34)

at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at uk.ltd.getahead.dwr.impl.ExecuteQuery.execute(ExecuteQuery.java:170)

at uk.ltd.getahead.dwr.impl.DefaultProcessor.doExec(DefaultProcessor.java:552)

at uk.ltd.getahead.dwr.impl.DefaultProcessor.handle(DefaultProcessor.java:88)

at uk.ltd.getahead.dwr.DWRServlet.doPost(DWRServlet.java:178)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:153)

其中包括SQL执行时间、SQL执行耗费的时间、SQL返回的数据量、具体的SQL语句和SQL语句在代码中的位置。

以上的日志采集的信息包含了系统运行的所有状态信息，通过分析这些日志就可以判断出当前办公管理系统运行的状态，以及系统性能和宕机问题的原因。

所述日志分析子系统包括性能瓶颈分析模块4、线程执行分析模块5和内存分析模块6；

其中，性能瓶颈分析模块4，基于Jprofiler工具通过分析一段时间的线程日志，判断程序执行的瓶颈点，以此来协助开发人员对程序进行优化。这个工具的输出结果如下：

从上到下列出了依次最耗费cpu的代码行。

算法使用的基本原理是：通过统计一段时间的线程日志中和某个程序（要分析的程序）的相关线程，找到这些线程正在运行的代码行（正在运行的点），然后统计出这些运行点的数量，由于线程基本上是随机获取的，因此有如下原理：某个运行点（代码行）出现的次数越多，代表其运行的越慢（或者运行的次数越多），瓶颈度越大，按照数量倒排序就可以统计出上面的瓶颈参考信息，同时结合堆栈的层级结构，就可以把瓶颈信息以树形的结构展示出来。

线程执行分析模块5，基于longtime工具进行分析。给定一段时间的线程日志，分析出这段时间运行比较慢的程序，以及这些运行较慢的程序的相关信息，通过图形的方式直观表现，统计出程序连续的执行时间。

输出代表运行程序的图形：长度代表时间，位置代表执行开始时间，鼠标放到该图形上会显示程序的详细信息。以便查看运行较慢的程序及其运行时长，运行时间。

算法的基本原理是：如果在同一个线程里（线程号相等）而且连续的两个线程日志中发现相同的程序，则认为这个程序在这两个线程日志中间的时间里也一直存在于这个线程内，因为web应用服务器的线程池里一般有1000多个线程，新的请求是随机的，一个请求第一次在某个线程，结束后下个请求会随机再分配一个线程处理，如果是两个不同的程序，连续紧接着被分配到同一个线程的概率只有1/1000*1000，如果连续三次，则概率为1/1000*1000*1000，概率极小，因此通过离散的线程日志，可以统计出程序连续的执行时间。

内存分析模块6，分析JVM内存，根据内存的老年代的变化曲线判定系统是否已经内存溢出，计算老年代的占比是否正常，若垃圾回收后占比大于90%，则表示内存即将溢出，进行预警，若垃圾回收后占比大于99%，则系统已经宕机，需要立即通知或强制干预重启系统。

所述警告、干预子系统，包括警告模块7和强制干预模块8，

其中，警告模块7通过SMS短信发送代理接口进行短信的提醒发送，通过办公管理系统提供的webservice接口动态创建内部流程进行提醒。

强制干预模块8通过Resin提供的Resin.restart() 方法进行web应用服务器的重启操作。

通过警告和强制干预，可以最小化的降低系统异常对用户造成的影响。

上述描述已经详细阐述了发明的说明和描述。它不是为了将本发明限制为所披露的形式和方式。按照以上的方式，可以进行相应的修改或更改。讨论实例是为了更好地说明本发明的原理及其实用性,从而利用本发明进行各种修改并满足其它特定的需求。所有这些修改和变化当依照公平和合法的权利解读，并且根据附加权利要求，这些修改和变化都属于本发明的范围内。

Claims (1)

1.一种办公管理系统性能监控平台，其特征在于：包括日志采集子系统、日志分析子系统和警告、干预子系统；

所述日志采集子系统分为内存日志采集模块、线程日志采集模块和SQL执行日志采集模块；

其中，内存日志采集模块，使用JVM Management API采集当前办公管理系统的JVM的内存信息，采集的信息包括：采集时间、临时代、年轻代、年老代、持久代、各代GC的次数和时间；

线程日志采集模块，通过ManagementFactory.getThreadMXBean().getAllThreadIds() 可得到所有线程的信息；

SQL执行日志采集模块，采用java代理，动态修改字节码，在保障类的excelSql的方法前后加上统计代码，统计SQL语句执行的时间，以及返回的数据量，通过两个过滤条件来过滤日志：执行时间超过10秒的sql语句和返回数据量超过10000条的sql语句，其中10和10000都是可配置的，打印日志的同时打印出当时的线程堆栈，判断sql语句具体在代码中的位置；

所述日志分析子系统包括性能瓶颈分析模块、线程执行分析模块和内存分析模块；

其中，性能瓶颈分析模块，基于Jprofiler工具通过分析一段时间的线程日志，判断程序执行的瓶颈点；

线程执行分析模块，基于longtime工具统计出程序连续的执行时间；

内存分析模块，分析JVM内存，根据内存的老年代的变化曲线判定系统是否已经内存溢出，计算老年代的占比，若垃圾回收后占比大于90%，则表示内存即将溢出，进行预警，若垃圾回收后占比大于99%，则系统已经宕机，需要立即通知或强制干预重启系统；

所述警告、干预子系统，包括警告模块和强制干预模块，

其中，警告模块通过SMS短信发送至代理接口进行短信的提醒发送，通过办公管理系统提供的webservice接口动态创建内部流程进行提醒；

强制干预模块通过Resin提供的Resin.restart() 方法进行web应用服务器的重启操作。