This is the blog for Scout, simple server monitoring
powered by plugins. From request times to memory usage,
put your monitoring in one place.
Install in minutes.
This info is for Scout plugin authors.
The Scout Agent version 5+ supports options inline in the code. If you're not using inline options, you should. Here's an example from the awesome new Redis monitor plugin:
class RedisMonitor < Scout::Plugin
OPTIONS = <<-EOS
client_port:
name: Port
notes: Redis port to pass to the client library.
default: 6379
client_db:
name: Database
notes: Redis database ID to pass to the client library.
default: 0
client_password:
name: Password
notes: If you're using Redis' password authentication.
EOS
...
Using inline options makes the plugin easier to test and troubleshoot, since the Scout agent knows about the options and can utilize the defaults in test mode:
$ scout test redis-info.rb
== Plugin options:
1. 'client_port' Default: 6379. Redis port to pass to the client library.
2. 'client_password' If you're using Redis' password authentication.
3. 'client_db' Default: 0. Redis database ID to pass to the client library.
== Running plugin with: client_port=6379; client_db=0
....
By the way, if you want to test the plugin with something other than the default values, just include them like so:
$ scout test redis-info.rb client_password=seekret
Finally, if you're thinking about a new plugin for Scout, we'd love to hear about it. We're always happy to get you started or point you in the right direction. Read more on plugin development here.
Bootstrapped tech startups are a lot like restaurants started by quality chefs. It’s easy to find restaurants serving award-winning food that fail. There are lots of self-funded startups started by smart developers that either never launch or die a painful death. Writing quality software – just like serving good food – is the foundation, but it’s not going to make you profitable.
Like chefs who take pride in their food and constantly strive to improve it, developers like us are never done making our software better. There is an unlimited list of things we’d like to improve. Better scheduling and planning won’t shrink the todo list – it’s a leaking todo list that spawns another todo when one is completed.
Andre talks about data security with hosted monitoring, remodeling his bathroom, how Scout fits in with existing tools like Nagios and Munin, our secret open-source sauce for data storage, and smoke detectors.
On his blog article regarding the interview, Robert says of Scout:
I have had the opportunity to use Scout and witness the power of the application. One of the most impressive aspects I see is the plugin system. Scout offers a bunch of plugins, all open source. Developers can also freely develop their own plugins for their own purposes and are welcome to contribute them as open source. An all around win.
We made a small improvement on the graphing interface, thanks to your feedback. It's now a lot faster to select multiple metrics to graph. You can select metrics via checkboxes like so:
Instrument your business. It's like instrumenting your code, but profitable.
If you're a developer or a sysadmin, periodic optimization is a fact of life. As more people use your code, you'll see performance issues. Unoptimized use cases bubble up. Systems get strained by continued or heavy use.
If you haven’t heard of Chef, Seth provides a great overview in this blog post. To quote Seth:
Chef is a state-based, configuration management tool written entirely in Ruby. It is scalable and completely open-source. The 37 Signal’s team describes it as “Rails for sysadmins”! With Chef you don’t write scripts to configure your infrastructure you write code that programs it.
If you’d like to learn more about Chef and live in the Atlanta area (or have a private plane), Seth will be presenting at tomorrow’s Atlanta Ruby Meetup Group meetup. Joshua Timberman of Opscode, the open source company behind Chef, will be presenting with Seth.
Delayed::Job is a widely used database-backed asynchronous priority queue extracted from Shopify. Need to send massive newsletters? Handle batch imports? Using Ruby on Rails? Take a look at Delayed::Job for these types of long-running scheduled tasks.
Lukas and Alex originally developed the plugin during a pairing session while working on PaperC, an online book platform specializing in textbooks. PaperC processes PDFs using Delayed::Job. Eric made several additions to the plugin based on his work at Cloudvox, an easy-to-use open phone API platform. Cloudvox even supports conferencing and activating phone numbers.
Developers! You can churn out a Rails or Sinatra app in no time. What about putting it out there in production? Occasionally forget the syntax for crontab or logrotate? Yeah, me too.
That's why I wrote up a few essential notes for a serviceable production environment.
This article covers Centos/Red Hat and Ubuntu, which is what I always end up on. My approach is to get some minimal configurations working quickly so I can see some results. From there, I can go back and refine the configurations.
You realize a default alerting threshold is too low or you want to add additional monitoring functionality to all 100 of your servers.
Do you login to every server, update the scripts, and reload? Maybe build a custom script to automate this?
Follow the lead of the smart people at Railsware – Web Apps Made with Passion. Railsware, an Agile Rails development firm which manages a large cluster on Amazon EC2, saves a lot of time (and a lot of pain) using Scout to monitor many servers:
It’s difficult to imagine updating monitoring scripts across dozens of our servers manually. What takes a couple of mouse clicks with Scout might take hours with traditional monitoring software.”