Scout
 

"HowTo" Posts


4 Simple Steps to Detect & Fix Slow Rails Requests

July 29, 2008 by Derek

Posted in HowTo | 11 comments 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... More

 

Monitoring Amazon EC2 Instances

July 03, 2008 by Charles

Posted in HowTo, Examples | no comments 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... More

 

Giving your web host access to your Scout account

May 29, 2008 by Derek

Posted in HowTo | no comments 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... More

 

How we handle background jobs

May 22, 2008 by Derek

Posted in HowTo | no comments 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:

Scout ~ Edit Graph

 

How To Customize a Scout Plugin

May 08, 2008 by Charles

Posted in HowTo | no comments 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

Scout ~ Bristol

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

 

Recording Historical Data in Scout

April 28, 2008 by Derek

Posted in HowTo | no comments 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:

Scout ~ Derek Laptop

Learn more about creating Scout Plugins