January 06
Andre
Comments
2008 was a year full of numbers – 34% (fall of the the Dow Jones Industrial Average), $1.84B (Apple iPhone revenue), and $100M (cost of the Beijing Olympics Opening Ceremony).
But raw numbers are just the start – in 2009, our goal is to tell you what they mean:
- Your Rails application is slow. Now what? We’re bringing deeper, more actionable Rails instrumentation .
- You’ve got one hell of a memory leak. What’s going on? We’ll help you get a complete picture of your system right when the leak happens.
- You’re on the ski slopes but want to stay abreast of trends. We’ll help you get beyond raw numbers and alert you on trends.
And besides the functionality, there’ll be a new name for Scout in Q1!
Stay tuned for details in the coming weeks (or just subscribe to our RSS feed).
December 05
kevin
Comments
Merb Day Atlanta – a “one-day, one-track conference for Ruby and Rails developers looking to learn Merb” – is this Saturday and Scout’s extremely proud to be one of its sponsors.
Our own Charles Brian Quinn and Matt Todd will be there, taking in the sights, and Matt will also be talking some code – he’s teaching a three-part tutorial with Michael Ivey on learning, using, and hacking Merb.
Be sure to say hey if you get the chance!
November 25
Derek
Comments
David Grandinetti of WeGoTo12 has added a pair of Scout plugins for 2 web services many Ruby on Rails developers are familiar with:
Lighthouse Open Tickets
This plugin tracks the total number of open tickets for a specific Lighthouse project. Lighthouse is a issue tracking, bug tracking, and project management hosted application.
HopToAd Unresolved Errors
This plugin tracks the number of unresolved errors in a HopToAdd project. HopToAdd is a hosted service for tracking and managing exceptions generated by a Rails application.
You can view a full list of available plugins in our plugin directory. The source of these plugins is available on Github.
September 23
Derek
Comments
I really like Dan Mange’s workflow for Rails performance tuning:
- Use
curl for benchmarking. It’s good enough (and damn simple).
- Use the ruby-prof gem along with an optional request parameter so you can profile any action, any time.
Dan also does a solid job explaining CPU time and what if means for your Rails app. A snippet:
At CarePages we have an Apache log that logs the controller, action, and Rails runtime. We run a script that groups the runtimes by controller and action, and then calculates the total runtime for a controller/action divided by the total runtime for all requests. What we found the first time we did this was that one of our pages was taking nearly 40% of the overall CPU time. It wasn’t the slowest page, but it was the most frequently hit page. We had two other pages that were taking about 19% and 13% of the overall CPU time. This gave us a good place to start – if we could make the 40% page twice as fast, we would lower our overall CPU usage by 20%.
September 09
Derek
Posted in HowTo | Comments
Life as a cross-dresser must be unnerving. I could buy a wig, put some makeup on my adam’s apple. Buy a skirt. Does a sock-filled bra work for my bosom?
With a bit of mood lighting, I might actually look like a woman, but it would be difficult to relax. Knowing my manhood could be exposed in a multitude of ways – some stubble on my chin, hair on my legs, forgetting to make my voice less deep, etc. would leave me on-edge.
In some ways, I feel like I identified with cross-dressers before we solidified our Rails monitoring stack over the past year. I just felt vulnerable – that one wrong move could send our Rails stack tumbling.
We’ve standardized our setup, and I thought I’d share the 3 tools we’re using that make me feel much less like a cross-dresser these days.
The 3 pillars of our Rails monitoring stack
We break Rails monitoring into the 3 parts below (along with the tools we use):
Process Monitoring
|
System Performance
|
Exception Notifications
|
“The Diaper”
A safeguard for emergencies
|
“The Nerves”
Preventing future problems
|
“The Megaphone”
A loud voice when your app is breaking
|
|
Monit
|
Scout
|
Exception Notification plugin
|
|
Ensure Mongrels are running & restart leaking processes
|
Catch disturbing trends before they become problems – disk space usage,
server load, slow requests, etc.
|
Organizing and collecting application exceptions
|
So, to be clear, even though we built Scout, we use a combination of tools to make sure our Rails apps are running.
Read more... 
August 29
Derek
Comments
Plot a week of data. A month. A year. We’re not picky – choose any time range and Scout plots the data in real-time.
You’ve always been able to graph as much data as your plan allows on Scout, but now it’s a whole lot faster. It takes a lot of horsepower for graphing – in fact, some monitoring products limit you to 24 hours of data. Some give you access to more, but you’re in for long wait. When you’re making serious decisions about Rails performance, we think you need to see as much as data as quickly as possible.
Watch a 1 min. 34 sec. Quicktime clip that shows our new graphing engine in action:
If you are an existing Scout user, note that you can now edit your default plugin graphs in-place – there’s no need to create a separate graph. You have the option to save your changes to the graph so it loads with the new settings next time you view the plugin.
August 22
James
Posted in Plugins, Updates | Comments
The number one requested plugin for Scout has been a Phusion Passenger monitor. I’m happy to report that is now available.
Using the new Passenger Monitor plugin, Scout can keep track of Passenger’s VM size, process count, and the amount of private memory it has squirreled away. Aside from just tracking these numbers for graphs, you can also elect to be emailed if any of these statistics crosses a line you indicate. As an added bonus, this plugin also tracks the same statistics for the Apache instance managing Passenger.
Passenger has quickly become a great new way to deploy Rails applications and we want to make sure Scout is keeping up with the curve.
August 11
Derek
Comments
Ensuring 15 Rails apps are running smoothly can be a real chore, especially when they have core pieces that fall outside the typical monitoring stack. Mike Mangino of Chicago-based Elevated Rails recently wrote about consolidating his Rails monitoring efforts using Scout:
This simple interface to reporting and alerting is incredibly powerful. What makes it even more powerful is the ease with which you can install plugins.
...
So far, using Scout has been a real joy. That’s something I never thought I would say about a monitoring tool.
Mike has open-sourced much of his work, publishing his plugins for Scout in our directory:
You can fork and/or follow Mike’s Scout plugins at GitHub.
August 05
Charles
Posted in Updates | Comments
You can now follow our commits to Scout plugins at our GitHub Repository.
GitHub makes it easy to find out when new plugins are created. Feel free to fork us (as long as forking is legal in your part of the world).
Quick note – remember to use the raw format when using your own plugins from GitHub by appending ?raw=true to the plugin script URL.
Also see:
July 29
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...
