JavaMelody – monitoring made easy

A properly monitored application can make life much easier, especially if something goes wrong in the production environment. Without the ability to see measurements related to resource utilization (like heap space, CPU usage, disk space, active threads, GC pauses, HTTP requests, and so on) it is pretty challenging to understand how the application behaves. Companies usually provide access to monitoring tools for developers. “Usually” does not mean “always”. The quality of data from those tools also differs. It may also happen that the access to the corporate dashboard expires for you… in the worst possible moment 🙂 How to prevent your app and ensure you get all the numbers you need? How to get all required statistics as soon as possible, even from day one of the project? For Java projects, use JavaMelody. The configuration is dead simple and the results are fantastic.

JavaMelody in a nutshell

JavaMelody has been available to use for a pretty long time, however, I have not seen it used in many projects so far. As stated in the GitHub repo:

The goal of JavaMelody is to monitor Java or Java EE applications in QA and production environments.

There are various ways you can configure the tool for your application. JavaMelody comes also with the Spring Boot Starter – if your app runs on Spring Boot, the configuration should not take more than a couple of minutes. Just add the dependency (below for Maven) with a few properties:

<dependency>
	<groupId>net.bull.javamelody</groupId>
	<artifactId>javamelody-spring-boot-starter</artifactId>
	<version>1.91.0</version>
</dependency>

javamelody:
  # Enable JavaMelody auto-configuration (optional, default: true)
  enabled: true
  # Data source names to exclude from monitoring (optional, comma-separated)
  excluded-datasources: secretSource,topSecretSource
  # Enable monitoring of Spring services and controllers (optional, default: true)
  spring-monitoring-enabled: true
  # Initialization parameters for JavaMelody (optional)
  # See: https://github.com/javamelody/javamelody/wiki/UserGuide#6-optional-parameters
  init-parameters:
    # log http requests:
    log: true
    # to exclude images, css, fonts and js urls from the monitoring:
    #url-exclude-pattern: (/webjars/.*|/css/.*|/images/.*|/fonts/.*|/js/.*)
    # to aggregate digits in http requests:
    #http-transform-pattern: \d+
    # to add basic auth:
    #authorized-users: admin:pwd
    # to change the default storage directory:
    #storage-directory: /tmp/javamelody
    # to change the default "/monitoring" path:
    #monitoring-path: /admin/performance

Done! Once you start the app, it shall be monitored by JavaMelody, and the output accessible under the /monitoring endpoint.

JavaMelody provides not only charts of resource utilization. It is possible to invoke the GC, make a heap dump, see JNDI properties, terminate active sessions, and so on. Therefore, it would be wise to protect the monitoring endpoint from unauthorized access.

Monitoring

In the GitHub Wiki of the project, there are a bunch of screenshots that illustrate how reports look like. I have attached a few examples from that page, but JavaMelody offers much more. For example, it is possible to see the statistics of the HTTP request, check what Controller was responsible for a particular request, and even analyze the performance of the related SQL queries. With those numbers (higher ones are highlighted in red), it is trivial to understand where are the potential bottlenecks or at least places that could be optimized. Fantastic!

JavaMelody exposes also an external API, therefore it is possible to get the above statistics in a different format, like JSON or XML. Last but not least, JavaMelody can generate a PDF report.

Is it safe to use?

I have used JavaMelody in a few projects and have not observed any issues. Of course, as with every tool like that, it is good to perform regression testing to ensure nothing is broken afterward. For example, in SpringBoot, JavaMelody does its own autoconfiguration which may break existing configuration in some cases. I have seen once an issue with a FlyWay DataSource or Spring Boot tests failing. In case of the Spring Boot tests, turning off the JavaMelody autoconfiguration did the trick:

spring.autoconfigure.exclude=net.bull.javamelody.JavaMelodyAutoConfiguration

Is it worth it?

JavaMelody offers a detailed insight into your application in a very digestible format with minimal configuration effort. I regret that I was not aware of this tool much earlier in my career. With JavaMelody it is so much easier to understand how the application behaves, where are the bottlenecks, and where to look if something goes wrong. I deliberately have not written more about this tool as it is best to see it in action. If you have not used that before, definitely try JavaMelody. It can make your life easier, especially if it comes to optimization and production incidents. Have fun!