Are you a Google Analytics enthusiast?
More SEO Content
Monitoring your server's uptime
Posted 18 October 2003 - 06:12 PM
If you want a free way to monitor your domain to make sure it is reachable, there's at least one site I know of out there which will do it.
They'll send a request to port 80 (that's the one for web pages) every fifteen minutes and send you an email if it goes down. Just make sure you use an email address which is totally separate from your domain or you won't get the notification email if the entire server crashes.
They have a paid version that monitors a lot of other things, but the http monitor is a freebie! Even though I have other monitors set up on all of my servers I also stick this one at one domain on each server. It's always good to have redundancy IMHO.
You'll either be amazed at how good your host's uptime performance is, or severely disappointed. Either way it's a good thing to know.
FYI, as a comparison mine is 99.73% and the only reason it's that low is because I had to turn processes off for most of a late Saturday night a couple of months ago to install some major upgrades while I was applying some security patches. Typically mine is 99.99% uptime, but anything over 98 is considered pretty good.
Posted 18 October 2003 - 07:14 PM
Posted 18 October 2003 - 07:50 PM
I can attest that I've used on-server, inside the network and off-site monitoring with various servers for years, and the "false positive" aspect is a very, very rare one. I honestly cannot remember the off-site monitor ever being incorrect.
Of course for me to ascertain what happened is pretty easy because I've got the additional monitoring resources in place. (The on-server one senses immediately if something goes down, attempts to restart the service and sends a notification if it doesn't restart; The on-network one checks all services every 2 minutes. You don't need that kind of depth unless you run the server.) So it might be easier for me to tell, but you would also be able to take a qiuck peek at your log files to see if everything was perking along just fine when the supposed down time occured.
Posted 18 October 2003 - 07:59 PM
I know that ISPs (or routers?) are generally supposed to reroute traffic so that it gets to its destination. However, on occasion, I haven't been able to get through to sites that were up via my cable ISP while others have (where the domain was not being transferred to a new IP address). Perhaps that's due to severe overload; not sure on my end.
Glad to know that the server monitoring facilities work well. <g>
Posted 18 October 2003 - 08:58 PM
All ISP's are not created equally, nor are all server farms/hosts. So another general statement which applies is: The closer you and/or the remote machine you're trying to reach are to the Tier 1 Network, aka Internet Backbone, the fewer issues you are likely to experience.
Most servers (geez I hate generalities) from reputible hosting firms are very close the Tier 1. A couple of hops, four hops at most. My DSL line on the other hand takes at last 10 hops before I ever get a sniff of a Tier 1. I understand that's pretty typical for most ISP-type connections.
This where my results may vary from others. My servers, by design, sit in a server farm which has multiple incoming trunks from multiple providers, all of which are connected directly to the Tier 1 Network. So one hop away at all times. Even if a line gets cut or a router fails somewhere near the NOC, their switching network usually resolves any reconvergence/latency issues in a matter of seconds. Minutes at most.
Of course not everybody's network is quite like that. So... Disclaimer: You mileage may vary.
Posted 22 October 2003 - 08:29 PM
I think testing from another location is much better than testing from on the server. If you test on the server, you don't know if the connection is down, whereas a third party checking will be more like your average user checking your site.
I would think that the problem of testing a server's uptime from some other location is that there could be inteference (or just plain down time) anywhere in the path from the testing area to the server. Routers, Web traffic, the like could be responsible, whereas the server itself may be up and running as usual.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users