A tour of Scout's Ruby on Rails Monitoring Plugin

June 22 Bullet_white By Derek Bullet_white Posted in Plugins Bullet_white Comments Comments

Curious how data moves from your Rails app to Scout? Wondering how Scout handles high-traffic Rails apps? Where does Scout add MySQL suggestions? How are alerts generated? I’ll guide you through the process below.

Logging each web request

At a basic level, Scout’s Rails benchmarking isn’t much different than what gets written to your Rails log. Instead of writing to a log file, the Scout Rails Instrumentation plugin sends a Hash to the Scout Agent like the one below:

{:num_requests=>2, :avg_request_time=>241.0, :actions=>
:num_requests=>2, :render_runtime_avg=>8.59355926513672, :render_runtime_max=>8.73303413391113, 
:runtime_avg=>241.0, :other_runtime_avg=>77.4774407348633, 
:queries=>[[[156.152, 0]], [[153.706, 0]]], :runtime_max=>243.0, 
:other_runtime_max=>78.1149658660889, :db_runtime_avg=>154.929}}, 
:queries=>["SELECT * FROM \"users\""], 
:scout_time=>"Mon Jun 15 21:04:00 UTC 2009"}

These messages are sent to the Scout Agent every 30 seconds by the Scout#Reporter.report! method:

response = ScoutAgent::API.queue_for_mission(Scout.config[:plugin_id], report)

The instrumentation runs in a background thread that is only active when reporting to the agent, and since the queuing process is asynchronous once the data has been prepared, the impact on performance is negligible. We’ve benchmarked the impact between 1ms-3ms with a small memory requirement (1 MB).

Running the Instrumentation Plugin

Every three minutes, the agent collects the messages sent to the agent, analyzes & aggregates the data, and sends the results to Scout.


A large Rails application can process a lot of requests – for example, a Rails app with 50 web processes may result in up to 300 messages queued to Scout. If we needed to process every request on our server, our hardware cost would dramatically increase for high-traffic Rails apps.

Enter the Scout Agent.

Instead of sending reports directly from your Rails app to our server, the agent steps in between to decrease the load. The agent creates a single report for each action that contains the minimum, maximum, and average for each benchmark as well as the number of requests. No matter how large or how small the Rails application is, Scout generates just 1 report for each unique action – dramatically cutting down the hardware costs for serving Scout.


The agent looks through the messages sent to the agent, looking for slow MySQL queries, missing indexes, and more. When an optimization opportunity is found, a Hint is created.

Triggers & Alerts

Triggers are Scout’s way of tracking when things go wrong. In other words, leave the number crunching to Scout. When you install the Rails Monitoring Plugin, 2 default triggers are created:


When a trigger fires, an alert is created. A sample alert from Scout:

Scout ~ Alert

Alert Throttling

When things are really going wrong with your application, the last thing you want is a every-minute email blast. Scout sends one alert when something goes wrong then another when the conditions are back to normal. Scout will continue to update the alert on scoutapp.com so you’ll see the most recent data.

Elsewhere & Digging In

You can find everything but the Scout server on GitHub:

Get notified of new posts.

Once a month, we'll deliver a finely-curated selection of optimization tips to your inbox.


comments powered by Disqus