Monitoring Your Colocation (Part 2)

Monitoring Performance

Somewhat different than usage monitoring, performance monitoring is concerned with how well various functions of your colocation respond to demand. Performance monitoring can generally be broken down into systems performance monitoring and network performance monitoring. Systems performance monitoring would include monitoring of your servers, storage devices, applications and other pieces that form the functional core of your colocation. Network performance monitoring would include the IP connectivity to your systems (i.e. carrier bandwidth), but could also include any network hardware that you may have provided, such as routers or switches.

Performance monitoring is most commonly done from the perspective of your end-users – so if your colocation is serving web content, performance monitoring would be concerned with factors such as how quickly the content is served to the end user,  how well the server handles multiple simultaneous requests, the speed at which your systems look up and serve info from databases, files, etc. This is most commonly accomplished by tools which perform various tests against the WAN (Wide Area Networkj) side of your colocation, as opposed to internal testing. As you might expect, degraded system performance could create the appearance of poor network performance, where in fact the network is operating fine – and this is among the reasons that both network and system performance must be monitored.

Spiceworks server monitoring tracks data on CPU, RAM, storage and more.
Spiceworks server monitoring tracks data on CPU, RAM, storage and more.

As with usage monitoring, there are a variety of tools at your disposal to accomplish your performance monitoring goals. Spiceworks, the popular free support portal/forum, offers a free solution that incorporates both network and server performance monitoring. A similar free service is offered by, as a gateway to their premium (paid) services. There are many other 3rd party hosted solutions, both free and paid – and there are a number of self-hosted solutions as well. However, there are strong arguments to made against hosting your performance monitoring solution yourself, or at least against hosting it on the same equipment that is being monitored. While server performance monitoring tools can be effectively run locally on the servers being monitored, this requires multiple instances of the monitoring tool, each installed locally on the monitoring target – more work and more management than one central monitoring platform. Even if you go with a self-hosted, centralized monitoring solution that connects to all of your servers and monitors your network as well, it really should be hosted somewhere else versus on the installation that is being monitored, in order to guarantee maximum availability and accurate data. If you do decide to host your own monitoring, Solarwinds has carved quite a niche for itself in this area, with a range of (paid) monitoring tools for just about every need.  On the free side, the previously-mentioned Zabbix offers some server and application monitoring features, and OpenNMS is a popular tool which is focused on availability and performance.

Monitoring Uptime

Our final topic, monitoring uptime, is perhaps the most critical of all monitoring tasks. Fortunately, it is also among the easiest to implement.

Uptime monitoring is simply concerned with one thing: are your systems online, or offline? The target(s) of uptime monitoring can be an IP address, a website, an application, a server, a network device, a complete system, or any combination thereof. Uptime monitoring of any given target can typically be accomplished with one or more tests, from the simple ‘ping’ (checking an IP address for reach-ability), to http/https response tests and beyond. Once configured, uptime tests are run against targets at regular intervals (every five minutes has become a de facto standard, but almost any frequency can be defined). Uptime monitoring systems may be configured to trigger any number of events once a test results in an “offline” result: test retries, alternate tests, and alerts can all be defined outcomes.

Of the three types of monitoring discussed in this topic, uptime monitoring is the service that you’ll want to obtain from a 3rd party provider that specializes in monitoring services. Such providers typically use a cloud architecture which allows your target to be tested from multiple remote points at once – an “offline” condition only results when the test fails from all monitoring stations. This helps to rule out any isolated temporary issues (i.e. carrier network congestion) that can create a false positive when a single monitoring station is being used.

Uptime monitoring services will also store logs of historical performance, with date and time stamps for every event, as well as overall uptime ratings for your monitored points. This information can be useful for evaluating the performance of your colocation as well as the services from your provider.

Uptime monitoring has been around nearly as long as the World Wide Web, so you’re greatest challenge will be choosing from a cornucopia of providers. If your needs are modest, free offerings from StatusCake, UptimeRobot, or any number of alternative free service providers may fill the bill. If your requirements go beyond the capabilities of a free account, Pingdom or SiteUptime would be among the many choices you have for premium service.