Tooling up

Advanced Java monitoring with Automon

Coman Hamilton
Programming image via Shutterstock

Unlike most Java monitoring tools, Automon builds on your existing monitoring setup to give more monitoring control. Author Steve Souza explains the idea behind his new open approach to monitoring Java code.

JAXenter: You’ve just released an interesting new open-source approach to monitoring java programs. Can you tell us a bit about it?

Steve Souza, Automon creator: Absolutely, I’d love to. Automon monitors Java applications. It measures method execution time, and counts the specific exceptions that your application throws. Automon is complimentary to the other monitoring tools that developers are already using; in fact, it enhances them. Automon lets you control ‘what’ you want to monitor independently from the tool that you use to monitor (‘how’).

Developers can determine ‘what’ to monitor by changing a few lines in a simple configuration file.  One powerful benefit of this is that developers can defer what should be monitored until runtime.  This allows them to easily monitor different things in development, testing and production.  It also allows them to easily change what they monitor as the application evolves.

Automon is all about openness. That is, Automon doesn’t perform the actual monitoring; rather, it delegates to whatever monitoring tool a developer is already using.  This makes it easy to swap between monitoring tools such as Jamon, Yammer metrics, New Relic, StatsD, JavaSimon or even your own monitoring implementation.  If in the future a new tool comes around, no problem! Implement a simple interface and start using it.

Automon is very lightweight and can also be enabled/disabled at runtime making it perfect for production monitoring.  Finally, Automon is open source and is available at

There’s already a couple of Java tools similar enough to this out there – what is Automon doing differently?

Well, there are definitely some great tools out there. Luckily, you don’t have to choose between Automon and your favourite. Automon is monitoring tool agnostic. Automon leverages the monitoring tools developers already love, plus adds more power, expressiveness and choice.

The Monitoring API’s each have different strengths. For example, Jamon lets you look at the full stacktrace of any exceptions your application throws, and Yammer Metrics has rolling averages. Depending on your needs one of these features may be a deciding factor. Automon lets you easily swap between monitoring tools, based on which one best meets your needs.

Automon makes the leading monitoring APIs more powerful in a few ways.  Unlike the Monitoring API’s Automon doesn’t require you to know in advance what classes and methods you would like to monitor or force you to use proprietary annotations.

There are also other approaches to monitoring code that are unique to the specific monitoring tool being used.  For example, Spring uses the power of AspectJ’s pointcut language to specify what methods to monitor, but you are limited to only being able to monitor Spring beans.  For example, if you would like to monitor constructors, calls to third-party libraries (like Hadoop, Cassandra, ElasticSearch) or even JDK classes such as those in the* or* packages, you are unable to when using Spring.  Automon gives the monitoring APIs the ability to monitor all of these and more by changing a simple declarative XML configuration file.

The following diagram summarises these concepts.

Automon Bridge

Automon Bridge

And you’ve implemented it using AspectJ, right? What does this allow users to do?

I’m a big fan of AspectJ’s implementation of Aspect Oriented Programming (AOP).  Lucky for me, monitoring is the killer application for AOP.  With its simple expressive syntax the AspectJ, pointcut language is a wonder.  Automon uses pointcuts to allow users to specify what methods or classes they would like to monitor.

For example, if you wanted to monitor all public methods in your Rest package you could specify the following pointcut:

execution(public **(..))

That’s it!  Although powerful, this simple example only hints at the full power of AspectJ’s pointcut language for easily specifying ‘what’ parts of the code you would like to monitor.  Automon also has defined many reusable pointcuts that let you easily specify what you would like to monitor by specifying something as simple as ‘jdbc()’, or ‘net()’.  More reusable pointcuts will be added with each release.  For example, I can imagine ‘hadoop()’, or ‘cassandra()’ pointcuts.

Can you tell us a bit about how it works?

Sure.  Let me give you an example.  Here is how you could typically execute a java program:

java -classpath myapp.jar com.mycompany.MyClass

To add Automon monitoring you simply do the following:

  1. Add Automon and your monitoring tool jars to the classpath
  2. Add the AspectJ javaagent
  3. Provide an AspectJ configuration file that specifies ‘what’ code you want to monitor.

Here is what the command line might look like if you use Jamon as the monitoring implementation:

java -Dorg.aspectj.weaver.loadtime.configuration=file:ajc-aop.xml -javaagent:aspectjweaver.jar -classpath myapp.jar:automon-1.0.jar:jamon-2.81.jar com.mycompany.MyClass

Let’s say you just wanted to monitor your Rest API then the  AspectJ configuration file (ajc-aop.xml) might look like this:

  	    <concrete-aspect name=“com.mycompany.aspects.MyMonitoringAspect" extends="org.automon.aspects.AspectJBase">
               <pointcut name="user_monitor" expression="profile()"/>
               <pointcut name="user_exceptions" expression="profile()"/>
               <pointcut name="profile" expression="execution(public **(..)) "/>

In the xml file, you define your aspect to inherit from AspectJBase, and specify what methods to monitor by specifying the ‘user_monitor’ pointcut.  You also specify what code should be monitored for exceptions by specifying the ‘user_exceptions’ pointcut.  In this case I defined a reusable pointcut that they both use called ‘profile()’ that points to the Rest classes.

How you would look at the collected monitoring data depends on which monitoring tool you put in your classpath, but regardless, they will all have the same information in them.  With respect to Jamon, if you look in the Jamon report you would see aggregate statistics such as count, average, total, min, max and more for the called Rest methods.  A representative label might look like this:


In addition, if any exceptions were thrown you would see a label with the exception name and a count of how many times it occurred. The label might look like this:

With Jamon you would also be able to look at the full stacktrace.

Are there any requirements for developers? And what’s the best way to get started?

Dive in and start monitoring!  It just requires the steps I mentioned above and a JDK 1.5 or higher Java application.

The best place way to start is to check out the Automon project, read the README files and run the programs in the ‘examples’ directory.

The example I mentioned above uses AspectJ’s Load-time weaving (LTW) capabilities.  With Load-time weaving AspectJ adds the monitoring information to your classes at runtime when they are loaded. You can also use Build-time weaving (BTW) which puts monitoring into your classes when they are compiled.  Build-time weaving can either be done with the AspectJ compiler or via a Maven pom file.  The examples directory has examples of LTW, and BTW. There are also a few examples that use Maven.

For a great introduction to the AspectJ pointcut language, I recommend ‘AspectJ in Action’ by Ramnivas Laddad.

What are your plans for future releases?

First I would like to develop a community and get contributions and feedback.  There are many diverse needs that developers have, and I would love to get these ideas into the Automon codebase. Developers can easily enable their tool to gain the benefits of being called by Automon by implementing the simple OpenMon interface.

For the next release I would like to incorporate a couple other monitoring tools like New Relic, Perf4j, and StatsD.

Currently Automon only times method calls and a few other pointcut types and does not incorporate any dynamic data into the monitoring label. Incorporating data into a label is important when measuring the performance of SQL statements (using SQL string and argument values) and page requests (page name) for example. Each monitoring API has had to solve this problem independently, I would like to see Automon take on this duty and let the monitoring APIs focus on what they are best at – tracking the statistics.

My ultimate goal is to see monitoring APIs become a first class citizen in Java, much like logging already is.  All of the monitoring tools and API’s have definitely given us a great start. Wouldn’t it be great to see the best ideas, terms and concepts from them get rolled back into the JDK?

Coman Hamilton
Coman was Editor of at S&S Media Group. He has a master's degree in cultural studies and has written and edited content for numerous news, tech and culture websites and magazines, as well as several ad agencies.

comments powered by Disqus