Do we really need a phone number?

By Derek Bullet_white Posted in Business Bullet_white Comments Comments

Like a bug zapper on a Midwestern summer evening, our company phone number attracted lots of annoying visitors: partnership offers from the Middle East, RFP requests for the wrong product, support inquires for a dating service, etc. In fact, I can only recall a handful of calls from real-life customers.

Did we have a phone number because it solved a problem or because we thought businesses – serious ones – are supposed to have one?

For now, we’ve stopped displaying the phone number on our website. While I don’t think this makes sense for every business, for a developer-focused business like Scout I’m betting it won’t be an issue.


New Plugin: Simple Process Check

By Andre Bullet_white Posted in Plugins Bullet_white Comments Comments

Simple Process Check is a new plugin in the spirit of the recent Simple Port Check.

Provide a comma-delimited list of process names (names only, no paths). This plugin checks that at least one instance of each named process is running.


  1. You’ll get an email if any of the processes have NO instances running.
  2. You’ll get another email when any of the non-running processes are present again.

Simple Process Check vs. Process Usage

The Process Usage keeps tabs on one specific process name. It tracks the number of instances running, the total memory usage, number of restarts, etc.

Simple Process Check keeps tabs on multiple processes (according to the list of names you provide), but provides less information on each process. You should use Simple Process Check if you have a number of processes to monitor, and primarily need assurance that they all are running.

Try it out

That link again: Simple Process Check. Let us know if you have any questions or feedback.


New Plugin: Simple Port Check

By Andre Bullet_white Comments Comments

Simple Port Check is, well, simple: give it a list of ports, and it checks that each port will accept a TCP connection.

If the plugin detects that one or more ports stops accepting TCP connections, you’ll get an email notification. When the ports are available again, you’ll get another email:

The link again: Simple Port Check Plugin. Any questions or feedback, feel free to drop us an email.


Monitoring HAProxy

By Derek Bullet_white Posted in Plugins Bullet_white Comments Comments

HAProxy is a rock-solid, high performance TCP/HTTP load balancer. It’s what we use at Scout to proxy traffic to our app servers.

We’ve added a plugin to monitor HAProxy: just specify the URL to your HAProxy stats page and the name of the proxy. You’ll get the request rate, error rate, and proxy status for the specified proxy.

Why monitoring the load balancer is important

The load balancer is one of the best places to narrow down the cause of an outage. If all servers in a proxy aren’t processing requests, it’s often an indication of an outage further down the stack (ex: the database). If it’s isolated to a specific app server, the first place to look might be the downed app server.

The Scout HAProxy plugin gathers its metrics by parsing the output of the HAProxy Status page. It’s one of my favorite open source status pages: the page loads quickly and the color-coded statuses make it easy to focus on problem areas during an incident. The Scout plugin and the HAProxy status page play well together: if the plugin records a dramatic change in the throughput, error rate, or the proxy status, we’ll pull up the HAProxy status page and dig further.

Installation Notes

Like all Scout plugins, installing the HAProxy plugin is just a couple of mouse clicks away. Just click the button in the Scout UI and select the HAProxy Monitoring plugin. Note that the plugin has one dependency: the fastercsv gem must be installed. See the plugin directory entry for more details on the plugin.


A big thanks to Jesse Newland for the initial version of this plugin.


Our poor choice of words: "Server Down" alerts are now "No Data" alerts

By Derek Bullet_white Posted in Updates Bullet_white Comments Comments

What we’ve been referring to as “Server Down Notifications” suffer from two problems:

  • False Positives – The last thing you need is an alert from Scout at 3am telling you that your server is down when it isn’t.
  • An overaggressive email subject – The subject line of these emails looks like “Server is DOWN”. However, this isn’t accurate. We just know that Scout hasn’t received data from this server. That doesn’t necessarily mean the server is down.

We’re making two changes to these alerts:

  • The email subject now states “Server isn’t reporting”. This is really all we know.
  • These alerts used to fire when the agent didn’t report for five minutes. This was overly aggressive. While it doesn’t happen often, things can go wrong between your server and ours that can cause a reporting pothole. Alerts are now sent when the agent hasn’t reported for 30 minutes. It’s important to tell you when monitoring isn’t working, but not important enough to risk sending a false positive because of a short reporting outage.

So, what do we suggest to verify that a server is down? An external monitoring service like Pingdom is a good option. Services like Pingdom can alert you if a server can’t be pinged and/or isn’t accepting SSH/TCP connections. Failed external checks and a lack of internal metrics from Scout often indicate that a server really is dead.

We’re confident (1) keeping our finger off the alarm button a bit longer and (2) calling these alerts what they really are will give you a more comfortable experience. We’re developers too and we know the heartburn a 3am SMS causes.


Making Scout feel young again: our 4-part tonic

By Derek Bullet_white Posted in Development Bullet_white Comments Comments

Scout is no longer a puppy: in dog years, he’s old enough to drink, get drafted, and rent a car. During that time, cruft gathered around the edges of our server infrastructure.

We’ve been using a hodgepodge of server hardware, some performing multiple roles, some not, all individually configured and tuned. Small changes to our stack seemed to involve a lengthy checklist. Our staging environment didn’t mirror production: what happened on staging didn’t always happen on production. Finally, database changes were painful.

We wanted to get lean in the right places: could we make the young adult Scout as easy to manipulate as the baby Scout? 7.weeks.ago we followed a four-part process to get there.

Read More →


Older posts: 1 ... 31 32 33 34 35 ... 68