Whilst I’m a fan of using percentages for my disk space checks, sometimes an explicit size is more appropriate. So, you’d expect the following to work nicely:

$USER1$/check_disk -w 5G -c 1G -p /data/foo

If you don’t actually test that this works (by artificially filling your disk and seeing what happens), you may be dismayed to find that you only get alerted when the disk has 5MB of free disk space. Why is this?

Because Nagios, despite the fact that nobody has sweated the megabytes for about a gazillion years, doesn’t support ‘G’ as a suffix for thresholds. Oh, it’ll make a good show of pretending — after all, the output formatting options have ‘GB’ as an option — but nope, for your thresholds it’s “5000M” all the way.

ROCK ON!

We’ve been using Nagios to monitor an ever-increasing number of services on all of the servers that we own at Anchor for a number of years. For the most part the things we monitor have a focus on those that a systems administrator (us in other words) has to deal with. This includes things like CPU load, memory usage, disc space availability, swap usage, server load, availability of core applications such as web servers, data base servers, mail servers. On a given server we typically monitor anywhere from 5 to 25 different attributes.

The end goal of all this monitoring is to ensure that the services on the servers we run are always working.

We can take this a step further though, rather than just monitor the components of the server that are required to keep the websites running, we can monitor in quite detailed ways many of the components of the websites themselves.

At the end of the day, having a monitoring system tell you that a server is healthy and all of the applications are working only goes so far. Ultimately what’s important (to our clients) is that the website is behaving the way that they expect it to.

Since we don’t build any of the websites that we host unfortunately we can’t put in place systems to monitor the innards of an application. To do so requires an intimate knowledge of how the application was built. We do however have a very powerful monitoring system and if the developers of the websites put the hooks into their code, we can monitor these hooks so that both Anchor and the developers can be alerted to the problems.

With these hooks in place, in many cases Anchor will be able to fix the problems, but if we can’t at least we notify the client that there’s a problem (even if it is at 2am in the morning).

In our world, the more monitoring we put in place the greater the uptime of services and the happier our clients are. On this one though, we need our clients’ help. For all Anchor customers on a Fully Managed support pack we do our side of the monitoring free of charge, and for everyone else we can do anything – for a small fee of course.

To help people understand what can be achieved with web application monitoring along with some implementation ideas, we’ve put together this article on website monitoring.