Currently, for the RapidSpike Uptime Monitoring Service, you can add one of three types of Uptime monitors: Ping Monitor, TCP Monitor, and HTTP Monitor.

Let’s take a brief look at the three and the differences between them and the usage scenarios for each one.

Ping

A Ping Monitor is the basic networking level monitor offered by RapidSpike for any network device (generally servers). Ping uses the ICMP protocol to check the network reachability of the device you are checking. At a low level, this tells you that the device is there and has power to the network interface. Responding to a ping request is not a full indication that the service on the device is running but allows you to troubleshoot any issues.

One issue with Ping is that some Internet firewalls will block Ping traffic from reaching the network. It is common for TCP and HTTP monitors to work well, whilst the ping monitor fails.

Be sure to check out the Wikipedia entry for Ping.

TCP

The next level of network device monitor is the TCP Monitor. If we can ping a device, then we know that it is connected to the network. The next level involves verifying our ability to access the desired services.

All services that run on a network device are accessible via ports. We can communicate with ports using either TCP or UDP – RapidSpike supports TCP port monitors.

By enabling a TCP Monitor you are checking that a service is accessible on a given port on the network device. For example, all websites are hosted using a web server service. These services default to being accessible on ports 80 (non-secure) or 443 (secure). So, if we set up a TCP Monitor on port 80 we are checking that the web server service is accessible on the network device via TCP.

There is a list of common port numbers for both TCP and UDP and we can use these to configure a TCP Monitor for most services that would run on a network device. Be sure to check out the Wikipedia entry for TCP.

HTTP

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 add a Content Check. It has an extra level of complexity because an HTTP monitor checks the correct response code but can also check for text on the page. This is very useful for checking that someone on your page is working as expected.

Why would I use them all?

One benefit of configuring a ping, TCP and HTTP monitor for your servers and websites is that it provides in-depth troubleshooting in the event of an error. For example, if your Ping and TCP monitors setup on your web hosting server 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 or there may be a firewall rule preventing access. 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 us and the server totally blocking access.

Another 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 problem. Tying all of this together with a User Journey Monitor provides a total end-to-end solution for managing your web performance.