Come join our live training webinar every other Wednesday at 11am PST and hear LogicMonitor experts explain best practices and answer common questions. We understand these are uncertain times, and we are here to help!
Web checks periodically make HTTP GET, HEAD or POST requests to one or more URLs. LogicMonitor supports two types of Web Checks:
The processes for creating standard Web Checks and Internal Web Checks are largely identical. This support article covers the creation of both types of checks, but will identify where configurations diverge, notably when building URL requests and identifying checkpoint locations.
Note: For information on the type of data that is monitored for your configured Web Checks and how that data is organized on the Websites page, see What Is Website Monitoring?.
To begin the creation of a new Web Check, select Websites | Add | Web Check or Websites | Add | Internal Web Check, depending upon whether you want the tests to be performed from locations external or internal to your network. In the Add dialog that opens, there are several pieces of basic information that must be provided, as shown (and discussed) next.
Note: Web Checks can also be added using LogicMonitor’s API; see Using LogicMonitor’s REST API for more information.
In the Name field, enter a descriptive name for your new Web Check.
In the Description field, briefly describe the scope and purpose of your new Web Check.
From the Website Group field’s dropdown menu, select the group that the Web Check should belong to from the list of existing groups. By default, the root (top-level) website group is selected.
From the dropdown menu, select “http://” or “https://” depending on your web server settings. Then, enter the website domain to which your Web check request will be sent.
For every Web check, you will configure at least one URL path, along with the corresponding request and response settings for that URL path. As discussed in a later section, additional URL paths (and their corresponding request and response settings) can be added, but only after the configurations for the first URL path have been saved.
In the Step One URL Path field, enter the first path that should be tested for your website. Enter the path relative to the website domain (e.g. “/folder/page.htm”). As discussed in a later section, additional paths can be added, but not until after configurations for the first path have been saved.
From the Request area of the Add dialog, we come across the first difference in configurations between creating standard Web Checks and creating Internal Web Checks:
Note: Script settings are not discussed in this support article; if you would like to use a Groovy script to execute your Internal Web Check, see Executing Internal Web Checks via Groovy Scripts for detailed script information, instructions, and examples.
For standard Web Checks (or Internal Web Checks that aren’t executed via a Groovy script), there are several HTTP request settings that must be completed for the URL, as shown (and discussed) next.
Note: If you are testing a path that uses form-based authentication, there are browser tools you can use to identify what information (and formatting) you will need to include in your request. For more information on using these tools, see Web Checks with Form-Based Authentication.
For the HTTP Version field, select the version of HTTP that should be used to make the request: 1.0 or 1.1. The version you select is based on your website’s settings.
Note: You can determine this setting in the response headers using the Linux/Unix cURL command (e.g. curl –head help.logicmonitor.com).
For the Method field, select the HTTP method that should be used to make the request: GET, HEAD, or POST.
If you select the POST option, additional configurations display that allow you to specify the data (and whether or not it’s formatted) to be included in request payload. Additionally, as shown in the previous screenshot, if you select the Formatted Data option, one more configuration displays that allows you to specify which format.
Note: As discussed in Web Checks with Form-Based Authentication, there are browser tools you can use to identify what information you will need to include in your request and what format it should be in.
If the Follow redirect option is checked, the HTTP request will follow any redirects configured for the URL.
If the Wait for all page elements to load option is checked, the HTTP request will wait for all page elements to load before checking the response.
For requests that are going to a page that requires either HTTP Basic authentication or NT LAN Manager (NTLM) authentication, check the Authentication Required option to have LogicMonitor construct the authentication headers for you. As shown next, additional configurations display that allow you to specify the type of authentication (along with authentication credentials) that will be used in the HTTP request.
Note: If the website uses form-based authentication, you can optionally add steps to the Web Check that POST the username and password values. For examples of setting up a Web check with form-based authentication, see Web Checks with Form-Based Authentication.
From the Auth type field’s dropdown, select the type of authentication used by the page:
In the Username and Password (and optionally Domain if using NTLM authorization) fields, enter your authentication credentials.
In the header table, click the + button to add any header key-value pairs that should be included in the HTTP request.
Like the Request area of the Add dialog, the Response area also features a Groovy scripting option for Internal Web Checks only. (Script settings are not discussed in this support article; if you would like to use a Groovy script to execute your Internal Web Check, see Executing Internal Web Checks via Groovy Scripts for detailed script information, instructions, and examples.)
For standard Web Checks (or Internal Web Checks that aren’t executed via a Groovy script), there are several HTTP response settings that must be completed for the URL, as shown (and discussed) next.
From the HTTP Response Format field’s dropdown, select the format that the response to the HTTP request will come in. The fields immediately below this field will dynamically update based on your selection to allow you to specify format-specific criteria that should be included in (or absent from) the response. If relying on the presence of a string, note that the entry is case-sensitive.
In the Expected status code response field, enter the expected HTTP status code(s) that will be included in the response. Enter only integers. Multiple status codes should be separated by commas. If no status is specified, a 200/OK response is expected.
If you choose “XML” as the response format, it’s important to note that Xpath processing does not support regular expressions. In order to find string matches in the page’s returned XML, you’ll need to use the contains query, as shown in the following screenshot. This query returns TRUE if the string is present. (A useful tool for testing Xpath queries can be found at freeformatter.com.)
When you add a new Web Check, at least one URL path (called the Step One URL Path), must be specified, along with its corresponding request and response settings. However, multiple steps can be added to the same Web Check in order to support more complicated checks that require a series of URL requests and responses in order to verify that a website is in full working order.
As shown next, additional steps are added after the initial Web Check is saved, from the Steps tab.
Click the Add Step button and enter a path (either relative to the root URL previously established for the Web Check or independent from) and a description for this additional step into the Add a Step dialog. Then, proceed to configure request and response settings as outlined in this support article.
Each step you add is saved individually and available for management and testing from the Steps tab. For more information on testing steps, see Testing Web Check Steps.
In the Checkpoints section of the Add dialog, specify the locations from which Web Checks should be sent. As discussed in the following two subsections, the types of locations that are available here vary depending upon whether you are adding a standard Web Check or an Internal Web Check.
Note: If your Web Check consists of multiple steps (i.e. multiple URLs or paths that must be tested in succession), the checkpoints configured here apply to all of these steps.
Note: If you have default checkpoints established and want to use or build on those, leave the use default Website settings option checked. For more information on configuring default Website settings, see Website Default Settings.
If you are adding a standard Web Check, there are five geographically dispersed checkpoints, hosted by LogicMonitor, from which the check can be sent.
When you have finished selecting the external locations from which your checks will originate, click the Test button to verify that the selected locations can successfully reach your website.
If you are adding an Internal Web Check, you will need to specify the Collectors that will be sending the checks. Click the + button to add Collectors to the table, as shown next.
Note: As discussed in Roles, your user account must, at a minimum, have Collector view permissions in order for you to be able to view and select Collectors from this area of the dialog.
In the Alert Triggering section of the Add dialog, you will specify the conditions that must be met in order for a website alert to be triggered, as well as the severity of the resulting alert(s). There are several fields that require configuration in this section, as shown (and discussed) next.
Note: If your Web Check consists of multiple steps (i.e. multiple URLs or paths that must be tested in succession), the alert triggers configured here apply to all of these steps.
Note: If you have default alert triggering settings established and want to use or build on those, leave the use default Website settings option checked. For more information on configuring default Website settings, see Website Default Settings.
From this field’s dropdown menu, select how often the designated checkpoints will check the website. You can choose from frequencies that range from once a minute to once every 10 minutes.
In this field, specify how many milliseconds in which the website must load.
From this field’s dropdown menu, select the number of consecutive checks that must fail in order for an alert to be triggered.
This field piggybacks on the previous field. It gives you the ability to designate a different alert severity should checks from multiple checkpoints fail, as compared to the failure of just one checkpoint. For example, as shown in the previous screenshot, you could specify that if all checkpoints report failure for three consecutive checks, an alert with the severity level of critical will be triggered.
This field also piggybacks on the After (X) failed checks: field. It gives you the ability to designate a different alert severity should checks from only one checkpoint fail, as compared to the failure of multiple checkpoints. For example, as shown in the previous screenshot, you could specify that a failure at a single checkpoint location for three consecutive checks will trigger an alert with the severity level of warning. Additonally, using individual checkpoint alerts allows for greater request/response detail in the alert messages, since it is not simply a summarization of all checkpoints.
In the SSL Alerts area of the Alert Triggering section, you can configure LogicMonitor to alert you when SSL certificate issues are encountered during a Web Check.
When checked, the Alert on SSL Errors option will trigger alerts if a certificate experiences any of the following issues:
If any of the above bulleted issues are encountered and the Halt on SSL errors option is also checked, the Web Check will stop and fire the alert without continuing.
You can also choose to get proactive notification of certificate expiration. Check the Alert on Certificate Expiration option and, for each alert severity level, enter the number of days in advance of expiration in which you would like to receive a corresponding alert.
Once you’ve configured the conditions that must be met in order for a website alert to be triggered, you can use the Test Routing hyperlinks to see what alert rule will match each condition, along with the escalation chain associated with that alert rule.
From the test display, the Test Now button can be used to send a synthetic test notification to the first stage in the specified escalation chain.
Note: Synthetic alert messages use LogicMonitor’s default global alert message templates. Any customizations such as addition of alert tokens will be ignored during testing. You must use a live alert to test customizations. For more information on alert message templates, see Alert Messages.
For more information on alert rules and their associated escalation chains, see Alert Rules.
Properties can be added to your Web Checks to facilitate organization, customize alert message templates, set authentication credentials, and more. For more information on adding and using properties, see Website Properties.
In This Article