Currently for the RapidSpike Uptime Monitoring Service you have the option to add one of three types of uptime monitors.
Lets take a brief look at the three and the differences between them and usage scenarios for each one.
These three types are Ping Monitor, TCP Monitor, and HTTP Monitor.
A Ping Monitor is the basic networking level monitor offered by RapidSpike. Ping uses the ICMP protocol to check the network reachability of the network device you are checking. This works at a low level and tells you that the device is there and has power to the network interface. Just because something returns a ping, it is not a true indication that the service on the device is running but it does help in troubleshooting so definitely one to use if you can enable it within your account.
One issue with Ping is that some Internet firewalls will block ping traffic reaching the network. It is common for TCP and HTTP monitors to work fine but the ping monitor fail so be sure to be mindful of this and be sure to disable it if this is the case.
Be sure to check out the Wikipedia entry for Ping.
The next level of monitor is the TCP Monitor. If we can ping a device we know it is connected to the network, the next level up is to check that the services are running on the device. All common applications run on a network device on what is called a port. These are either TCP or UDP ports. Currently RapidSpike only support TCP port monitors but it is planned to include UDP monitors in the future.
By enabling a TCP Monitor you are checking that the service is running on the network device. For example, all websites are hosted on what is called a web server. These web servers default to running on TCP Port 80. So, if we set up a TCP Monitor on Port 80 we are checking that the web server service is running on the network device.
There is a list of commonly used port numbers for both TCP and UDP and this can be used to configure a TCP Monitor for most applications that would run on a network device.
Be sure to check out the Wikipedia entry for TCP.
The last, and highest level of monitor is the HTTP Monitor. This monitor is checking for the existence of pages for your monitored website. The monitor work by looking at the HTTP Response Code for the configured page. If a page exists, the web server will return a status code of 200, which means OK. This is a simple check to ascertain if a page exists on a website.
it is advisable to check every page on your website (within reason if it is a database driven site) and also to check for the existence of other items such as your favicon.ico or your custom 404 page.
At this level you can also add what is called a Content Check. This extra level of complexity not only check the correct response code but also checks that some text is shown on the page. This is very useful for checking that everything is working by checking for the existence of some text that you know should be visible on a specific page.
So, three monitor types, Why would I use them all?
Well, one benefit of configuring a ping, TCP and HTTP monitor for your website is that it provides depth in troubleshooting in the event of an error. For example, if your Ping and TCP monitors are passing but your HTTP monitors are failing then this is probably a configuration error on the web server that is preventing your pages from being displayed.
If only the ping monitor is responding then the web server may have crashed on your network device. If the Ping monitor goes down (and presuming it was not initially blocked) then it is normally an indication that there is a total server outage or something between you and the server totally blocking your access.
One other use is looking at the response times from the network, the server and the application. With this information you can ascertain if there is a performance issue and identify which part of your infrastructure is causing the issue.
Tying all of this together with a User Journey Monitor provides a total end to end solution for managing your web performance.