It’s no mystery, estimating a software development project is difficult. Many focus on time spent coding and testing the application but fail to account for the issues that normally arrive towards the end of a project’s lifecycle. Performance testing, maintenance, and other feature additions can easily turn into sleepless nights and an over-schedule/over-budget project, but they don’t have to.
Monitoring is an essential exercise for keeping your application healthy.
The ability to identify issue-prone areas in your application, early in the project’s timeline, can help minimize hiccups and headaches and improve your chances for a stress-free deliverable.
Beyond that, there are a few more reasons to consider continuous monitoring...
Monitoring can be achieved using JMX-based solutions like Metrics or Server. For low-level JVM based monitoring, there are standard JDK tools like jconsole, jstat, jmap, jstack or hprof. For full-fledged monitoring solutions, which can be incorporated during the development phase of the project, use a tool like JavaMelody or Lambda Probe.
JavaMelody is an open source (LGPL) application used to monitor Java or Java EE application servers. It measures and calculates statistical information based on application usage. The resulting data can be viewed in a variety of formats including evolution charts, which track various operations and server attributes over time. There are also robust reporting options that allow data to be exported in either HTML of PDF formats. Time is always scarce in development, so it’s useful to work with a tool like JavaMelody which has low overhead, is non-intrusive, and provides useful information.
Installation is fairly simple and can be done in just a few minutes. You can download the distribution from JavaMelody Wiki and extract the javamelody.jar. Alternatively, if you’re using Maven with a Spring-based framework, it’s best to follow the maven repository configuration instructions.
JavaMelody requires a monitoring filter before the web app’s servlet in WEB-INF/web.xml.
You can exclude data from certain urls by using the url-exclude-pattern regular expression. Additionally, email-parameters can be used for configuring weekly reports and by including the monitoring-spring.xml file, you can monitor data sources with a Spring post-processor.
If you are required to restrict access to monitoring statistics, the following configuration needs to be added in Spring Security’s applicationContext-security.xml. Ensure that the monitoring filter in web.xml (above) is defined after the Spring Security filter chain.
If you also want to see EHCache statistics, add statistics=”true” to the ehcache.xml config file.
For monitoring data sources and SQL, add a JNDI-lookup to applicationContext-persist.xml
As described in the User guide for monitoring Spring Business facades, there are a few of options available for monitoring objects controlled by frameworks like Spring and EJB.
Option 1. JdkRegexpMethodPointcut
With JdkRegexpMethodPointcut in applicationContext-web.xml you can catch objects with a regular expression that matches all objects that have “Service” in their name.
Option 2. Use of an annotation of JavaMelody. This is the most convenient and adaptable option. Just add the annotation @net.bull.javamelody.MonitoredWithSpring to all implementation classes and/or interfaces and/or methods of interfaces which you want to monitor, without modification of your applicationContext.xml file.
Option 3. Use of MonitoredWithInterfacePointcut Assuming all business facades have a common interface (or superclass), for example “com.xyz.Facade”, add the following code snippet to applicationContext-web.xml to monitor all the related facade methods.
All the statistics can be viewed in HTML, by navigating to the following URL:
The url can be customized in the configuration file. Reports can be viewed in weekly, daily or monthly formats. They can also be downloaded or can be sent by email in pdf format. iText library for WebApps and Java’s Mail and Activation library is required on the server in order to use the mail session. The report provides the same information you can find on monitoring web page with both high-level and detailed information. JavaMelody statistics from development:
Features come with a cost, and JavaMelody is no exception. On the JavaMelody Wiki, you can find a healthy discussion about system overhead. It seems that the general consensus is that the overhead cost caused by JavaMelody is very low and that the feature is safe to enable full-time in a QA environment. If no problem arises, you might consider enabling JavaMelody in your production environment as well. Using a tool like JavaMelody can lead to valuable insights on how to optimize servers or uncover otherwise hidden issues, providing value that exceeds the overhead cost.
As an FYI, here are a few more details about how JavaMelody handles data:
“Measurement is the first step that leads to control and eventually to improvement. If you can’t measure something, you can’t understand it. If you can’t understand it, you can’t control it. If you can’t control it, you can’t improve it.” - H. James Harrington
Improvement requires constant feedback. Leveraging a tool like JavaMelody can provide valuable data about your applications performance with minimal overhead.