AWS Developer Blog

Taste of JMX Using the AWS SDK for Java

As you may know, starting from Java 5, the JMX technology is available out-of-the-box to monitor and manage the Java VM.  It seems natural to wonder what it would be like to configure and modify the behavior of the AWS Java SDK via JMX in real time.  Imagine, for example, every configuration option related to enabling SDK metrics can also be done via JMX.  The only difference is configuration via system properties is a one-off and static business, whereas configuration via JMX is dynamic, and can be done anytime on-the-fly in real time while the JVM is running!  Since version 1.6.7 of the AWS SDK for Java, you can do exactly that.

Why the need for JMX ?

Here are two use cases I can think of.

  1. You are trying to troubleshoot intermittent latency issues with a running JVM accessing AWS, but didn’t have metrics configured when the JVM was originally started.  Even though you could conceivably shut down, configure the necessary system properties, and then restart the JVM to enable automatic metric generation, you don’t have to!  Via JMX, you can dynamically turn on automatic metric generation and have the metrics uploaded to Amazon CloudWatch for as long as you want, and then have generation turned off afterwards if you desired.  (See sample JConsole screen shots below.)
  2. You are not entirely decided on whether you want to permanently enable metrics, or what the optimal metric configuration would be (for example, per-host-level metrics vs. per-JVM-level metrics).   Via JMX, you can experiment and play around with different options to see what is best for your applications.  Based on actual observation with different options, you can then decide on the best metric configuration and configure the metrics via system properties for long-term use.

To me, it’s simply fun and powerful to be able to manage and administer a fleet of JVMs dynamically on-the-fly, and especially so when remote scripting is involved.  JMX is an enabling technology, and what can be done with the power it offers is only limited by our imagination. 

Example: Metric Configuration via JConsole

Here are the steps to navigate to the Metric Administration MBean via JConsole:

  1. Fire up jconsole.
  2. Connect to a running JVM that accesses AWS via the AWS SDK for Java.
  3. Click the MBeans tab, and expand the name space

         com.amazonaws.management
  4. Click AwsSdkMetrics.
  5. Click Attributes.

Assuming you have no system properties configured for your JVM, you should see all the default values.  Something like:

jmx-attributes

Now, you can modify almost all the attribute values simply by clicking on the value fields. You then change the values directly in-place and press the Enter key.  Almost all changed values will take effect immediately (i.e. without the need to disable/re-enable metric generation).   The only exception is the value of CredentialFile which gets lazily applied as explained below. Here is a sample screenshot of what it looked like after I changed the Region value to "us-west-2", CredentialFile value to "/Users/hchar/.aws/awsTestAccount.properties" and JvmMetricName value to "MyJVM", but before enabling automatic metric generation:

jmx-disabled

To enable automatic metric generation, click Operations to find the enableDefaultMetrics button:

operations

Click the enableDefaultMetrics button to enable automatic metric generation and uploads to Amazon CloudWatch.  Once metric generation is enabled, you should see the values reflected on the Attributes tab:

jmx-enabled

What are the Limitations?

Compared to what you can do with system properties for metric configuration, there are absolutely no limitations!  In other words, for all the one-off metric configuration options that you can make using system properties, such as those described in the Metric Configuration blog, you can achieve the same effect using JMX, but dynamically in real time and as often as you want!

However, if you happened to modify the CredentialFile attribute value, which is the credential file used for uploading metrics to Amazon CloudWatch, you would need to disable and then re-enable the metrics (via invoking the disableMetrics and the enableDefaultMetrics operations) before the credentials would become effective.  This allows the underlying service client to re-initialize itself with the proper credentials.  In JConsole, you can do so by simply clicking the respective buttons on the MBean’s Operations tab.

Finally, have fun using JMX with the AWS SDK for Java, and Merry Christmas!