The Java Management Extensions (JMX) technology is a standard part of the Java Platform. With JMX developers can expose and manage their application via any JMX enabled console (Examples of these consoles are jconsole and visualvm).
As of release 2.80 JAMon allows all monitors to be viewed via a JMX console. Some monitors are automatically displayed in the JMX console (for example Garbage Collection metrics), and others would need to be explicitly included (Note: All JAMon data is also viewable via the JAMon war).
A summary of JAMon JMX capabilities follows. There is also a short video that covers most of JAMon's JMX capabilities.
The following image shows the above mentioned JAMon JMX capabilities.
The above image is an example of the JAMon JMX Log4j data. It shows that each of the log levels were called 4000 times except TRACE, which wasn't called at all. The JAMon log4j appender must be enabled for this data to appear.
This section represents any page hits (jsp, servlet, html, etc) in a web application.
The example below shows how the frequency of returned http status codes from the web server.
This section represents any SQL commands executed by the application.
This section represents any Exceptions thrown by the application.
This section represents information associated with garbage collection invocations.
The JMX console also displays aggregate statistics (duration in ms.) for each type of Garbage Colleciton that has occurred (i.e. Scavenge, MarkSweep/Full). An example for 'Scavenge' appears below.
Of course you can also see this informat in the JAMon web application. The following shows that a MarkSweep collector was invoked 6 times and the Scavenge collector was invoked 8 times.
In addition to the aggregates mentioned above, JAMon also tracks the details of each individual GC invocation via JAMon's buffer listener capabilities. Listeners can be configured in the jamonapi.properties file. To configure and view the detailed GC invocation data click on the blue box underneath the 'Modify' column (see above).
Each row in the table below represents details collected for one GC invocation. Some of the data collected is: The duration of the GC invocation (in ms.), memory statistics both before and after the GC invocation (BeforeGc, and AfterGc respectively).
In addition to tracking the frequency and duration of the GC invocations JAMon JMX also tracks the memory consumed (in bytes) by Java different memory pools after the GC was fired (AfterGc). Note all GC related data shows up in the JAMon display screen if you filter by 'gc'. A snapshot of this data is in the image below.
Developers can use JAMon's custom JMX metrics capabilities to add any JAMon monitor to JMX. In fact that is exactly how the JMX entries we have discussed that start with 'Jamon.' were added. For example 'Jamon.PageRequests.Jetty' was added this way. To add your own custom JMX monitors simply add them to the jamonapi.properties file. Below you can see how many of the custom metrics discussed in this document are configured. Note each custom metric has to have the exact JAMon monitor label and units (comma delimited). Optionally if you would like the JMX label to appear with a different (more readable) name in JMX then this can also be provided. By convention the name should start with 'Jamon.'.
Note if you provide one custom JAMon JMX monitor then you are taking ownership of ALL custom monitors. This means that if you would like any of the other 'Jamon.' custom JMX metrics discussed above to still appear they must also be in the jamonapi.properties file.
The 'Jamon' JMX bean allows developers to enable/disable JAMon, view the JAMon version and reset JAMon data via the 'reset' Operation.
Normally JAMon numbers continually grow. The 'Delta' capability allows a developer to determine how much the JAMon metrics have changed since the last time they were checked. All 'Delta' JMX beans reside within the 'deltas' jmx directory structure as seen below.
For example the 'refresh' button was clicked on the Log4j Delta JMX bean below and it indicates that most log methods were called 2,000 times since the Delta 'refresh' button was last clicked. If the 'refresh' button was clicked again and no log methods had been called in between refreshes then all the numbers would be 0.
The following shows changes in jetty page hits since the 'refresh' button was last clicked. So 3 page hits occurred during this time interval, and their average time per invocation was 102 ms.