本發(fā)明涉及一種基于java代理的一種sql語句的監(jiān)控方法，以及繼續(xù)線程日志的性能、宕機分析方法，尤其是指一種辦公管理系統(tǒng)性能監(jiān)控平臺。
背景技術(shù)：
由于現(xiàn)有的公司的辦公管理系統(tǒng)越來越復(fù)雜，用戶的并發(fā)量也越來越大，使系統(tǒng)不穩(wěn)定，容易宕機。因此系統(tǒng)的穩(wěn)定性變得越來越重要，需要有一套好的機制來監(jiān)控系統(tǒng)的運行狀況，同時也需要有一套分析方法，能夠事后快速定位宕機問題的原因，及時的修補標準產(chǎn)品的重大宕機bug，以保證系統(tǒng)的穩(wěn)定性。當前已有的用于解決該穩(wěn)定的工具為：第三方的jprofiler、btrace，這些工具比較重量級，部署復(fù)雜，甚至需要大量開發(fā)?，F(xiàn)有技術(shù)中，由于沒有很好的圖形化界面，主要是通過命令行以及一些日志分析工具進行問題分析，主要通過用戶技術(shù)開發(fā)人員分析系統(tǒng)宕機和性能問題。
技術(shù)實現(xiàn)要素：
為了解決上述問題，本發(fā)明提供了一種辦公管理系統(tǒng)性能監(jiān)控平臺，其目的在于解決現(xiàn)有技術(shù)不能很好地對辦公系統(tǒng)的穩(wěn)定性進行監(jiān)控、分析的問題。
一種辦公管理系統(tǒng)性能監(jiān)控平臺，包括日志采集子系統(tǒng)、日志分析子系統(tǒng)和警告、干預(yù)子系統(tǒng)；
所述日志采集子系統(tǒng)分為內(nèi)存日志采集模塊、線程日志采集模塊和SQL執(zhí)行日志采集模塊；
其中，內(nèi)存日志采集模塊，使用JVM Management API采集當前系統(tǒng)的JVM的內(nèi)存信息，采集的信息包括：采集時間、臨時代、年輕代、年老代、持久代、各代GC的次數(shù)和時間。
SQL執(zhí)行日志采集模塊，采用java代理，動態(tài)修改字節(jié)碼。考慮到要監(jiān)控系統(tǒng)運行的sql語句，必須修改系統(tǒng)的數(shù)據(jù)庫包裝類，而不同的OA軟件版本該包裝類可能不一樣，如果直接修改，就沒辦法通過直接覆蓋的方式部署性能監(jiān)控平臺，因此通過字節(jié)碼方式，動態(tài)的在運行期在保障類的excelSql的方法前后加上統(tǒng)計代碼，統(tǒng)計SQL語句執(zhí)行的時間，以及返回的數(shù)據(jù)量，通過兩個過濾條件來過濾日志：時間超過10秒的sql和返回數(shù)據(jù)量操作10000條的sql，其中10和10000都是可配置的，打印日志的同時打印出當時的線程堆棧，判斷sql語句具體在代碼的位置。
以上的日志采集的信息包含了系統(tǒng)運行的所有狀態(tài)信息，通過分析這些日志就可以判斷出當前系統(tǒng)運行的狀態(tài)，以及系統(tǒng)性能和宕機問題的原因。
所述日志分析子系統(tǒng)包括性能瓶頸分析模塊、線程執(zhí)行分析模塊和內(nèi)存分析模塊；
其中，性能瓶頸分析模塊，基于Jprofiler工具通過分析一段時間的線程日志，判斷程序執(zhí)行的瓶頸點，一次來協(xié)助開發(fā)人員對程序進行優(yōu)化。
算法使用的基本原理是：通過統(tǒng)計一段時間的線程日志中和某個程序（要分析的程序）的相關(guān)線程，找到這些線程正在運行的代碼行（正在運行的點），然后統(tǒng)計出這些運行點的數(shù)量，由于線程基本上是隨機獲取的，因此有如下原理：某個運行點（代碼行）出現(xiàn)的次數(shù)越多，代表其運行的越慢（或者運行的次數(shù)越多），瓶頸度越大，按照數(shù)量倒排序就可以統(tǒng)計出上面的瓶頸參考信息，同時結(jié)合堆棧的層級結(jié)構(gòu)，就可以把瓶頸信息以樹形的結(jié)構(gòu)展示出來。
線程執(zhí)行分析模塊，基于longtime工具進行分析。給定一段時間的線程日志，分析出這段時間運行比較慢的程序，以及這些運行較慢的程序的相關(guān)信息，通過圖形的方式直觀表現(xiàn)，統(tǒng)計出程序連續(xù)的執(zhí)行時間。
算法的基本原理是：如果在同一個線程里（線程號相等）而且連續(xù)的兩個線程日志中發(fā)現(xiàn)相同的程序，則認為這個程序在這兩個線程日志中間的時間里也一直存在于這個線程內(nèi)，因為web應(yīng)用服務(wù)器的線程池里一般有1000多個線程，新的請求是隨機的，一個請求第一次在某個線程，結(jié)束后下個請求會隨機再分配一個線程處理，如果是兩個不同的程序，連續(xù)緊接著被分配到同一個線程的概率只有1/1000*1000，如果連續(xù)三次，則概率為1/1000*1000*1000，概率極小，因此通過離散的線程日志，可以統(tǒng)計出程序連續(xù)的執(zhí)行時間。
內(nèi)存分析模塊，分析JVM內(nèi)存，根據(jù)內(nèi)存的老年代的變化曲線判定系統(tǒng)是否已經(jīng)內(nèi)存溢出，計算老年代的占比是否正常，若垃圾回收后占比大于90%，則表示內(nèi)存即將溢出，進行預(yù)警，若垃圾回收后占比大于99%，則系統(tǒng)已經(jīng)宕機，需要立即通知或強制干預(yù)重啟系統(tǒng)。
所述警告、干預(yù)子系統(tǒng)，包括警告模塊和強制干預(yù)模塊，
其中，警告模塊通過SMS短信發(fā)送代理接口進行短信的提醒發(fā)送，通過辦公系統(tǒng)提供的webservice接口動態(tài)創(chuàng)建內(nèi)部流程進行提醒。
強制干預(yù)模塊通過Resin提供的Resin.restart() 方法進行web應(yīng)用服務(wù)器的重啟操作。
通過警告和強制干預(yù)，可以最小化的降低系統(tǒng)異常對用戶造成的影響。
本發(fā)明對比現(xiàn)有技術(shù)具有以下優(yōu)勢：1、可以對正在運行的生成系統(tǒng)進行及時分析，2、不需要部署，不用引入第三方的特殊依賴，只需要使用系統(tǒng)本來就運行其上的 jdk的自帶工具就可以實現(xiàn)，同時通過開發(fā)一下的日志分析工具，可以時候?qū)θ罩具M行智能分析，協(xié)助排查宕機問題和性能問題的原因，完成數(shù)據(jù)的監(jiān)控和采集，3、對系統(tǒng)性能影響很小，保證生產(chǎn)系統(tǒng)不會受到監(jiān)控工具本身的影響。
附圖說明
圖1為辦公管理系統(tǒng)性能監(jiān)控平臺的示意圖。
具體實施方式
本發(fā)明的具體實施方式如下：
一種辦公管理系統(tǒng)性能監(jiān)控平臺，包括日志采集子系統(tǒng)、日志分析子系統(tǒng)和警告、干預(yù)子系統(tǒng)；
所述日志采集子系統(tǒng)分為內(nèi)存日志采集模塊1、線程日志采集模塊2和SQL執(zhí)行日志采集模塊3；
其中，內(nèi)存日志采集模塊1，使用JVM Management API采集當前系統(tǒng)的JVM的內(nèi)存信息，采集的信息包括：采集時間、臨時代、年輕代、年老代、持久代、各代GC的次數(shù)和時間。
使用如下方法即可獲得：
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進行垃圾回收的次數(shù)；
YGCT：年輕帶E進行垃圾回收耗費的總時間；
FGC：年老帶O進行垃圾回收的次數(shù)；
FGCT：年老帶O進行垃圾回收耗費的總時間；
GCT：垃圾回收耗費的總時間。
以上信息使用文本文件存儲，文件名稱為 memory-日期.txt 每天對應(yīng)一個文件。
線程日志采集模塊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時間、線程的堆棧、線程的運行狀態(tài)。
其他剩余信息都可以通過對應(yīng)的api 獲得，線程日志每個5分鐘生成一個文件，每天生成一個thread-日期 名字的目錄。
SQL執(zhí)行日志采集模塊3，采用java代理，動態(tài)修改字節(jié)碼。考慮到要監(jiān)控系統(tǒng)運行的sql語句，必須修改系統(tǒng)的數(shù)據(jù)庫包裝類，而不同的OA軟件版本該包裝類可能不一樣，如果直接修改，就沒辦法通過直接覆蓋的方式部署性能監(jiān)控平臺，因此通過字節(jié)碼方式，動態(tài)的在運行期在保障類的excelSql的方法前后加上統(tǒng)計代碼，統(tǒng)計SQL語句執(zhí)行的時間，以及返回的數(shù)據(jù)量，通過兩個過濾條件來過濾日志：時間超過10秒的sql和返回數(shù)據(jù)量操作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執(zhí)行時間、SQL執(zhí)行耗費的時間、SQL返回的數(shù)據(jù)量、具體的SQL語句和SQL語句在代碼中的位置。
以上的日志采集的信息包含了系統(tǒng)運行的所有狀態(tài)信息，通過分析這些日志就可以判斷出當前系統(tǒng)運行的狀態(tài)，以及系統(tǒng)性能和宕機問題的原因。
所述日志分析子系統(tǒng)包括性能瓶頸分析模塊4、線程執(zhí)行分析模塊5和內(nèi)存分析模塊6；
其中，性能瓶頸分析模塊4，基于Jprofiler工具通過分析一段時間的線程日志，判斷程序執(zhí)行的瓶頸點，以此來協(xié)助開發(fā)人員對程序進行優(yōu)化。這個工具的輸出結(jié)果如下：
[100.00%=6]:ROOT
[33.33%=2]:at _jsp._workflow._request._managerequestnoform__jsp._jspService(_managerequestnoform__jsp.java:1653)
[33.33%=2]:at weaver.conn.RecordSet.executeSql(RecordSet.java:341)
[33.33%=2]:at _jsp._workflow._request._managerequestnoform__jsp._jspService(_managerequestnoform__jsp.java:1202)
[33.33%=2]:at weaver.workflow.workflow.WfFunctionManageUtil.haveStopright(WfFunctionManageUtil.java:161)
[16.67%=1]:at _jsp._workflow._request._managerequestnoform__jsp._jspService(_managerequestnoform__jsp.java:2743)
[16.67%=1]:at weaver.hrm.resource.HrmListValidate.(HrmListValidate.java:20)
[16.67%=1]:at _jsp._workflow._request._managerequestnoform__jsp._jspService(_managerequestnoform__jsp.java:1484)
從上到下列出了依次最耗費cpu的代碼行。
算法使用的基本原理是：通過統(tǒng)計一段時間的線程日志中和某個程序（要分析的程序）的相關(guān)線程，找到這些線程正在運行的代碼行（正在運行的點），然后統(tǒng)計出這些運行點的數(shù)量，由于線程基本上是隨機獲取的，因此有如下原理：某個運行點（代碼行）出現(xiàn)的次數(shù)越多，代表其運行的越慢（或者運行的次數(shù)越多），瓶頸度越大，按照數(shù)量倒排序就可以統(tǒng)計出上面的瓶頸參考信息，同時結(jié)合堆棧的層級結(jié)構(gòu)，就可以把瓶頸信息以樹形的結(jié)構(gòu)展示出來。
線程執(zhí)行分析模塊5，基于longtime工具進行分析。給定一段時間的線程日志，分析出這段時間運行比較慢的程序，以及這些運行較慢的程序的相關(guān)信息，通過圖形的方式直觀表現(xiàn)，統(tǒng)計出程序連續(xù)的執(zhí)行時間。
輸出代表運行程序的圖形：長度代表時間，位置代表執(zhí)行開始時間，鼠標放到該圖形上會顯示程序的詳細信息。以便查看運行較慢的程序及其運行時長，運行時間。
算法的基本原理是：如果在同一個線程里（線程號相等）而且連續(xù)的兩個線程日志中發(fā)現(xiàn)相同的程序，則認為這個程序在這兩個線程日志中間的時間里也一直存在于這個線程內(nèi)，因為web應(yīng)用服務(wù)器的線程池里一般有1000多個線程，新的請求是隨機的，一個請求第一次在某個線程，結(jié)束后下個請求會隨機再分配一個線程處理，如果是兩個不同的程序，連續(xù)緊接著被分配到同一個線程的概率只有1/1000*1000，如果連續(xù)三次，則概率為1/1000*1000*1000，概率極小，因此通過離散的線程日志，可以統(tǒng)計出程序連續(xù)的執(zhí)行時間。
內(nèi)存分析模塊6，分析JVM內(nèi)存，根據(jù)內(nèi)存的老年代的變化曲線判定系統(tǒng)是否已經(jīng)內(nèi)存溢出，計算老年代的占比是否正常，若垃圾回收后占比大于90%，則表示內(nèi)存即將溢出，進行預(yù)警，若垃圾回收后占比大于99%，則系統(tǒng)已經(jīng)宕機，需要立即通知或強制干預(yù)重啟系統(tǒng)。
所述警告、干預(yù)子系統(tǒng)，包括警告模塊7和強制干預(yù)模塊8，
其中，警告模塊7通過SMS短信發(fā)送代理接口進行短信的提醒發(fā)送，通過辦公系統(tǒng)提供的webservice接口動態(tài)創(chuàng)建內(nèi)部流程進行提醒。
強制干預(yù)模塊8通過Resin提供的Resin.restart() 方法進行web應(yīng)用服務(wù)器的重啟操作。
通過警告和強制干預(yù)，可以最小化的降低系統(tǒng)異常對用戶造成的影響。
上述描述已經(jīng)詳細闡述了發(fā)明的說明和描述。它不是為了將本發(fā)明限制為所披露的形式和方式。按照以上的方式，可以進行相應(yīng)的修改或更改。討論實例是為了更好地說明本發(fā)明的原理及其實用性,從而利用本發(fā)明進行各種修改并滿足其它特定的需求。所有這些修改和變化當依照公平和合法的權(quán)利解讀，并且根據(jù)附加權(quán)利要求，這些修改和變化都屬于本發(fā)明的范圍內(nèi)。