What do you monitor with JMX in your production Java application?

This question is not about how JMX works or what JMX does. This question is about applications of JMX in a standard application server environment in production. It is not for specific server either.

What do you monitor with JMX in production environment that runs standard stack of Java EE services: database access (JDBC and JPA), session EJBs, JMS, web server, web services, AJAX-enabled se开发者_Go百科rvices?

At the JVM level, I monitor the garbage collection duration per minute,

At the Servlet Container level, I monitor the number of requests, number of exceptions (4xx & 5xx codes) , sum of request duration per minute,

At the SOAP level, I monitor the number of invocations, number of exceptions & sum of invocations per operation and per minute,

At the Web MVC Framework level, I monitor the number of invocations, number of exceptions & sum of invocations per action and per minute,

For the pools (datasource,thread pool / executor service), I monitor the active count,

For the JMS connections, I monitor the number of sent & received messages per minute, and the number of active receivers,

For EhCache, I monitor the number of entries in the cache, the number of hits & miss per minute,

At the business application level, I developped an @Profiled annotation to monitor the number of invocations, number of exceptions and total duration per minute.

If you are interested in such kind of metrics, we developed many JMX extras (dbcp, util.concurrent, jms, @profiled annotation) and packaged all this with Spring XML namespace based configuration, Hyperic HQ plugins, monitoring jsp pages, etc

The details are here : http://code.google.com/p/xebia-france/wiki/XebiaManagementExtras .

All this code is licensed under the business friendly Open Source Apache Software License 2, deployed on Maven Central Repository, downloadable as a jar and available on a Google Code Subversion server to be integrated the way you want.

Hope this helps,

Cyrille (Xebia)

I've used JMX to expose an MBean that will allow the adjusting of the Log4J Logger levels dynamically. This proved to be very useful for a clustered application where we did not want to have to modify the log4j configuration file on all nodes to change the log level for a specified logger.

My most common requirement is monitoring thread counts and memory. My most recent work involved heavily-threaded servers dispatching to grids, and it was important to monitor thread usage (a measure of how much dispatch work the server was undertaking). Memory is closely tied to the thread usage (partly because of the objects associated with each thread, partly because of the implicit stack allocation per thread).

We JMX-enabled our workload queue data as well. The above monitored symptoms or effects of queuing work items, but ultimately we wanted to monitor the actual queues of work. It's worthwhile to expose key components via JMX to get a clearer perspective on what's going on.

On a previous project, we monitored thread counts and memory, number of HTTP sessions and size of query caches. The other interest of JMX with caches is that you can force a flush.

A little OT but you can use JMX for quite a bit more. Currently I am using JMX to hot deploy / hot fix components. Dynamically add functionality to existing components (filter, etc.). JMX is good for communication between components on the same JVM. Every component I create is instrumented to use JMX.