Ruby Weekly is a weekly newsletter covering the latest Ruby and Rails news.

Scout: A Ruby Powered Web Monitoring and Reporting Service

By Peter Cooper / March 27, 2008

scout.png

Disclaimer: Scout is a commercial service. I have received no compensation for mentioning this service and am posting about it merely due to my own interest in it.

Scout is a new "a la carte" monitoring and reporting service, primarily for tracking servers and Web applications, developed by HighGroove Studios. Scout lets you use plugins (provided both by HighGroove and other Scout users) written in Ruby to customize and manipulate your monitoring arrangements. You can also write your own plugins. Subscription levels will vary from a free account (one server, up to 3 plugins, 30 minute reporting intervals) up to over $100 per month for the highest level (supporting many more servers, shorter intervals, unlimited plugin usage, etc.)

The installation process and plugin system are what make Scout particularly unique and interesting. A Scout "client" is run on each machine you wish to monitor, and is installed with RubyGems (gem install scout). The client routinely runs its plugins and sends information to the central Scout service (rather than Scout "querying" the server, as with most monitoring services). Any plugins you install through the Scout Web interface are pulled down by the Scout client to all of the relevant servers automatically!

Scout is still in its pre-release stage (though not for long) but HighGroove have offered to give the first 20 Ruby Inside readers who mail rubyinside@highgroove.com an account! So.. be quick if you want a go :) (They've now all gone, sorry!)

I also decided to ask the Scout team a few questions about the service to get a better feel for how it works:

Is Ruby the only language used on Scout? If not, why not, and what else are you using?


James Edward Gray II: The Scout client and server are written in Ruby, yes. They make use of data formats like YAML and Ruby's marshaled object binary format as well as communicate using protocols like HTTP, but the beating heart is Ruby at both ends.

However, most plugins will shell out to external utilities. Some of these utilities might be considered languages in their own right. For example, AppleScript can be used to communicate with or control Mac OS X applications. Even the shells themselves are languages and plugin writers may want to make use of that fact.

The reason to rely on these external sources of data is simple: plugins can get the data they need from the expert sources with very little effort. Duplicating the functionality of all popular system utilities in Ruby would be a massive undertaking and extremely error prone. Instead, we want users cranking out handy plugins by investing small slices of time. In short, we want to focus on the interesting problems that haven't already been solved.

Which technologies does Scout use?


Derek Haynes: The web interface is a Rails app, but the bulk of the requests are processed by a separate Merb app that handles all of the alerts, reports, and errors that are sent to Scout. We went with this setup for 2 primary reasons - we need to continue to process data even when we're updating the web interface, so we needed to decouple the web service from the app and Merb handles these requests more efficiently.

Why did you choose Ruby for Scout's plugin language, and how has it worked out so far?


James Edward Gray II: Like her sister language Perl, Ruby is a powerful tool when used to glue system utilities together. The ease of talking to external processes and the powerful string manipulation features make it an ideal choice for collecting important data and transforming it into the needed formats for the server. This is a big strength of Ruby's design that gets overlooked too often. We hope to change that, of course.

How does Scout plan to deal with availability?


Charles Brian Quinn: The Scout server is running on virtualized hardware, with two physical locations at InterNAP and the AtlantaNAP data centers. We are fully load-balanced with failover support. In the event of failure at one of the datacenters, we are fully redundant. We plan on scaling out horizontally as the need arises.

Do you have any plans or see any further innovations for Scout using Ruby further down the road?


Derek Haynes: I hate to sound like a Real Estate Scammer, but it's practically unlimited. You can include any Ruby library when running a plugin (here's an example that "loads the Rails environment" and "another that uses hpricot"), so anyone can extend the client. An obvious answer is a Ruby DSL for working with system commands. A couple of new libraries address this in different ways, but as James said earlier, a one-size-fits-all solution is a massive undertaking.

Comments

  1. Pedro says:

    Hi, I'm new to Rails web development. I'm using the Google chart API. It's ok, but isn't great.

    What chart library are you using?

  2. Derek Haynes says:

    Pedro,

    We're using amcharts (http://amcharts.com). It's flash-based, not images like Google.

    I found it easy to setup and they look great - we tried several graphing libs and we are very happy with it.

    Cheers,

    Derek

  3. Chris says:

    I've been using scout for a little more than a week and I gotta say that I love it. I really like the power and functionality afforded through the plugin system. I've run into a couple issues but it's a young system. Actually, for each issue, all I did was log onto their chatroom and I got to talk to an engineer that quickly fixes my issue. That's a very, very nice added bonus.

    I'm looking forward to an iPhone version of the site, as it uses Flash exclusively for the graphs but they've assured me that it's on the way.

    All in all, a really cool service.

  4. Jon Gretar says:

    Damn... This looks exactly like something I would need. Unfortunatly my company does not allow the use of hosted services.

    That is kinda the only true Ruby weakness. You can develop an application in Java and compile it so you can easily sell it to users that host it themselves but that gets rather hard when you are using uncompiled language such as Ruby.

  5. Pedro says:

    Dereck,

    Thanks for your answer. It looks exactly what I have been looking for. Specially the zoom in the stats, I have been using Ajax and google API for something like that, and was really painfull.

Other Posts to Enjoy

Twitter Mentions