May 09, 2008 by Charles
Posted in Features | 1 comment 
We’ve been working on two major features that we’re sure will be a hit, and that we can’t wait to talk about:
1) Easier Plugin Creation—there’s a reason we love Ruby, and not just because it’s such a powerful language for talking to external system processes and manipulating strings (as pointed out by JEG2 in our RubyInside debut). Ruby makes writing powerful code down-right simple through a very natural language. And with our new plugin code helpers and syntax, you can write a plugin like this:
my_output = `run some wild script here`
remember(:last_time_output => my_output)
report(:data => my_output)
if my_output ~= /Error/
alert("An Error Occurred", "Details: #{my_output}")
end
And that’s not all. We’ve built a clearer syntax for how you invoke Scout, and how you interact with options and how you can store your own settings and report your own data.
2) Automatic Client Provisioning—if you have any servers in the cloud, or just more than one server, you already know how easy it is to install Scout (one liner to install and another to setup), but it just got easier than that. You can now automatically provision clients using the scout client itself. I know, crazy-talk, but watch. On bootup, of our Amazon EC2 instance, we’ll just run:
scout clone [client-key] `hostname` >> /etc/crontab
And we’ve just setup a new client on scout, with all our pre-configured plugins, cloned from another client, and the name of our hostname, setup to run on our interval.
If you’re interested in helping us beta test the new 2.0 version of our client, you can install it from our beta-gems server:
sudo gem install scout --source http://beta-gems.scoutapp.com/
Let us know what you think. Be sure to check the README to find out more details on what’s new.
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 29, 2008 by Derek
Posted in Features | no comments
One of the things people like most about Scout: the plugin code your clients execute is downloaded via a plain-vanilla HTTP or HTTPS connection like this one. This means you can simply update the plugin code once, and any clients that run the plugin grabs the new code. You don’t have to manually install scripts on each monitored server.
But what happens if the web server hosting the plugin code isn’t available? What if you are running a plugin someone else developed and they change the plugin code?
We’ve got you covered. Scout now caches the plugin code when you add a plugin to a Scout Client. By default, Scout locks to the version of the code available when the plugin was installed. However, you can override this and have Scout automatically grab the latest version. You can also perform a one-time update.
We check for code updates every 5 minutes, so if you are debugging a new plugin you developed, click the “Update Code” button when you push out a change to instantly refresh the code.
Read on for screenshots.
Read more... 
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
April 24, 2008 by Derek
Posted in Examples | no comments
Determining a web application’s hardware resources isn’t easy (or cheap). Frankly, it’s often just guesswork. Even when you build benchmarking scripts, they can miss key behaviors and ignore important metrics.
Scaling becomes a lot less stressful when you can quickly compare a history of your application data with server performance.
For example, we did this to get a better understanding of how our Scout server performed during our invitation process. The graph below was generated through Scout and shows the relationship between user accounts and the server load. As we expected, the overall load on the server increased as the number of accounts increased. Scout shows us how this data is correlated – it gives us an idea of how many accounts our current hardware can support.
Scout Accounts vs. Server Load
It’s trivial process to regularly feed Scout your application data (user signups, orders, revenue, etc):
- Start with this Rails App Plugin Sample (this assumes a Ruby on Rails application, but you can do this with any framework/language)
- Grab your application data – just use ActiveRecord!
- Put the plugin on your server (can protect behind basic auth)
- Add the plugin
April 23, 2008 by Charles
Posted in Plugins | no comments
Sometimes, the simplest ideas make for the best plugins.
Let’s say you have some process that always needs to be running (maybe that’s a ferret server or a backgrounDRb server) or maybe it’s just Apache.
Install the Keep Process Running Plugin and Scout will help make sure that process is always running.
The plugin simply scans the active running processes, and checks to see if that process is running. If it can’t find it in the active process list, it will attempt to run the restart action. You can specify anything, so if you need to perform some special startup task (/usr/bin/apachectl start) it can do that. If you do not specify a restart action, it simply re-runs the command it is looking for. This actually works well in most cases.
If you have any feedback or suggestions on this plugin feel free to comment on the plugin itself.
April 22, 2008 by Derek
Posted in Plugins | no comments
Ever wanted to track how many people are logged into your server? Mark Hasse built an Active Logins plugin that does just that, returning the total number of people logged in via console, ssh, telnet, etc.
Mark has built several other plugins as well:
It’s easy to create a Scout a plugin and we’re here to help. Some useful plugin resources:
April 21, 2008 by Derek
Posted in Features | 181 comments
We’ve received great feedback on our existing Scout plugins, but we wanted a better way to organize it. Friday we called on our inner agileness and built plugin ratings and comments.
If you have a Scout account, you can rate and comment on plugins in our directory. If you don’t have a Scout account, it’s completely free to signup – no obligations, late night phone calls, etc.
We’ll use your feedback to tune our plugins. If you have an idea for a new plugin, just add it to this thread in our forums.
April 17, 2008 by Derek
Posted in Plugins | no comments
Swap memory is like pushing your car downhill when it’s all out of gas. Sure you’ll keep going, but just not as fast. Oh, and use too much, and you could be in trouble.
In our experience, when a significant amount of swap memory is used, our web application performance slows down dramatically. Swap memory is just a lot slower than physical memory.
Eric Lindvall has created a nice plugin that profiles a system’s memory usage, returning the following information:
- Swap Total
- Swap Used
- % Swap Used
- Memory Total
- Memory Used
- % Memory Used
View the Memory Profiler Plugin
April 16, 2008 by Derek
Posted in Plugins | no 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.
