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.
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.”
Older baseball players typically have plenty of power and discipline but are slow runners with lower batting averages. It’s kind of obvious: as we get older, we get bigger and more patient, but we also get slower. This characteristic even has a name, described as (you guessed it): old player skills.
Bill James, a famous baseball historian, studied these players and found that younger players that start with these skills fade away faster than than their peers. The players that have long careers are often those that have speed when they’re young and are able to adapt as the gifts of youth fade.
What does this have to do with small, self-funded, developer-run businesses like us?
James Gray, lead developer of the Scout Agent, takes a stab at the eternal question “What makes a great developer?” in the latest RailsCoach Podcast Episode.
Besides talking about Scout’s blended open-source approach to monitoring, James also talks about The Pomodoro Technique (a time management process), his time at the helm of the RubyQuiz, NoSQL, and other topics.
On Thursday, January 21st at 1pm Central I’ll be leading a webinar with Rackspace where I’ll show how Scout makes monitoring your cloud enviroment a snap. Using Scout, I’ll show how to:
monitor cloud servers automatically when they boot
update monitoring on your entire cluster in one click
In other words, you’ll learn how to get the day off the next time your monitoring infrastructure needs to be updated.
If you’re looking at deploying more of your infrastructure to the cloud and are curious about monitoring solutions this webinar is for you.
How much memory is really available on your Linux box? Don't use /proc/meminfo to find out, use free -m instead. You may have more memory available than you thought.
Here's an example. /proc/meminfo says about 330MB is free:
You'll see the "buffers" and "cached" columns, which tell you about the amount of memory that the kernel is using for filesystem buffers, etc.
This sort of cached data will be freed by the kernel when an application tries to allocate more than what is "free", which is why the "-/+ buffers/cache" line is really the important line to pay attention to when you're checking out the free memory on a system.
So in this example, 708MB is how much memory is technically available for allocation should an application need it. The "buffers" (86MB) and "cached" (288MB) will be released by the kernal if they are needed.
Just provide the paths to your Sphinx log files and Sam’s plugin reports the following data:
Queries per-minute
Average query time
Average time per rebuild
Index rebuilds
Average results returned
Like with any Scout plugin, you can plot metrics from the Sphinx Monitoring Plugin against other metrics. For example, the chart below shows the relationship between the Sphinx query rate and the server load:
With the fifth release of the Scout Agent we introduced server downtime monitoring to all of our plans. You may already use a website monitoring service like Pingdom for alerts when your website goes down. What’s the difference between website and server monitoring? Can one replace the other?
Derek
