Monitoring Your Rails Sessions With Scout

By Derek Bullet_white Posted in Plugins Bullet_white Comments Comments

An oft-forgotten maintenance issue on Ruby on Rails applications is forgetting to expire old sessions. Lots of sessions in your database can dramatically slow performance.

You can use a cron job to expire old sessions, but it’s not always foolproof. We’ve seen timeouts when attempting to delete lots of session records and it’s not out of the range of possibilities to mistakenly disable multiple cron jobs.

Tim Morgan provided the inspiration for our latest plugin, Rails Session Monitoring. The plugin is dirt simple, reporting back the total number of sessions and the number of old sessions (you can define what constitutes old – the default is 14 days).

Here’s what I saw when I ran it on of our apps:


This is also the type of plugin that you don’t really need to run frequently – once-per-day is probably fine.


Scout Opens to Public

By Derek Bullet_white Comments 3 comments

The floor is waxed, the windows are washed, and the paint is fresh.

Scout, our server monitoring and reporting application, is at your service.

As a web developer, there are few things I value more than a solid block of focused development time. Because Scout has largely removed the lingering question “Is everything working?”, I have more of this time than ever before.

We believe Scout represents a shift in how web resources are monitored, primarily in 3 ways:

1. Monitoring has to be Open-Source

No single organization can keep pace with the speed of technical advancements. We believe the best monitoring practices are abstracted from real-world experience, not from a single organization attempting to cover the monitoring field. It’s our responsibility to make it as easy as possible to build, share, and present data from monitoring scripts built by the community. We all win when web services become more reliable.

2. Monitoring isn’t just for Sys Admins

We’re asking more of people than ever before – you’re now a product manager/front-end developer/AJAX wiz/database administrator/sys admin. The service that collects the most data doesn’t win – it’s the one that makes it understandable and actionable to a variety of people quickly that does.

3. If you’re just looking at the server, you’re missing 1/2 the story

When you’re just looking at data collected from your server, you’re looking at symptoms. You’re forced to take educated guesses, and wrong decisions can be extremely costly and time consuming when determining your resource needs.

It’s far easier to make resource decisions when you can see trends between server data and outside information like web application data (number of users, orders, etc) and analytics data (unique vistors, page views, etc). This data needs to be collected along with internal data to give a real-time view. Before Scout, it was time-consuming to pull all of this data together.

So, go ahead and get started with Scout!