I am thinking of a strategies to monitor a web service hosted at http url. I want to be able to know if it is up or down. I am aware of polling but wondering if there are any other non obvious strategies.
closed as not constructive by Michael Hampton♦, John Gardeniers, Ward, Scott Pack, HopelessN00b♦ Oct 30 '12 at 14:06
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
I've given this quite a bit of thought recently and I came to the conclusion that some form of polling is the only reliable method of determining if a system is running. When thinking this through, I found it useful to consider how you'd track the well-being of an elderly relative who lives alone, some distance away.
I can think of three options:
Options 2 and 3 are both variations on polling. The only difference is who initiates the request; but either option would work. Option 1 is an event-driven notification. This is the most efficient kind of notification because the relative will receive immediate help. But, if they've had a bad fall and knocked themselves out they won't be able to raise the alarm and it could be days before anyone notices.
Based on this, I believe the best choice is to use event-driven notification where possible but use some form of polling as a reliable fallback. Whichever method of polling is used, it must be obvious when the polling mechanism itself fails. It would not be good if the system you use for polling the web service has gone down and you haven't realised.
In the system I'm responsible for, which comprises a number of web pages and webservices, we use a mixture of event-driven notification and polling. Whenever an error or other noteworthy event occurs in the system, an email is sent to my inbox. But we don't rely on this to inform us of all issues. If we did and there was a problem with the error reporting process, or a network connectivity problem, we would never hear about it. To cover these types of problem, we use polling.
We decided to write our own monitoring solution which polls all critical services every few seconds. If no response is received within the expected timeout period, or the response arrives but is not as expected, the system alerts one of our staff. The system will send emails to key staff and also communicates the current status of all systems via its "information radiator"/"big visible chart" type of display.
Here's one of the information radiators we have in our office which provides an always present indicator of our critical services' availability and performance:
The display is situated in a prominent location in our office to ensure we'd know if it wasn't monitoring.
Last month we released the system, called ServiceMon, as open source under the GPL license.
ServiceMon is configured using a very simple script. Here's an example of how you'd monitor a web page:
You can also use this approach to monitor stateless, REST-based services. There's an example here
If you need to monitor a SOAP-based web service, you'll need to create a simple plugin. This article I wrote for CodeProject has a section towards the end that explains what's involved.
Ideally, your system will be designed from the ground up with monitoring in mind, and will hopefully expose status and diagnostic information via security-controlled methods (which may need to be restricted for internal use).
I hope this helps your situation and I'd be really interested to hear what option you end up using.
For more information about ServiceMon, please visit the project's homepage