Posterous theme by Cory Watilo

Filed under: howto

Monitoring a Grails app using Splunk

Grails + Splunk = happy

Splunk is a popular, enterprise-grade tool for IT infrastructure monitoring. If you haven’t come across it before, I’d take 5 minutes to check out this introductory video. In a nutshell, Splunk indexes any form of time-series data, and provides an interface for searching, analysing and reporting on these data.

The enterprise version of Splunk can be used to provide real-time info on all aspects of the operation of entire data clusters, and as you can imagine it has an enterprise-sized price tag to match. However, the good news is that there’s also a version which is free to use if you’re indexing less than 500MB of data a day and don’t require some of the advanced functions such as real-time alerts. This makes Splunk a great tool for small shops and early-stage startups to use for web-app monitoring and performance analysis.

Splunk can consume pretty much any logs your server can produce: syslog, database, Apache, mail, log4j, top – you name it, if it’s a plain-text time-stamped log file, Splunk will index it. However, in this introductory post, I’m going to keep things simple and describe how to get Splunk up and running to provide real-time monitoring of the log4j logs produced by a Grails application.

Splunk is fairly lightweight, so can usually be run on the same server as your Grails app. However, I’m going to take a slightly different approach and run Splunk on my development machine, to avoid having to install any new software on my app server.

First thing is to download and install Splunk. Head over to this page, and choose the appropriate distribution for your machine. Installation is painless and only takes 5 minutes, but if you run into trouble, check out the help pages on the Splunk site. That’s another great thing about Splunk: the documentation is really, really good. Extremely comprehensive and well-written. They even run a Q&A forum using the StackOverflow API.

Once you’re installed, start up Splunk by running

/opt/splunk/bin/splunk start --accept-license

(on Ubuntu/Debian – your system may differ). Load up the web front-end by going to http://localhost:8000/, and log in as admin (password “changeme”).

Okay, now Splunk is up and running we need some data to feed it. The simplest way is to point Splunk at a log file and tell it to tail it. If you’re running Splunk on the same machine as you’re app, this is simple. If not, we need to do an extra step to get the log file onto our development machine. I decided to go with tried-and-trusted cron and rsync:

* * * * * rsync -e ssh -avlq {remote-user}@{remote-host}:{absolute-path-to-remote-log-file} {absolute-path-to-local-log-file} >/dev/null 2>&1

(replace text in curly brackets as appropriate). Thus my application log will be sync’d to my development machine every minute. Remember, this method will only work if you have your development machine registered as an allowed host on your production server.

Now, go to http://localhost:8000/manager/search/data/inputs/monitor and click ‘New’ to add your log file as a new input. Here are the options you want:

  • Source: {absolute-path-to-local-log-file}
  • Host: {remote-host} // but fine to leave as the default
  • Source type: Automatic // Splunk will auto-detect the log4j format
  • Index: default
  • Advanced options: Follow tail: checked

Click ‘Save’, and Splunk will now begin to index the log file, and monitor it for changes.

Now that the set-up is complete, the fun begins. Head over to http://localhost:8000/app/search/dashboard – this is where you can get a visualization of the contents of your log file, filter the contents, search for events, and build reports. The guys at Splunk do a better job of demonstrating these features than I could, so at this point I’ll direct you to one of the many demo videos on the Splunk site. Alternatively, check out the search tutorial in the docs.

Hopefully I’ve showed you how easy it is to set up Splunk and get it analysing the logs of your running Grails app – without having to make a single change to your production server!

Deploying a Grails app to RackSpace Cloud Servers

Judging from the number of blog articles on the subject, Amazon's EC2 seems to be a pretty popular way of deploying Grails applications. Certainly, the tooling support is good: CloudFoundry provides Cloud Tools, which includes an Amazon EC2 Grails plugin and an Amazon Machine Image (AMI) pre-configured for running Grails; the CloudFoundry service itself makes deployment a breeze; also, if you're a SpringSource Tool Suite user, you can deploy to EC2 from within the IDE.
Despite the good support for Amazon EC2 deployment, there are a few gotchas to complicate matters.  Because of the ephemeral nature of EC2 instances, you'll need to use an Elastic Block Storage (EBS) volume to park your database on.  Also, if you want a static IP address for your app, your need to configure an EC2 Elastic IP Address.  These add to the cost of the deployment, as well as the complexity.  Running just one of the smallest available instances with persistent storage 24/7 will cost you just over $60/month.
The easy deployment and horizontal scalability of Amazon EC2 make it a great platform for running you're application once you're in production with a large number of users.  However, if you're in the prototyping/early development stages, it's probably overkill. This was the case with a project I'm currently bootstrapping.  I was looking for a solution that was simpler and cheaper to use now, but also easy to scale up once the app goes public.
After a bit of research, I decided to take RackSpace's Cloud Server service for a spin.  At 3¢/hour (under $22/month) for a Linux server with 512MB RAM and a 30GB disk, and data transfer prices at 22¢/GB in, 8¢/GB out, the price was certainly right.  Incredibly, included in this price is 24/7 support by email, phone or live chat.
I found the setup to be quick and painless; my application was up and running on the server within the hour - this includes five minutes spent on the phone on a courtesy call from RackSpace's support team (which was a nice touch!).
I've reproduced the steps from signup to deployment below:
  1. Sign up for RackSpace Cloud
  2. Spin up a server instance.  You'll need at least 512Mb RAM for Grails.  I chose the Debian (Lenny) distro, as setup for this distro is very well documented on the RackSpace wiki.
  3. Prepare server:
    1. Lock down your server, following the instructions at http://cloudservers.rackspacecloud.com/index.php/Debian_Lenny_-_Setup
    2. Install the Java SDK: sudo aptitude install sun-java6-jdk
    3. Install MySQL: sudo aptitude install mysql-server mysql-client
    4. Install Grails:
    5. Create and run a test app to make sure everything is correctly set up.
  4. Save a snapshot of this server to rollback to in the event of a catastrophe.
  5. If you need to do some admin to prep your database, I found the best way was to use MySQL Administrator, running on my local machine and connecting to the remote MySQL server through an SSH tunnel.  Instructions for doing this from a Windows client using Putty are here: http://realprogrammers.com/how_to/set_up_an_ssh_tunnel_with_putty.html
  6. You have a number of options for deploying your app, the simplest probably being rsync over SSH.  You can do this from your Windows development machine using cwrsync (remember to install rsync on your application server too).  An alternative, if you use source control for your project, is to install the source control client on your application server, and export a copy of the project from your code repository.  I use Mercurial, so this is as simple as running hg archive <repo URL>, which I execute on the application server via a script on my development machine.
Using this setup, I am able to run my app using the Tomcat server embedded in Grails.  I found that 512MB RAM was enough for this, but depending on the size of your app you may need to go for a 1024MB server instance.  Having said that, upgrading your server is just a matter of a couple of clicks on the Cloud Server control panel, so you can start of with 512Mb without worrying about scaling up.

So far, my experience with RackSpace Cloud Server has been great.  The price and simplicity are refreshing after working with EC2 instances.  However, as good as the service currently is, there is one significant limitation worth mentioning:  Although you can create any number of backup snapshots of your server instance, these will disappear with your server when you un-provision it.  As yet, it is not possible to create a persistent snapshot that may be copied to multiple instances, a la Amazon EC2 AMIs.  This means that if you want to take advantage of the hourly pricing and un-provision your server when not in use, you'll need to go through the set-up process from scratch when you spin-up a new instance.  It is possible to script the set-up process, however note that the Sun Java JDK install is interactive; this means that, even making use of the RackSpace Cloud Server API, a fully automated provisioning/un-provisioning of server instances is not trivial.  RackSpace say they are working on this; they hope to allow server snapshots to persist independently of the server instance in the near future.  On the other hand, with the service being so cheap, leaving the server running 24/7 is not a bad option.

One final point worth noting is that currently all Cloud Servers are based in the US, although RackSpace are planning to offer UK-based Cloud Servers "in the first half of 2010".  This means greater latency for European users, as well as European legislation issues around the export of personal data.