WebART Check
  • 12 Apr 2023
  • 6 Minutes to read
  • Dark
    Light
  • PDF

WebART Check

  • Dark
    Light
  • PDF

Article Summary

Description

A Web Application Response Time (WebART) check monitors the availability and performance of a single, web-based application. These checks are useful for monitoring the efficiency and usability of commonly trafficked paths that might be taken by that application’s users.

A list of all WebART checks and their overall status can be viewed on the Application Monitoring dashboard (Quick Views >> Application Monitoring).

Details

See Create a WebART Check for information about creating WebART checks.

A WebART check loads its specified web application (typically an html web page) and then follows a sequence of steps (called “synthetic checks,” see below) to “use” that application in a way representative of a typical user; optionally interacting with that application by filling out a form and then validating that another web page returned by that form contains a specific string (for example, to determine a successful login attempt by searching for a welcome message). In this way, WebART checks not only monitor the availability of your web applications, but provide performance insights into the user experience for those applications.

WebART and Google
A WebART check will always ignore any Google Analytics code it finds in the target pages during testing.

WebART checks are the most complex of the check types and, in some ways, are actually more similar to a managed device than a type of check—in that they are discreet, manageable objects that get checked for availability and are polled for multiple types of statistical data. The also get their own version of the Device Dashboard called the Application Performance dashboard.

Since WebART checks are not associated with any specific device, they don’t appear in any device-based lists, such as the Devices dashboard. Instead, they appear in application-based lists such as the Application Monitoring dashboard, along with Netreo’s single email application check.

WebART checks report on the basic availability of their target application. But, they also report on and record several performance metrics (any of which can have a threshold check configured for it, just like a device).

Each WebART check can be configured to access their target web application either locally (from the Netreo install location) or remotely (by selecting from a variety of Netreo cloud reflectors located around the world). Using a remote reflector is a good way to get an idea of how your application is performing for users in that region.

The following remote reflectors are available for WebART checks:

  • AP – Seoul
  • AU – Sydney
  • UK – London
  • EU – Frankfurt
  • US – East Coast
  • US – West Coast

When a WebART check is executed, the first thing that happens is that the check’s built-in synthetic browser attempts to load the application (this process performs the availability check). If the application is unresponsive or returns an error code, the check stops and an alarm is generated (the timeout for a WebART check is 10 seconds and cannot be changed). If the application responds properly, the various synthetic check steps are carried out and their response times are measured and recorded.

The total load time for an application does include any associated images and javascript. However, a WebART check will not actually execute any Java or Flash objects if they are present (for security reasons).

For remote (as opposed to local) WebART checks, response times are measured from the selected cloud reflector to the target and back, and exclude the time it takes for Netreo to communicate with the reflector—thus ensuring the most accurate measurement possible.

Each WebART check includes a built-in availability check (configured like a service check) and a threshold check for the application total load time statistic. Additional threshold checks can be added as desired. The following additional statistics are available for monitoring on WebART checks:

  • DNS, TCP and HTTP times for the first synthetic check step.
  • HTTP times for any additional synthetic check steps after the first.

Netreo’s list of WebART checks are run sequentially in a batch (typically, every five minutes). This means that if you have a large number of WebART checks, and one or more bad checks are hanging or waiting to time-out, they may cause the remainder of the checks to fail to execute at all. This will cause any performance graphs for those checks to show no data and any application status indicators for those checks will remain blank. So, be sure to maintain your WebART checks and either fix bad checks or delete them.

The User-Agent request header used by the WebART check’s synthetic browser to load web pages is:

Mozilla/5.0 (Compatible; OmniCenter by Netreo) AppleWebKit/600.6.2 (KHTML, like Gecko) Version/8.0.6 Safari/600.6.2

Synthetic Checks

Synthetic checks are steps in the simulated path of a user. All WebART checks require at least one synthetic check in order for it to have any meaningful functionality. WebART synthetic checks are added and configured to simulate a given path that an end-user might take through your application. This path is then monitored for performance, measuring such aspects as functionality, availability and response time. A WebART check without any synthetic checks will never become active or report anything. Synthetic checks are executed in the order in which they are added, and cannot be reordered. So, it’s best to plan your synthetic checks carefully before beginning.

Web Forms

The first synthetic check step in a WebART check offers the option of filling out a web form. But, only the first step offers that option. Adding the first synthetic check step to a WebART check begins an interactive wizard process that will immediately connect to a user-supplied URL and search that URL for any forms that can be filled out. If any forms are available, Netreo will download them and allow you to select which form (if any) to fill out for the first step. A dialog is then provided where you can specify the exact values for the WebART check to use to fill out that form. The web page that results from filling out and submitting the form can then be validated as correct by searching for strings within the page using a search expression or exact text match (see below). Additional steps can be added to the WebART check (to be executed in sequence) by adding additional synthetic check steps to simulate navigation of the application (for example, navigating a website). This path will then be replicated every time the WebART check runs. If you make your first synthetic check step a login step, you will already be logged in if you do decide to add additional steps; such as following additional links or activating other page functions to see if they are performing as desired. It is important to note that Netreo will only download forms for the first synthetic check step. This means that Netreo cannot log in to sites requiring two-step authentication (i.e. where the username and password are submitted using different forms on different pages).

WebART alert notifications and synthetic checks
Alert notifications sent out for a failed WebART check include a field called “Additional Information” which provides the name of a synthetic check, seemingly implying that this is the point at which the check failed. But, this is not the case. Typically, the synthetic check listed is the last synthetic check to succeed before the failure—although this is not guaranteed to be the case. The information provided in this field merely provides a potential jumping-off point to begin troubleshooting the cause of the failure. It is not intended to be seen as the exact point of failure.

Was this article helpful?