ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Monitoring Local and Remote Applications Using JMX 1.2 and JConsole
Pages: 1, 2

Performing Remote Management using JConsole

The JConsole application itself uses up significant system resources, and so using the JConsole locally to the applications being monitored can have an impact on the monitored results. The preferred route for using JConsole is to start it from a remote machine and then, using the JMX remote monitoring facilities, log in to your application and monitor its performance from a safe distance.

As it happens, configuring JMX in order to monitor an application remotely is simple and elegant if security is not a big concern (if you are working in a development environment, for example).

To start the example application with remote monitoring enabled, no security options, and using an arbitrary free port of your choice, you need to add the com.sun.management.jmxremote.port, com.sun.management.jmxremote.authenticate, and com.sun.management.jmxremote.ssl Java system properties to the command line:

> java -Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=8004 \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false \
-classpath %PROJECT_DIRECTORY% com.oreilly.onjava.jmxexample.SimpleApplication

When you now start JConsole from a remote networked machine, you should now be able to connect to the JMX agent in your application by entering the relevant information under the "Connect to Agent" dialog's "Remote" tab, as shown in Figure 11.

Figure 11
Figure 11. Connecting to a remote JMX-enabled application without authentication

At this point, you should only need to specify the Host or IP and the Port to connect to your application. The User Name and Password fields are not required, as you have not yet enabled authentication on your JMX Agent. Once the remote connection to your application's JMX Agent has been established, the title bar of JConsole will show the remote connection's details, as shown in Figure 12.

Figure 12
Figure 12. The remote connection's information displayed in JConsole's title bar

The fact that anyone can effectively manage your application at this point should be making you suitably nervous. The first step in securing the JMX Agent on your application is to add user name and password authentication. In order to enable JMX authentication, you first need to create a password file. A default template of the password file is located at %JRE_HOME%/lib/management/jmxremote.password.template.

Copy the template password file from %JRE_HOME%/lib/management/jmxremote.password.template to a directory that only you can read and write from (especially if you are working in a multiple-user environment). Your home directory is a good candidate location to copy the template password file to, renaming it %MY_HOME_DIRECTORY%/jmxremote.password.

Once you have created your own copy of the password file, amend its contents by un-commenting the two existing users monitorRole and controlRole. The resulting contents of your password file should look like this:

monitorRole   QED
controlRole   R&D

The QED and R&D values are the cleartext passwords for the two roles. Once you have saved your changes, you can enable authentication in your application's JMX Agent when you run your application by setting the com.sun.management.jmxremote.password.file Java system property to your amended jmxremote.password file, and by setting the com.sun.management.jmxremote.authenticate Java system property to true:

> java -Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=8004 \
-Dcom.sun.management.jmxremote.authenticate=true \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.password.file=%MY_HOME_DIRECTORY%/jmxremote.password \
-classpath %PROJECT_DIRECTORY% com.oreilly.onjava.jmxexample.SimpleApplication

Once your application has started, you can connect to the JMX Agent using JConsole by entering the remote monitoring information as before, but this time including one of the user names and passwords from your jmsremote.password file; for example, the "controlRole" user and the "R&D" password shown in Figure 13.

Figure 13
Figure 13. Connecting to a remote JMX-enabled application with authentication enabled

Once the remote connection to your application's JMX Agent has been established, the title bar of JConsole will show the remote connection's details, including the role you with which you connected, as shown in Figure 14.

Figure 14
Figure 14. The remote connection's information, including the user role, displayed in JConsole's title bar

At this point, it is worth changing the passwords that are stored in your copy of the jmxremote.password file. The file contains a set of simple <role> <password> pairs. To change the passwords, simply edit the file and restart your application. For example, to change the password for the "controlRole" to "BANANA", edit your jmxremote.password file so that it contains:

monitorRole   QED
controlRole  BANANA 

Note: You can add new users with different permissions by editing the %JRE_HOME%/lib/management/jmxremote.access file. This is explained in more detail in the documentation on JMX available from Sun; see the References section of this article for details.

You have now effectively applied access authentication to your JMX-enabled application. However, the level of security that you have achieved is probably only acceptable for a development environment, as the passwords are still being exchanged in cleartext form between your application's JMX Agent and clients such as JConsole. Although it is beyond the scope of this article, it is worth considering using the SSL configuration options that are built into JMX in order to secure remote JMX monitoring in any production environments.


This completes the whirlwind tour of JMX and JConsole and how to monitor your own applications locally and remotely. The combination of JMX 1.2 and JConsole in J2SE 5.0 brings Java application management and monitoring to the front line of Java development like never before. There is much more to JMX, including the capability to programmatically create your own clients and your own MBeans, and so it is definitely worth digging a little deeper into what JMX 1.2 has to offer by exploring the references provided with this article.


Russell Miles is a senior consultant for SpringSource in the UK and contributes to various open source projects while working on books for O'Reilly.

Return to ONJava.com.