Java監視工具的選擇非常廣泛（由Google提供的隨機選擇和順序）：

javamelody

壓力探頭

JVisualVM

控制臺

賈蒙

Java JMX Nagios插件不適用

此外，還有各種專用工具，例如ActiveMQ ， JBoss ， Quartz Scheduler ， Tomcat / tcServer ……那么您應該使用哪一個作為最終的監視儀表板？ 好吧，它們都不提供您可能需要的即用型功能。 在某些應用程序中，您必須不斷監視給定JMS隊列的內容和大小。 已知其他一些存在內存或CPU問題。 我還看到了系統管理員必須不斷運行一些SQL查詢并檢查結果甚至分析日志以確保某些基本后臺進程正在運行的軟件。 可能性是無止境的，因為它實際上取決于軟件及其用例。 更糟糕的是，您的客戶并不關心GC活動，打開的JDBC連接數量以及此令人討厭的批處理進程是否掛起。 它應該工作 。

在本文中，我們將嘗試開發簡單，廉價但功能強大的管理控制臺。 它將基于單個二進制結果的思想構建-是否有效。 如果單個運行狀況指示器為綠色，則無需進一步說明。 但！ 如果它變成紅色，我們可以輕松地向下鉆取。 之所以可能，是因為我們沒有顯示數百個不相關的指標，而是將它們分組為樹狀結構。 樹中每個節點的健康狀況與最壞的孩子一樣糟糕。 這樣，如果我們的應用程序發生任何不良情況，它將冒泡。

我們不會強迫系統管理員不斷監視多個指標。 我們決定什么是重要的，即使是我們軟件中最微小的一部分也出現了故障，它也會彈出。 將其與沒有綠色/紅色版本和電子郵件通知的連續集成服務器進行比較。 相反，您必須每隔一個構建就去服務器，并手動檢查代碼是否正在編譯以及所有測試是否都是綠色的。 日志和結果在那里，但是為什么要解析它們并手動匯總呢？ 這就是我們試圖在我們自己的監控解決方案中避免的事情。

作為基礎，我選擇了Jolokia JMX到HTTP橋（這不是第一次 ）。 JVM已經提供了監視基礎結構，那么為什么要重新發明它呢？ 同樣由于Jolokia，整個儀表板都可以在客戶端JavaScript中實現。 這具有幾個優點：服務器占用空間最小，還允許我們通過添加度量標準或更改警報閾值來快速調整度量標準。

我們將從將各種JMX指標下載到客戶端（瀏覽器）開始。 我已經開發了一些用于演示目的的小型應用程序，其中使用了盡可能多的技術（例如Tomcat，Spring，Hibernate，ActiveMQ，Quartz等）。由于我發現Jolokia有點麻煩，所以我沒有使用內置的JavaScript客戶端庫 。 但是正如您所看到的，獲取大量指標只是一個AJAX調用的問題。

function request() {var mbeans = ["java.lang:type=Memory","java.lang:type=MemoryPool,name=Code Cache","java.lang:type=MemoryPool,name=PS Eden Space","java.lang:type=MemoryPool,name=PS Old Gen","java.lang:type=MemoryPool,name=PS Perm Gen","java.lang:type=MemoryPool,name=PS Survivor Space","java.lang:type=OperatingSystem","java.lang:type=Runtime","java.lang:type=Threading",'Catalina:name="http-bio-8080",type=ThreadPool','Catalina:type=GlobalRequestProcessor,name="http-bio-8080"','Catalina:type=Manager,context=/jmx-dashboard,host=localhost','org.hibernate:type=Statistics,application=jmx-dashboard',"net.sf.ehcache:type=CacheStatistics,CacheManager=jmx-dashboard,name=org.hibernate.cache.StandardQueryCache","net.sf.ehcache:type=CacheStatistics,CacheManager=jmx-dashboard,name=org.hibernate.cache.UpdateTimestampsCache","quartz:type=QuartzScheduler,name=schedulerFactory,instance=NON_CLUSTERED",'org.apache.activemq:BrokerName=localhost,Type=Queue,Destination=requests',"com.blogspot.nurkiewicz.spring:name=dataSource,type=ManagedBasicDataSource"];return _.map(mbeans, function(mbean) {return {type:'read',mbean: mbean}});
}$.ajax({url: 'jmx?ignoreErrors=true',type: "POST",dataType: "json",data: JSON.stringify(request()),contentType: "application/json",success: function(response) {displayRawData(response);}
});

只是為了向您概述客戶端可訪問的信息種類，我們將首先轉儲所有內容并將其顯示在jQuery UI手風琴上 ：

function displayRawData(fullResponse) {_(fullResponse).each(function (response) {var content = $('<pre/>').append(JSON.stringify(response.value, null, '\t'));var header = $('<h3/>').append($("<a/>", {href:'#'}).append(response.request.mbean));$('#rawDataPanel').append(header).append($('<div/>').append(content));});$('#rawDataPanel').accordion({autoHeight: false, collapsible: true});
}

請記住，這只是出于參考和調試的目的，我們并不是要顯示無盡的JMX屬性列表。

如您所見，實際上有可能在瀏覽器中使用Jolokia和JavaScript來實現完整的jconsole端口……也許是下次（有人愿意提供幫助嗎？）。 回到我們的項目，讓我們選擇一些基本指標并將它們顯示在列表中：

該列表本身看起來很有希望。 我沒有顯示圖表或值，而是為每個指標分配了一個圖標（稍后會詳細介紹）。 但是我不想一直瀏覽整個列表。 為什么我不能只有一個匯總多個指標的指標？ 由于我們已經在使用jsTree ，因此轉換相對簡單：

在第一個屏幕截圖中，您可以看到一個健康的系統。 由于總體指標為綠色，因此實際上沒有必要進行深入分析。 但是，第二個屏幕截圖的情況更糟。 系統負載驚人地高，交換空間也需要注意，但重要性不高。 如您所見，前一個指標一直上升到總體最高指標。 通過這種方式，我們可以輕松地發現系統中發生的錯誤。 您可能想知道，當我們一開始只擁有原始JMX數據時，我們是如何獲得這棵漂亮的樹的？ 這里沒有魔術，看看我如何構造樹：

function buildTreeModel(jmx) {return new CompositeNode('Overall', [new CompositeNode('Servlet container', [new Node('Active HTTP sessions',jmx['Catalina:context=/jmx-dashboard,host=localhost,type=Manager'].activeSessions,Node.threshold(200, 300, 500)),new Node('HTTP sessions create rate',jmx['Catalina:context=/jmx-dashboard,host=localhost,type=Manager'].sessionCreateRate,Node.threshold(5, 10, 50)),new Node('Rejected HTTP sessions',jmx['Catalina:context=/jmx-dashboard,host=localhost,type=Manager'].rejectedSessions,Node.threshold(1, 5, 10)),new Node('Busy worker threads count',jmx['Catalina:name="http-bio-8080",type=ThreadPool'].currentThreadsBusy,Node.relativeThreshold(0.85, 0.9, 0.95, jmx['Catalina:name="http-bio-8080",type=ThreadPool'].maxThreads))]),//...new CompositeNode('External systems', [new CompositeNode('Persistence', [new Node('Active database connections',jmx['com.blogspot.nurkiewicz.spring:name=dataSource,type=ManagedBasicDataSource'].NumActive,Node.relativeThreshold(0.75, 0.85, 0.95, jmx['com.blogspot.nurkiewicz.spring:name=dataSource,type=ManagedBasicDataSource'].MaxActive))]),new CompositeNode('JMS messaging broker', [new Node('Waiting in "requests" queue',jmx['org.apache.activemq:BrokerName=localhost,Destination=requests,Type=Queue'].QueueSize,Node.threshold(2, 5, 10)),new Node('Number of consumers',jmx['org.apache.activemq:BrokerName=localhost,Destination=requests,Type=Queue'].ConsumerCount,Node.threshold(0.2, 0.1, 0))])])]);
}

樹模型非常簡單。 根節點可以具有子節點列表。 每個子節點可以是代表單個評估的JMX度量的葉子，也可以是代表孫子集的復合節點。 每個孫子可以依次是葉或另一個復合節點。 是的，這是Composite設計模式的簡單示例！ 但是，使用策略模式并不明顯。 仔細觀察，每個葉節點對象都具有三個屬性：標簽（在屏幕上看到的內容），值（單個JMX度量）和一個奇數函數Node.threshold（200，300，500）…這是什么？ 它實際上是一個更高階的函數（函數返回一個函數），稍后將用于解釋JMX度量。 請記住，原始值是沒有意義的，必須將其解釋并轉換為美觀的圖標指示符。 此實現的工作方式如下：

Node.threshold = function(attention, warning, fatal) {if(attention > warning && warning > fatal) {return function(value) {if(value > attention) { return 1.0; }if(value > warning) { return 0.5; }if(value > fatal) { return 0.0; } else { return -1.0; }}}if(attention < warning && warning < fatal) {return function(value) {if(value < attention) { return 1.0; }if(value < warning) { return 0.5; }if(value < fatal) { return 0.0; } else { return -1.0; }}}throw new Error("All thresholds should either be increasing or decreasing: " + attention + ", " + warning + ", " + fatal);}

現在變得清楚了。 該函數接收級別閾值，并返回將其轉換為-1：1范圍內的數字的函數。 我本可以直接返回圖標，但是我想從GUI表示中抽象樹模型。 如果現在返回活動HTTP會話指標的Node.threshold（200，300，500）示例，那么最終結果很明顯：如果活動HTTP會話數超過200，則顯示注意圖標，而不是“確定”。 如果超過300，則會出現警告 。 出現500以上的致命圖標。 此功能是一種了解輸入并以某種方式處理它的策略 。

當然，這些值/函數僅是示例，但這是真正艱苦工作的體現–對于每個JMX指標，您都必須定義一組理智的閾值。 500個HTTP會話是災難還是我們只能處理的高負載？ 90％的CPU負載是否有問題，或者如果它真的很低，我們應該開始擔心嗎？ 一旦微調了這些級別，就不再需要同時監視所有內容。 只需查看頂級單一指標即可 。 如果是綠色，休息一下。 如果不是，請在幾秒鐘內向下鉆取以找出真正的問題所在。 簡單有效。 我是否提到了它不需要在服務器端進行任何更改（除了添加Jolokia并將其映射到某個URL）？

顯然，這只是一個小的概念驗證，而不是完整的監視解決方案。 但是，如果您有興趣嘗試和改進它，則可以像從我的GitHub 帳戶一樣獲得整個源代碼。

參考：來自JCG合作伙伴的 Jolokia和JMX的客戶端服務器監視 ? Java和社區博客中的Tomasz Nurkiewicz。