JMX, SNMP, Java, etc...

Daniel Fuchs blogs on JMX, SNMP, Java, etc...

All | Personal | Sun

tags: blogging firewall hg java jconsole jmx jvm management mbean mercurial monitoring opendmk openjdk opensource rmi snmp ssl
Table Of Contents (list all entries)

« Happy Birthday! | Main | Brian Goetz: Trust... »

Friday February 23, 2007

JVM Monitoring: JMX or SNMP?

Since Java^TM SE 5.0, the JRE provides a means to manage and monitor the Java Virtual Machine. It comes in two flavors: one is based on the Java Management Extension (JMX^TM), the other is a small SNMP agent that builds upon the Management and Monitoring API of the Java SE platform and exposes the same information through SNMP.

A legitimate question that often arises to newcomers to the JMX and SNMP technologies is:

Which technology should I use to monitor my JVM? JMX, or SNMP?

In this blog I will try to provide some guidance on this subject.

Monitoring the JVM through JMX

The JVM JMX agent is composed of a JMX RMI Connector Server which exposes the content of a platform MBeanServer to remote applications. When started, it registers all the platform MXBeans that compose the JVM Monitoring and Management API in the platform MBeanServer, and expose them to remote JMX clients.
One such client is the popular JConsole graphical tool.
Follow this link to learn more about managing and monitoring the JVM through JMX.
Other links of interest can also be found in What is JMX? and Looking for JMX Overview, Examples, and More....

Monitoring the JVM through SNMP

The JVM SNMP Agent is a small SNMPv2c agent which exposes a single MIB, the JVM-MANAGEMENT-MIB. This agent is not extensible, and can only expose what is defined in that MIB.
Follow this link to learn how to start and configure the JVM SNMP agent.

In order to manage the JVM through SNMP, you will need to use an SNMP management console, or an SMMP management API. The Java Dynamic Management Kit from Sun provides an SNMP Manager API in Java. There are also a lot of other free or commercial SNMP tools, shells, and command line software, such as e.g. NET-SNMP.
A good place to start looking for them is here, or you could also ~~google it~~ use your favorite internet search engine.

Update:Dmitri Maximovitch has written an excellent article explaining how to use MRTG to monitor the JVM, either through JMX or through the JVM SNMP Agent.

So, Which Management Solution Should I Choose?

Well, in what Java and the JVM is concerned, I would say it's far more interesting to invest in a solution based on JMX rather than on a solution based on SNMP, for the following reasons:

The MIB that makes it possible to manage the JVM through SNMP is closed. The JVM-MANAGEMENT-MIB only exposes the information defined by JSR 163 - and none other. In particular, if you register your own MBeans in the platform MBeanServer, they will not be exposed through that MIB. On the other hand, you will be able to interact with them through a regular JMX connector, and JConsole will display them nicely.

The JVM SNMP Agent is also closed. As I have already explained, it doesn't have a public API. If you wanted to expose your own information through SNMP you would have to:

Find a standard MIB that defines the information you want to expose, or write your own MIB
Use a tool such as the Java Dynamic Management Kit to generate stubs for that MIB
Provide the application logic to implement those stubs
Start a new SNMP agent to expose your MIB.

All of this does require a certain amount of expertise in SNMP.

The power of expression of SNMP/SMI is limited. It is ideally suited to describe and monitor numeric gauges and counters (scalar or tabular), but describing complex data is much more awkward. Some things which could appear trivial in JMX, like for instance, returning a thread stack trace, can reach incredible levels of complexity in SNMP. Describing complex configuration can also rapidly become nightmarish. The possibility of evolution for SNMP interfaces is thus limited: SNMP is a very good protocol - but like any management technologies, it has its strengths, weaknesses, and limitations.

Conclusion

All in all, I would say that choosing to monitor the JVM through SNMP is legitimate when:

The JVMs you want to manage are deployed in a secure network (intranet-like). The JVM SNMP agent is an SNMP v2c agent, and SNMP v2 has basically no security.
You already have at your disposal SNMP management tools or SNMP management consoles
You already have an SNMP background knowledge, so that you will not have to learn everything about SNMP from scratch
You are trying to correlate JVM Monitoring data through non Java management applications which already have an SNMP stack
You are only interested in JVM data - not application data, and do not see any plans for this to change.
What is defined in the JVM-MANAGEMENT-MIB suits your need and is enough for your purposes.

If that is the case, and you answered YES to all questions, then the JVM SNMP Agent was made for you!

Cheers, and stay tuned for more adventurous journeys in the Java, JMX, and SNMP world!
-- daniel

Tags: java jmx jvm monitoring snmp
Posted by dfuchs ( Feb 23 2007, 04:50:07 PM CET ) Permalink Comments [7]

Trackback URL: http://blogs.sun.com/jmxetc/entry/jmx_vs_snmp

Comments:

Thanks Daniel, your answer was so helpfull.

Posted by Irene Levina on February 23, 2007 at 10:57 PM CET #

Hey Daniel, I'm running JBoss on Server1 and I have OpenNMS running on Server2. I'd like to enable SNMP on the JBoss server and for OpenNMS to be able to poll the JVM that JBoss is running in. No matter how I try to configure it, I get: Failed to start SNMP adaptor with address: xxx.xxx.xxx.xxx:162 (Permission Denied) Is this even possible of is the SNMP stuff limited to working on Localhost only? Cheers James

Posted by James Callaghan on June 21, 2007 at 06:25 PM CEST #

Hi James,

First it's a bad idea to start the Adaptor on port 162, since port 162 is usually used to listen for traps. The standard SNMP port to listen for incoming request is 161.

However, there are good chances that this port is already take by the native SNMP agent of the machine where you run your java application, so it's a better idea to choose some other port.

Finally, under many OS (at least UNIX - for Windows I don't know) you will need super user privileges to open a reserved port number (less than 1024).

I suggest that you try instead with something like -Dcom.sun.management.snmp.port=9161.

Also if you intend to run your SNMP client on a different machine have a look at this: What is the JVM SNMP Agent

Hope this helps,
--daniel

Posted by daniel on June 21, 2007 at 06:54 PM CEST #

Hello, what is the diference whith jvmti?

thank

Posted by Guillermina on January 29, 2008 at 01:15 AM CET #

Hi Guillermina,

JVM TI is a low level interface which provides native hooks in the JVM which will allow you to write tools like debuggers.
http://java.sun.com/javase/6/docs/platform/jvmti/jvmti.html

JMX and SNMP are high level management interfaces which will allow you to (remotely) monitor and manage a running application.

Using JMX you will also be able to write your own management/monitoring interface (= write your own MBeans) and access them from a remote application, either programmatically or through graphical tools like JConsole or VisualVM.
http://blogs.sun.com/jmxetc/entry/what_is_jmx
http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
https://visualvm.dev.java.net/
http://blogs.sun.com/lmalventosa/entry/jconsole_visualvm_milestone1

Hope this makes it clearer,

-- daniel

Posted by daniel on January 29, 2008 at 10:44 AM CET #

Hi,
i want to monitor a java application with snmp by exposing some of its data.
where should i basically start??
how do i write my own MIB for this?? and how to set values for my-own-defined OID's

Do i need to use Java-DMK or OpenDMK for achieving this??

please help

thank you

Posted by raj on November 17, 2008 at 08:39 AM CET #

Hi Raj,

I have answered this question here:
http://blogs.sun.com/jmxetc/entry/what_is_the_jvm_snmp#comment

Hope this helps,

-- daniel

Posted by daniel on November 17, 2008 at 11:01 AM CET #