Aug 30, 2016

Monitoring Grails Applications The Easy Way

Grails allows you to create RESTful APIs or Web applications much more quickly than other JVM frameworks. You may be surprised to know, though, that Grails also provides a number of handy features to help you monitor the health and performance of your applications.

Some of the these features you get for free while others require a bit of work on your part. This post should give you a taste of what you can do with very little work on your part.

When you want to start monitoring your Grails applications, the first place to start should be the Spring Boot production-ready actuators. Despite the odd terminology, these actuators provide a lot of handy features right out of the box. Actuators provide data on your running application through JSON endpoints.

Some of the actuator endpoints can help with diagnosing configuration issues, such as /autoconfig, /configprops, and /env. These aren’t related to monitoring your applications but they can help if you are having issues, especially with Spring configuration.

The /configprops endpoint lists all the Spring configuration properties but doesn’t include all the Grails-specific properties. The /env endpoint provides more information including Grails configuration settings. I’ve used these actuators to help debug Spring Security configuration issues.

In addition, the /info endpoint provides some basic information on your application, such as the Grails version number and your application’s version number. You can extend the information presented by writing Spring beans that implement the InfoContributor interface.

The endpoints most useful for monitoring include /health and /metrics.

Checking Application Health

The /health endpoint is designed to tell you whether your application is healthy or not. By default, it just tells you whether the application is up or not, along with information on disk space.

You can see this in action by creating a new Grails application and running it.

Create the application (using Grails 3.1.9):

grails create-app monitor --profile=web

Then, you need to edit the grails-app/conf/application.yml file, since the endpoints are disabled by default. Change the enabled setting to true for the endpoints:

# Spring Actuator Endpoints are Disabled by Default
    enabled: true
        enabled: true

Now, run the application:

grails run-app

Go to the /health endpoint, by default mapped to /health in your application, http://localhost:8080/health.

You will see output like the following:

    "diskSpace": {

Typically though, you’d want a health check to tell you if a back-end service connection is working, or report on other possible conditions with your application. You can do this by defining beans that implement the HealthIndicator interface. Spring Boot comes with some handy built in indicators, including checks for disk space, and connectivity to systems such as Cassandra, MongoDB, SOLR, and Rabbit MQ, as well as a configured Grails DataSource.

You can write your own as well, for example to report the health of a back-end accounting system, you can use the following as a guide:

package com.opi.monitor


 * Checks back-end accounting system's health.
class AccountingHealthMonitor implements HealthIndicator {
    Health health() {
        if (isHealthy()) {
             return Health.up().build()
        return Health.down().withDetail("Accounting System Status", "Unreachable").build();

     * In real life this method would check the health of the back-end system.
     * @return
    boolean isHealthy() {

Define this class as a Spring bean in your grails-app/conf/spring/resources.groovy:

import com.opi.monitor.AccountingHealthMonitor

beans = {

Since this example fakes a down status, you will now see a /health endpoint response that looks something like the following:

        "Accounting System Status":"Unreachable"

Notice how since one health indicator shows a DOWN status, the overall application status is DOWN.

Viewing Application Metrics

The /metrics endpoint contains a lot of data about how your application is running, including information on memory, processors, threads and so on, along with DataSource and Tomcat session metrics. Spring Boot by default uses the concepts of gauges and counters. A gauge holds a value and a counter shows a change up or down over time.

You can view the metrics with the /metrics endpoint. Here’s an example for a simple Grails Web application with one domain class:


You can extend the available metrics by implementing the PublicMetrics interface, as documented at

Instead of writing PublicMetrics classes, though, many prefer to use a add-on library called Dropwizard Metrics.

Dropwizard Metrics

The Dropwizard Metrics library provides a fairly detailed library to allow your application to capture metrics.

Dropwizard uses a bit different terminology than Spring Boot though. In Dropwizard, a meter holds the rate of events over time. A timer provides a histogram of an event type along with a meter of the rate.

The best feature though, is that Spring Boot’s metrics automatically works with the Dropwizard Metrics library. Spring Boot registers all its metrics with the Dropwizard MetricRegistry. The interaction goes both ways, too. Metrics you add to a MetricRegistry using Dropwizard will also appear in the /metrics endpoint.

You can find more information on this library at

To use the Dropwizard Metrics library, you’ll want to install the handy Grails plugin.

Installing Dropwizard Metrics

Unfortunately, you won’t likely find information on the Grails 3 plugin portal at Instead, as is common with so many Grails 3 plugins in a snapshot state, look on github at:

Documentation is at

To install, add the following dependency to your build.gradle file:

compile "org.grails.plugins:dropwizard-metrics:1.0.0.BUILD-SNAPSHOT"

Using the Dropwizard Metrics Library

Once installed, you can use the library itself to record metrics in as detailed a format as you’d like. Since this post concentrates on using out-of-the-box features, you should look at the handy annotations.

The @Metered annotation records an event into a named meter. Similarly, the @Timed annotation starts a timer every time the method is called.

For meters, you can use the following example service as a guide:

import grails.plugin.dropwizard.metrics.meters.Metered
import grails.transaction.Transactional

class UsageService {

    def triggerUsage() {
        // This method would access some service

Every call to the triggerUsage() method will record an event to the accounting meter.

For timers, here is an example of a slow service that performs a lot of time-consuming work:

import grails.plugin.dropwizard.metrics.timers.Timed
import grails.transaction.Transactional

class SlowService {

    def performWork() {
        // Simulate slowness

Your services will have real code, obviously.

Using these annotations, you can see the current values with the /metrics endpoint (showing just part of the new output):



As you can see, you get a lot of data from just using annotations. You can also, of course, make more use of the library to extract even more data.

Using the Actuator UI Plugin

The Spring Boot actuator endpoints all respond with data in JSON format. You can get a nicer look on top of this data by using the actuator-ui plugin.

To install the actuator-ui plugin, add the following to your dependencies in your build.gradle file.

compile 'org.grails.plugins:actuator-ui:0.2'

Note: Version 1.0 of the actuator-ui plugin was just released to support Grails 3.1.

Once installed, you can view the data in a more friendly format at /actuator/dashboard.

You can see a demo of this feature in a YouTube video at

Note that due to the sensitivity of the data, you want to secure the actuator user interface for administrators. The documentation at provides guidance on how to do this with Spring Security.

In addition to securing the actuator-ui, you also should secure the entire set of actuator endpoints.

Securing Actuator Endpoints

Allowing this information to get out in production can be a security issue. You can use the Spring Security Grails plugin to lock down these end points. Endpoints marked as sensitive in your configuration should get automatically protected by Spring Security. Be sure to read the documentation at to see what options are available to you.

Spring Boot allows a lot of customization. You can map these endpoint URLs to something different if you’d like. In addition, you can access the data via JMX if you’d prefer.

All of this shows a taste of the information you can extract from your Grails applications with minimal work. Yet another reason to use Grails.

About the Author

Eric Foster-Johnson profile.

Eric Foster-Johnson

Principal Technologist

Eric has decades of industry experience in designing and developing complex enterprise software, including designing and developing Grails and Java EE solutions to tough client problems. He has experience leading development teams, mentoring developers, and helping troublesome projects get back onto a success track. He has lead teams in both traditional and agile settings.

One thought on “Monitoring Grails Applications The Easy Way

  1. Mike Miller says:

    Looks great!

Leave a Reply

Your email address will not be published.

Related Blog Posts
Natively Compiled Java on Google App Engine
Google App Engine is a platform-as-a-service product that is marketed as a way to get your applications into the cloud without necessarily knowing all of the infrastructure bits and pieces to do so. Google App […]
Building Better Data Visualization Experiences: Part 2 of 2
If you don't have a Ph.D. in data science, the raw data might be difficult to comprehend. This is where data visualization comes in.
Unleashing Feature Flags onto Kafka Consumers
Feature flags are a tool to strategically enable or disable functionality at runtime. They are often used to drive different user experiences but can also be useful in real-time data systems. In this post, we’ll […]
A security model for developers
Software security is more important than ever, but developing secure applications is more confusing than ever. TLS, mTLS, RBAC, SAML, OAUTH, OWASP, GDPR, SASL, RSA, JWT, cookie, attack vector, DDoS, firewall, VPN, security groups, exploit, […]