We’re developing features that make using Scout in a cloud hosting environment super simple (Amazon ec2, Rackspace Cloud, GoGrid, etc). We’re looking for BETA testers, so shoot us an email at email@example.com with your account name if you are interested in giving Scout’s cloud support a try.
If you're using Amazon EC2, you may be familiar with CloudWatch, Amazon's analytic system that provides metrics on CPU usage, Network I/O, and Disk I/O of your instances. While CloudWatch collects metrics, it doesn't provide a web interface for viewing the metrics, graphs, trending, or alerting.
Enter our Scout EC2 Cloudwatch plugin. Like any other Scout plugin, you can graph the resulting metrics, set triggers, track trends, and get email alerts when the numbers go out of bounds.
What does it monitor?
The CloudWatch plugin captures the following ("measures", as EC2 calls them): NetworkIn, NetworkOut, DiskReadOps, DiskWriteOps DiskReadBytes, DiskWriteBytes, CPUUtilization.
Note, this plugin does not fetch EC2 Load Balancer Metrics, only EC2 instance metrics.
Single Instance, Autoscaling Group, etc.
The EC2 CloudWatch plugin can capture metrics from a single EC2 instance, or it can aggregate metrics across a couple of dimensions. It can aggregate metrics across a given instance type, across all instances launched from a specific image (AMI), or by a specified autoscaling group. That means you can, for example, graph the performance of your application server autoscaling group as a whole, or graph just your memcached instance.
To use this plugin, you have to enable CloudWatch for the instance(s) you want to collect metrics from. See Amazon's CloudWatch docs for details. Basically, it's just
ec2-monitor-instances ##### from the command line, or passing a monitoring parameter to the ec2-run-instances. It's covered nicely in Amazon's docs.
New to Scout?
If you're learning about Scout through this plugin, sign up for a trial Scout account to give this plugin a try. You can graph all kinds of metrics and measurements from all your servers. It works with cloud instances, VPS's, and dedicated hardware.
James Gray's July 19th talk at RubyKaigi 2009 focused on best practices for long-running Ruby daemon processes.
What types of questions did the audience ask? What did they seem most interested in?
In general, users always want to know about our RRD usage, extracting the daemon functionality from Scout's agent, and the agent's memory usage. It was the same at RubyKaigi. The questions reminded me of how much current Ruby RRD solutions suck and that it's time we did something about that. It also reminded me that I need to get around to extracting our daemon code, which I've always intended to do.
As FiveRuns posted on their blog they have announced End-of-Life for FiveRuns Manage. We have made arrangements with FiveRuns to ease the transition for customers who still need a robust, easy-to-use monitoring solution.
For current Fiveruns customers, we are offering 50% off your first paid month here with Scout . Note that this is only for current FiveRuns Manage customers, and that the offer expires in one week (August 19th). Of course, like any other Scout signup, it’s risk-free: your first month is free (and your second month is half-off) and you can cancel, upgrade, or downgrade at anytime.
FiveRuns Manage customers: use your discount code on our signup page, and welcome to Scout!
Getting started with Scout is very straightforward, and the signup process guides you through all the steps. The main difference from FiveRuns Manage is that you choose the components you want to monitor by selecting plugins. You can add or remove plugins at any time, and we offer some suggestions for getting started below.
Your basic process is this:
- Install the gem:
sudo gem install scout_agentand start it with the server key you’re given on signup
- Select one or more plugins from the directory. The Server Load, Disk Usage, and Memory Profiler are easy plugins to get started with.
- Customize or add Triggers. Scout uses triggers to alert you of spikes or trends in the data being gathered—for example, “alert me when the five-minute load average exceeds 4.0” Plugins come with default triggers, and you can customize all you need.
Let us know if you have questions!
You might be familiar with Linux load averages already. Load averages are the three numbers shown with the
top commands - they look like this:
Most people have an inkling of what the load averages mean: the three numbers represent averages over progressively longer periods of time (one, five, and fifteen minute averages), and that lower numbers are better. Higher numbers represent a problem or an overloaded machine. But, what's the the threshold? What constitutes "good" and "bad" load average values? When should you be concerned over a load average value, and when should you scramble to fix it ASAP?
What is iostat and why would I use it?
What are the plugin configuration options?
There are three configuration options for the iostat plugin:
- iostat Command -- most likely, you won't need to change this. Consult the iostat documentation for other flags and options.
- Device -- defaults to /, or specify any defice you want to monitor.
- Interval -- defaults to three seconds; set to a different number to have iostat report averages over that many seconds
How do I install the plugin in Scout?
Ensure the iostat command is installed on your server. If it's not, you probably just need to install the sysstat package. For example, on Ubuntu this is apt-get install sysstat.
Enjoy, and let us know if you have any feedback.