The Cloud Service & Website Monitor allows you to monitor the availability and response of a website without having to install an agent on the web server. This is particularly useful for sites hosted externally by web hosting providers, who may not allow access to the underlying servers.
The website URL is monitored from one or more devices that have a Naverisk agent installed. This can be either a standard or advanced agent. The monitor measures the site response time, and is also able to test for specific text being returned from the server. By monitoring remotely, you can measure the real-world response time, including the effect of network and internet speed between the web server and monitoring device. By monitoring a URL from multiple devices, you add redundancy to the monitor, and measure performance from different locations.
Creating a monitor
To monitor a website, a Passive Device must be added to the appropriate client. From the Devices tab, select New Device then click Create New Passive Device. Enter the device information as required then save.
The monitor then needs to be configured on a suitable device. This device can be on the same client as the passive device created above, or under a different client if required.
From the Monitoring tab, under Monitored URIs: select Add.
2. Enter the website URI, making sure the correct protocol is selected. The URI can be set to any available page on the site.
3. Under Device, choose the Passive Device created above
4. Set the other fields as required.
Searched Text: This is used to test for text returned within the tested web page. Setting this to text that you would see if the page is working correctly will allow the monitor to tell if the page is returning valid content or an error message. You can either test for content that should or should not be present.
Threshold: An alert will be generated if the website does not respond within the configured time, allowing you to check for degraded performance.
Interval: The intermittence at which the website will be monitored. (e.g., every 300 seconds. See screenshot below.)
Failure threshold: The number of consecutive failed polls before an alert is raised. This can be set to a higher number to prevent occasional slow responses etc from creating alerts unnecessarily.
SLA Class: The desired classification. This would typically be set to Performance or Availability
SLA Status: The required SLA status severity used when an alert is created
SLA Trigger Text: Optional text added to the ticket trigger field when an alert is created. This can provide additional information or details about the alert.
Once the required fields have been completed, click save. Note that multiple URI monitors can be added to a device.
You will also need to save the OS template on the device so that the monitor is added.
Adding a monitor to an OS template
In addition to manually adding a Monitored URI to an individual device, you can also add one or more monitors to any OS Template.
Under Settings, got to OS templates and edit the required template. You can also copy an existing template or create a new one.
You can add a URI monitor under the Availability section. The monitor is configured in the same way as above. Once the template is saved, the URI monitor will be added to all devices currently using the template. when adding a URI monitor to an OS template, consideration should be given to the number of devices using that template, to prevent a large number of devices all monitoring the website and creating excessive load.
Further details on using OS templates can be found in the Knowledge Base.
Viewing Monitor Details
By opening the Passive Device created for the monitor, you can view tickets created by the monitor, and see the devices that the monitor is run from.
Advanced concepts
Monitoring dynamic web pages
Many websites use dynamic pages driven by a back-end database. These can include catalogs, shopping cart sites, searches, blogs and forums. By referencing a dynamic page in the monitor, you can verify that the database and back-end code are performing correctly, however as the page is dynamic it can be difficult to search for specific text as it may not appear over time. For example, on a blog, if you are searching for text in a specific post, as new posts are added, the one with the text may eventually not be shown on the main page.
In many cases, we can request the specific article, post or other data within the URL. A typical example would look like:
Other sites may use what looks like a static URL (eg blogs) however the content is still fetched dynamically. Regardless of the method, by copying the specific dynamic page URL into the monitor will always return the expected page.
Using multiple monitors on one site
By configuring multiple monitors for one website, you can create more granular monitoring. Some examples include:
Different SLA Statuses. By creating monitors set to different threshold times, you can create alerts of increasing severity depending on how slow the site is responding
Testing multiple pages in on a site. Create a monitor for each page required. Different threshold times could be created depending on the complexity/size of a page or whether it is static or dynamic
Test for specific errors. By searching for a specific error message in each monitor (using the not-equal-to option), a separate alert will be raised for each error condition. The SLA Trigger Text field can be used to provide details of the error.
Monitor performance across distributed locations. By creating monitors on devices in multiple physical locations, the website performance can be verified from different networks/internet connections. This also provides monitoring redundancy.
Some Important Notes
Note there is no URI monitoring in Linux/Mac device.
All devices that hold the results need to be newly created Passive Devices
In the Monitored URI window , Searched text equal ( = ) to reads like : " If the text entered in the field is no longer showing in the website create a ticket. "
In the Monitored URI window , Searched text not equal ( ≠ ) to reads like : " If the text entered in the field is visible in the website create a ticket. "
In the Monitored URI window , threshold is total time it waits for the page to respond before it creates a ticket - unless the device accessing the page and the page is really fast , set this to a few seconds ( t x 1000 ms).
In the Monitored URI window , Interval is the time gap it takes before it polls the website again. So e.g. if you set it at 5s , it checks again after 5s.
In the Monitored URI window , Failure Threshold is the number of times it can fail (website did not respond) before it creates a ticket.