"HowTo" Posts
July 29, 2008 by Derek
Posted in HowTo | 11 comments 
In Blink, Malcom Gladwell’s book on split-second decisions, Gladwell tells the story of how the Emergency Department at Chicago’s Cook County Hospital changed their process for diagnosing chest pain.
Dr. Brendan Reilly instituted a simple test to determine whether a patient was suffering from a heart attack. It combined just 4 questions with the results of an ECG. This simple test was 70% better than the barrage of questions previously asked by hospital staff to identify patients that weren’t having a heart attack and was nearly 20% better at identifying patients that were having heart attacks.
More information on the patient’s symptoms often led to an incorrect diagnosis. It distracted doctors from the real issues.
I’ve seen this many times with developers trying to debug performance issues in Rails applications. They look at outliers instead of the obvious culprits. It’s part of the reason I’ve never felt a need for a deep, detailed Rails monitoring application (i.e. – benchmarks from the controller to the database level on every request).
The majority of the time, our performance problems have nothing to do with the Rails framework (and we’ve worked through a lot of issues since we started building Rails apps in 2005). Why benchmark the entire request cycle when the vast majority of issues are isolated at the database layer? After I’ve ruled out the database, I can see benchmarking a single request (there’s a great free tool below), but I simply don’t want the other, often irrelevant information clouding my mind.
The root symptom we want to avoid in our apps is slow requests. Our Scout plugin for analyzing slow Rails requests has been installed nearly 250 times, so we’re not alone there.
Read more... 
July 03, 2008 by Charles
Posted in HowTo, Examples | no comments
Amazon’s Elastic Compute Cloud (Amazon EC2) Service is changing how we approach computing infrastructure. Scout is an ideal monitoring solution for Ruby on Rails application servers on EC2 instances.
Why use Scout for monitoring your EC2 instances?
- Just a single line of code to add the client
- No complicated scripts to configure – choose what you want to monitor through the Scout web interface
- Easy to re-use or view statistical data once an instance has terminated
Overview
The basic process for EC2 monitoring works like this: You create a new client that you want to use as a template . You can then clone this client (and all of its plugins) using the scout clone command, which can be added to the boot/startup script on your AMI.
Read on for the Step-by-Step.
Read more...
May 29, 2008 by Derek
Posted in HowTo | no comments
A couple of times already, we’ve seen users give their web host access to their Scout account.
It’s a big help when debugging problems – especially things that a basic monitoring tool might not pick up (like slow web requests).
Read more...
May 22, 2008 by Derek
Posted in HowTo | no comments
We run background jobs on our Scout servers. Lots of them.
As we’ve grown, they’ve used dramatically more resources. We needed a way to simmer them down. Most of these jobs load the entire Rails environment – that’s a hefty overhead.
We’ve modified how we run background jobs and we’re seeing great results. If you’re interested in what we did, checkout Charles’ post on our Highgroove blog.
And finally, here’s the obligatory semi-promotional graph, generated by Scout, of how the load dramatically decreased after implementation:
May 08, 2008 by Charles
Posted in HowTo | no comments
Since Scout Plugins are open source, it’s easy to modify them to fit your needs.
Here’s a quick way to create a custom version of a Scout plugin.
1. Grab the current plugin and options
The code:
curl http://plugins.scoutapp.com/mongrel_cluster_monitor/trunk/mongrel_cluster_monitor.rb \
> mongrel_cluster_monitor.rb
The options:
curl http://plugins.scoutapp.com/mongrel_cluster_monitor/trunk/mongrel_cluster_monitor.yml \
> mongrel_cluster_monitor.yml
2. Edit the plugin code and test
scout -p /path/to/customized/mongrel_cluster_monitor.rb \
-o '{"mongrel_cluster_configuration_dir"=>"/etc/mongrel_cluster"}' \
-v -l debug
That says, use the -p option (or --plugin) and the -o (or --option) to
test locally, passing these options, be verbose (--verbose) and
set the log level to debug (--log-level debug).
Note that you could also add your own “option” there, as the path to
one of the configuration files…. however you want to do it.
3. Host the Plugin
Then, all you have to do is make that plugin and its options file (of
the same name) URL accessible (put it in your rails public dir,
perhaps, or on another server) for the scout server to be able to grab
it when you install. When you install, choose, Manual—and type in
the URL to your new customized version
(http://highgroove.com/new_customized_single_mongrel.rb for
example).
More on creating plugins
April 28, 2008 by Derek
Posted in HowTo | no comments
By default, when you create a report in Scout, we assume that the data corresponds to the time the report was submitted.
Sometimes this isn’t the case – for example, you can retrieve the number of subscribers to your RSS feeds in Feedburner, but not from the current day.
You can override the time Scout records the data in a Plugin with the special :scout_time report key.
Here’s an example:
# typical report data
{:circulation => 1000}
# correspond the data w/ February 24, 2008
{:circulation => 1000, :scout_time => Time.parse("2/24/08")}
When displaying the data on a graph, the data will be shown on 2/24 and not the current date:
Learn more about creating Scout Plugins
