Monitoring websites with HttpMonitor

Monitoring a website with the HttpMonitor ZenPack is as simple as monitoring any other sort of node, such as a server. With a minimal amount of setup, you can have graphs of page load time, size, alerts on uptime and more for important websites.

Setup

For the simplest case, if you just want to monitor one or more public sites for uptime and basic stats, there are only 4 steps after installing the ZenPack (you can download it here; ZenPack install instructions may be found here).

1. Add a device class

   Navigate to the /Devices class. Using the menu dropdown for Sub-devices, select "Add New Organizer...". A helpful name would be "Web" or "WWW". This is the class you can use for all the websites you want to monitor.

2. Add a device
   

   Click "Add Device". Make the device name the name of the site you wish to monitor, without subdomains, e.g. "mycooldomain.com". Change the Discovery Protocol to none. Change the Device Class Path to "/Web" (or the appropriate name if you decided on something different). You may customize the other fields if desired, this is optional.
   
   Once you click "Add Device", the IP will be found and the device added. If there are problems, be sure the domain you put in as the name can actually resolve on its own. After the device is added, go to zProperties under More in the drop down menu. Change "zSnmpMonitorIgnore" to True. You won't be monitoring your site with SNMP, and this will keep you from seeing errors regarding the agent being down. You should also set "zPingMonitorIgnore" to True for the same reason.
   

3. Create a Performance Template

   You need to create a new Performance Template for your site. It is useful in most cases to create a general Performance Template on the /Devices/Web class, and apply that to devices you add (i.e. each site). Then for special cases, like sites requiring authentication, you can create specific Performance Templates on those devices.
   
   To create the general Performance Template, navigate to the /Web class and click on the Templates tab. Click the drop down menu, then Add Template. A helpful name might be "indexpagechecker", since this Performance Template will be to used to perform the default checks against sites you add.
   
   After it is added, you need to add a data source. Click on the new Performance Template, and click the drop down menu under DataSources. Select Add DataSource, add a name (perhaps "indexpage"), and then select HttpMonitor as the Type. Now you can configure the specific of your datasource. The things to note primarily are Severity and Url. When this check fails, the event added will be of the severity you set, so Error or higher is likely appropriate. The Url is what the check will hit. "/" is default, and this path is appended to the id of the device it is applied to. Thus in the example case, it would hit "mycooldomain.com/". This would be appropriate to monitor your homepage.
   

4. Bind the template

   Now you need to bind your new Performance Template to the /Devices/Web class you added. Navigate to that class, and select the Templates tab. From the drop down, select Bind Templates. Select the Performance Template you just added, and unselect the one that is selected by default (hold CTRL) and hit Ok. This will bind your Performance Template to the class you are currently on, in this case /Devices/Web. The reason you unbind the default is that it monitors uptime with ping, which you do not want for monitoring a website.
   
   Whenever you add a new device under /Devices/Web now, it will inherit the indexcheck Performance Template, and therefore be monitored using HttpMonitor. 

Complications

There are some cases you may encounter which will require some changes in this setup. The most common might be if you are monitoring the webserver that hosts a website and then want to add monitoring for the site as well. If the IP of the server matches the IP of your site (which it would for many setups), you will start seeing errors of a conflict within a few hours of adding the second of them. If your server does not have the same IP as that which your site resolves to (such as if you have load balancing setup between your webservers and requests for your site), you can follow the steps above to add the site independently of the server(s).

If there is a conflict, you can get around it by adding the site monitoring onto the webserver itself. Thus, you would create a new Performance Template similar to the one we made above, except that Host should hard-coded to the domain of your site. You will then bind it only to the webserver for that site, instead of applying to the a class (since the Host will only apply to that one site). You have to change the Host in this way if the name of your webserver device is not the same as your website (e.g. your webserver is "superbox.mycompany.com" and your website is "mycompany.com"). If their names do match, you can copy the Performance Template described in the steps above into /Devices and then bind it to your webserver just as described above in binding it to a site device.

I've got to say that this "Complications" paragraph completely throws me for a loop. I'm in this situation, trying to do what should be the simplest thing in the world: configure zenoss to monitor http on a server, and I run across this paragraph which states this problem which must affect a lot of users, but then doesn't tell me what to do. (How do I add the site monitoring onto the Webserver itself? If I create a new Performance Template similar to the one we made above, where do I put it? How do I bind it only to the webserver for the site? -jdb

Aside from the options from this potential name conflict, however, the Performance Template can otherwise be identical to the one described above. After it is bound to the webserver, you will be able to see the same graphs under Perf as you would if the site were added as a device, get the same alerts, etc.

Graphs

For each HttpMonitor datasource you setup, you can get 2 datapoints:

• seconds taken to perform the test
• size of page loaded

To create a graph of these for a website you have added, once the Performance Template is bound to it and working, go to the Performance Template you added, indexcheck. Click the drop down under Graphs. One you might want to add could be called "ResponseTime". In the graph edit screen, you can select the datasources you want to display. In this case, select "indexpage_time". Add units (seconds) if you wish, then Save.

Now, for any device you add in /Devices/Web (or whichever class you bound the template to), you will have this graph available under the Perf tab. Having page size and load time graphs can be helpful ways to quickly see whether your site is responding slowly for users over time, when, etc.

Adding Thresholds

Aside from just knowing if your site is up or down, it is also helpful to know when it is performing outside of ranges you find acceptable. For example, if your homepage takes around 5 seconds to load, you may wish to set a threshold of 10 seconds. Then you could get alerts when your site is taking abnormally long to load and go find out why.

To add such a threshold, navigate to the Performance Template that you added and bound either to the site device or your webserver (e.g. go to /Devices/Web/mysite.com, and click on the Templates tab, then click on the template you added in the list). In the Thresholds section above Graphs, select Add Threshold. 

Call it something descriptive, like "long_load_time". In configuring this threshold, you will select the time related data source (the name will be indexpage_time, or the name you chose in making the template). You likely do not want to set a min value. For max, select something above the average range of your page load times, but not too extreme. Perhaps twice your average load time would be appropriate, or a value you feel is the most tolerable. The Event Class can be /Status/Web or another class you have made to categorize such events. Warning is a sensible Severity, and other defaults should be fine. Save that, and now whenever your page takes longer than the max, it will throw a warning event.

Next Step: ZenWebTX

In addition to the HttpMonitor Core ZenPack, there is another ZenPack related to web monitoring available for Enterprise customers: ZenWebTX. ZenWebTx extends Zenoss' web monitoring capabilities beyond the simple uptime, load time, and size checks available in the Core version.

With ZenWebTx you can have Zenoss navigate through your entire web application checking for compliance at each step. Multiple timers can be set along the way to measure response time for each operation of the synthetic transaction as well as the total time for the entire transaction to complete.

For more information, please contact our client services team.

Quick Links:

• To find out more about ZenPacks, go here.
• To download HttpMonitor, go here.