Grails alerts with jAlarms & Opsview

This post is going to explore how we can raise application alarms from Grails applications into an enterprise monitoring solution such as Opsview. These are known as Passive checks, as opposed to Active checks where Opsview is actively polling to check the state of a service.

Let’s start off by describing the main building blocks that we’ll be using (from source to sink):

1. Grails – a modern agile Open Source web framework with a rich plugin ecosystem that uses Groovy, the Spring Framework, Spring MVC and Hibernate.
2. JAlarms – an Open Source framework for allowing Java developers to raise alerts from server applications (also available as a Grails plugin)
3. JSend NSCA – an Open Source Java API that shields us from the underlying NSCA data format – described here
4. NSCA daemon – the Nagios Service Check Acceptor, which allows applications to submit service check results to Nagios
5. Opsview – an Open Source enterprise monitoring solution built on top of Nagios.

This post assumes you already have Opsview set up, with a host & service check defined and that the service check can accept passive check results.
If not – see the Opsview quick start guide.

Opsview configuration
We’ll start by ensuring that Opsview is configured so that it will accept remote NSCA service checks (I strongly suggest you use firewall rules to restrict access) and the encryption method is compatible with JSend NSCA (as it currently only supports NONE, XOR and TRIPLE_DES; Opsview supports about 20 algorithms with DES as the default).

1. Edit /usr/local/nagios/bin/ (as this script recreates the nsca.cfg when Opsview reloads configuration). The following diff shows the changes between the new file and the original file (diff

< #server_address=
< server_address=
> server_address=
< decryption_method=3
> decryption_method=2
< encryption_method=3
> encryption_method=2

If you make Opsview reload the config – you’ll then see the new values in /usr/local/nagios/etc/nsca.cfg

2. Restart opsview (as we’re binding differently):
/etc/init.d/opsview restart

JAlarms 1.5.2 features the addition of the NagiosPassiveCheckChannel contribution ( that I developed to integrate JAlarms with Opsview using JSend NSCA. Note that the channel was downgraded from JSend NSCA 2.0.1 (as used in the Github code) to 1.3.1_2 so that the dependency could be sourced from the Maven central repository.

NagiosPassiveCheckChannel requires the following settings:

  • settings – JSend NSCA NagiosSettings class
  • hostname – this must match the hostname as configured in Opsview
  • sources – a map of JAlarms source names to Opsview service check names (to allow for multiple jAlarms channels).

Setting up Grails jAlarms for Opsview
Using the recently launched JAlarms plugin (courtesy of Hackergarten Mexico and Andres Almiray) – at the time of writing we’ll need to upgrade the version of jalarms from 1.5.1 to 1.5.2 and declare the JSend NSCA dependency.

1. “grails install-plugin jalarms
2. Upgrade the jar to 1.5.2 (I built it from source)
3. Add the dependencies in grails-app/conf/BuildConfig.groovy:
Uncomment the repository:


Add the following dependencies:

compile 'org.apache.servicemix.bundles:org.apache.servicemix.bundles.jsendnsca-core:1.3.1_2'
runtime 'org.apache.servicemix.bundles:org.apache.servicemix.bundles.jsendnsca-core:1.3.1_2'

4. Set up the Spring beans & configuration
For speed, I’ve included the configuration in grails-app/conf/spring/resources.groovy (ideally these would be per-environment in Config.groovy):

import com.solab.alarms.channels.*
import com.googlecode.jsendnsca.core.*

beans = {
  nagiosSettings(NagiosSettings) {
    nagiosHost = ''
    password = 'changeme'
    encryptionMethod = NagiosSettings.TRIPLE_DES_ENCRYPTION

  channel(NagiosPassiveCheckChannel) {
    settings = ref(nagiosSettings)
    hostname = ''
    sources = [Test:'Alfresco Share connection']

Adding an alarm call
The jAlarms Grails plugin injects a sendAlarm method into controllers & services.
For ease of demonstration we’ll create a controller that always sends an alarm message:

def index = {
  sendAlarm('Test application alert', 'Test') // msg, source
  flash.message = "Alarm sent"

Combined with a simple GSP and we get:

If we look in Opsview, we see that the passive check has resulted in a critical state:

Hopefully that’s given you enough information to get started!


2 responses to “Grails alerts with jAlarms & Opsview

  1. Pingback: Blog bookmarks 02/03/2011 « My Diigo bookmarks

  2. Pingback: Monitoring Grails Apps part 2 – data collection | Lean Java Engineering

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s