11

I'm wondering if there's avantages of checking if a server is UP by doing a "HTTP GET Request" every second?

Can any server handle it?

2
  • Another option is doing the opposite: rather than monitoring the server from outside, monitor the server from inside, such as with r-u-on.com. You basically install a small script on your server that pings another server very often, so you can monitor your uptime without making life harder for your web server. Commented Apr 3, 2011 at 20:37
  • 3
    @Maxim, there are several problems with your suggestion. First, it doesn't check that the HTTP service is running on the server. Second, there is the problem of what happens when the server itself is down. That still needs to monitored. Besides, the same result could be had by a simple wget against the local machine. Commented Apr 4, 2011 at 8:38

7 Answers 7

26

Can "any" server handle it? Probably.

Should you do it? Probably not.

Ask yourself a few questions:

  1. How fast will you be to respond to an outage?
  2. How many pageviews do you normally receive per second?
  3. How many consecutive errors are you willing to see before calling it "Down" and sending an alert?
  4. Do you have any SLA with internal or external customers that needs to be honored?
  5. Based the questions listed above what seems like a reasonable monitoring and response time?

When I was first learning to program, I decided I wanted to make a stopwatch. When I finally got a working application, I noticed the CPU usage on my laptop was at 100% whenever I ran it.

My execution loop didn't have a wait cycle. It just kept executing over the time function.

On that day I learned a valuable lesson: there is no such thing as an infinitely accurate measurement.

6

While I, like just about everyone else, question the reason for wanting to monitor so frequently the technical side is a non-issue. One GET request every second is absolutely trifling compared to a typical page load.

Can your server handle it? We have nothing upon which to answer such a question but if your server has an issue handling it then I would suggest it would be completely inadequate for whatever else it's serving.

3

Nagios or munin can probably handle running the test every second but it's a bit obsessive. Is there a reason you need to check so frequently? If your server is that unstable you probably have deeper problems.

1

Most commercial monitoring software offer 1-min or 5-min interval by default. That seems to be a good check interval.

3
  • Pingdom, for instance, allows you to set an interval and then on detecting the first outage, increase the frequency at which it pings the server to see if it's back up. Commented Apr 3, 2011 at 20:47
  • >, increase the frequency ..=> but minimum is still 1 min, or?
    – sapguy
    Commented Apr 3, 2011 at 20:56
  • On free accounts I think the lowest that Pingdom offers is 1 minute. I don't have a premium account so I cannot say whether they offer an option for even more frequent checks for them. Commented Apr 3, 2011 at 22:00
1

There's nothing wrong with monitoring the server every second, it's just not very efficient especially on servers with high load where an Apache query may hang for a couple of seconds causing your requests to either backup, or issue false alerts for that particular moment, but it's not 'wrong'. One second checks won't make you any faster at responding, and in 99.9% of all circumstances, a 10 or 30 second check is just as important.

0

I agree 100% with Joseph here. If you still want to do some sort of real-time monitoring you could consider sniffing the webserver log for both server errors and absence of new entries in the log for a period of time. It won't put a load on the server, but triggering alerts based on this is a challenge :)

0

1 second resolution is really high and probably not needed. However I prefer collectd as it was designed for much higher resolution (ever 10 seconds) then other OSS tools like munin (5 minutes).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .