How many pageviews do
you normally receive per second?
How many consecutive errors are you
willing to see before calling it
"Down" and sending an alert?
Do you have any SLA with internal or external customers that needs to be honored?
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.
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.
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.
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.
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 :)
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).
Can "any" server handle it? Probably.
Should you do it? Probably not.
Ask yourself a few questions:
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.
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.
Most commercial monitoring software offer 1-min or 5-min interval by default. That seems to be a good check interval.
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.
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 :)
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).