Table of Contents
8. Web monitoring
Overview
With Áú»¢¶Ä²© you can check several availability aspects of web sites.
To perform web monitoring Áú»¢¶Ä²© server must be initially configured with cURL (libcurl) support.
To activate web monitoring you need to define web scenarios. A web scenario consists of one or several HTTP requests or "steps". The steps are periodically executed by Áú»¢¶Ä²© server in a pre-defined order. If a host is monitored by proxy, the steps are executed by the proxy.
Since Áú»¢¶Ä²© 2.2 web scenarios are attached to hosts/templates in the same way as items, triggers, etc. That means that web scenarios can also be created on a template level and then applied to multiple hosts in one move.
The following information is collected in any web scenario:
- average download speed per second for all steps of whole scenario
- number of the step that failed
- last error message
The following information is collected in any web scenario step:
- download speed per second
- response time
- response code
For more details, see web monitoring items.
Data collected from executing web scenarios is kept in the database. The data is automatically used for graphs, triggers and notifications.
Áú»¢¶Ä²© can also check if a retrieved HTML page contains a pre-defined string. It can execute a simulated login and follow a path of simulated mouse clicks on the page.
Áú»¢¶Ä²© web monitoring supports both HTTP and HTTPS. When running a web scenario, Áú»¢¶Ä²© will optionally follow redirects (see option Follow redirects below). Maximum number of redirects is hard-coded to 10 (using cURL option ). All cookies are preserved during the execution of a single scenario.
See also known issues for web monitoring using HTTPS protocol.
Configuring a web scenario
To configure a web scenario:
- Go to: Configuration → Hosts (or Templates)
- Click on Web in the row of the host/template
- Click on Create scenario to the right (or on the scenario name to edit an existing scenario)
- Enter parameters of the scenario in the form
The Scenario tab allows you to configure the general parameters of a web scenario.
General parameters:
| Parameter | Description |
|---|---|
| Host | Name of the host/template that the scenario belongs to. |
| Name | Unique scenario name. Starting with Áú»¢¶Ä²© 2.2, the name may contain supported macros. |
| Application | Select an application the scenario will belong to. Web scenario items will be grouped under the selected application in Monitoring → Latest data. |
| New application | Enter the name of a new application for the scenario. |
| Update interval (in sec) | How often the scenario will be executed, in seconds. |
| Attempts | The number of attempts for executing web scenario steps. In case of network problems (timeout, no connectivity, etc) Áú»¢¶Ä²© can repeat executing a step several times. The figure set will equally affect each step of the scenario. Up to 10 attempts can be specified, default value is 1. Note: Áú»¢¶Ä²© will not repeat a step because of a wrong response code or the mismatch of a required string. This parameter is supported starting with Áú»¢¶Ä²© 2.2. |
| Agent | Select a client agent. Áú»¢¶Ä²© will pretend to be the selected browser. This is useful when a website returns different content for different browsers. User macros can be used in this field, starting with Áú»¢¶Ä²© 2.2. |
| HTTP proxy | You can specify an HTTP proxy to use, using the format: http://[username[:password]@]proxy.mycompany.com[:port] By default, 1080 port will be used. If specified, the proxy will overwrite proxy related environment variables like http_proxy, HTTPS_PROXY. If not specified, the proxy will not overwrite proxy related environment variables. The entered value is passed on "as is", no sanity checking takes place. You may also enter a SOCKS proxy address. If you specify the wrong protocol, the connection will fail and the item will become unsupported. With no protocol specified, the proxy will be treated as an HTTP proxy. Note: Only simple authentication is supported with HTTP proxy. User macros can be used in this field. This parameter is supported starting with Áú»¢¶Ä²© 2.2. |
| Variables | List of scenario-level variables (macros) that may be used in scenario steps (URL, Post variables). They have the following format: {macro1}=value1 {macro2}=value2 {macro3}=regex:<regular expression> For example: {username}=Alexei {password}=kj3h5kJ34bd {hostid}=regex:hostid is ([0-9]+) If the value part starts with regex: then the part after it will be treated as a regular expression that will search the web page and, if found, store the match in the variable. Note that at least one subgroup must be present so that the matched value can be extracted. The macros can then be referenced in the steps as {username}, {password} and {hostid}. Áú»¢¶Ä²© will automatically replace them with actual values. Having variables that search a webpage for a regular expression match is supported starting with Áú»¢¶Ä²© 2.2. HOST.* macros and user macros can be used in this field, starting with Áú»¢¶Ä²© 2.2.Note: Variables are not URL-encoded. |
| Headers | HTTP headers that will be sent when performing a request. Headers should be listed using the same syntax as they would appear in the HTTP protocol, optionally using some additional features supported by the cURL option. For example: Accept-Charset: utf-8 Accept-Language: en-US Content-Type: application/xml; charset=utf-8 HOST.* macros and user macros can be used in this field.Specifying custom headers is supported starting with Áú»¢¶Ä²© 2.4. |
| Enabled | The scenario is active if this box is checked, otherwise - disabled. |
Note that when editing an existing scenario, two extra buttons are available in the form:
 |
Create another scenario based on the properties of the existing one. |
 |
Delete history and trend data for the scenario. This will make the server perform the scenario immediately after deleting the data. |
If HTTP proxy field is left empty, another way for using an HTTP proxy is to set proxy related environment variables.
For HTTP checks - set the http_proxy environment variable for the Áú»¢¶Ä²© server user. For example, //http_proxy=.
For HTTPS checks - set the HTTPS_PROXY environment variable. For example, //HTTPS_PROXY=. More details are available by running a shell command: # man curl.
The Steps tab allows you to configure the web scenario steps. To add a web scenario step, click on Add.
Configuring steps
Step parameters:
| Parameter | Description |
|---|---|
| Name | Unique step name. Starting with Áú»¢¶Ä²© 2.2, the name may contain supported macros. |
| URL | URL to connect to and retrieve data. For example: http://www.zabbix.com https://www.google.com GET variables can be passed in the URL parameter. Starting with Áú»¢¶Ä²© 2.2, this field may contain supported macros. Limited to 2048 characters starting with Áú»¢¶Ä²© 2.4. |
| Post | HTTP POST variables, if any. For example: id=2345&userid={user} If {user} is defined as a macro of the web scenario, it will be replaced by its value when the step is executed. The information will be sent as is, variables are not URL-encoded. Starting with Áú»¢¶Ä²© 2.2, this field may contain supported macros. |
| Variables | List of step-level variables (macros) that may be used for GET and POST functions. Step-level variables override scenario-level variables or variables from the previous step. However, the value of a step-level variable only affects the step after (and not the current step). They have the following format: {macro}=value {macro}=regex:<regular expression> For more information see variable description on the scenario level. Having step-level variables is supported starting with Áú»¢¶Ä²© 2.2. Note: Variables are not URL-encoded. |
| Headers | HTTP headers that will be sent when performing a request. Headers should be listed using the same syntax as they would appear in the HTTP protocol. Headers on the step level will overwrite the headers specified for the scenario. For example, 'User-Agent:' with no data will remove User-Agent set on scenario level. HOST.* macros and user macros can be used in this field.This sets the cURL option. Specifying custom headers is supported starting with Áú»¢¶Ä²© 2.4. |
| Follow redirects | Mark the checkbox to follow HTTP redirects. This sets the cURL option. This option is supported starting with Áú»¢¶Ä²© 2.4. |
| Retrieve only headers | Mark the checkbox to retrieve only headers from the HTTP response. This sets the cURL option. This option is supported starting with Áú»¢¶Ä²© 2.4. |
| Timeout | Áú»¢¶Ä²© will not spend more than the set amount of seconds on processing the URL. Actually this parameter defines maximum time for making connection to the URL and maximum time for performing an HTTP request. Therefore, Áú»¢¶Ä²© will not spend more than 2 x Timeout seconds on the step. For example: 15 |
| Required string | Required regular expressions pattern. Unless retrieved content (HTML) matches required pattern the step will fail. If empty, no check is performed. For example: Homepage of Áú»¢¶Ä²© Welcome.*admin Note: Referencing regular expressions created in the Áú»¢¶Ä²© frontend is not supported in this field. Starting with Áú»¢¶Ä²© 2.2, this field may contain supported macros. |
| Required status codes | List of expected HTTP status codes. If Áú»¢¶Ä²© gets a code which is not in the list, the step will fail. If empty, no check is performed. For example: 200,201,210-299 Starting with Áú»¢¶Ä²© 2.2, user macros can be used in this field. |
Any changes in web scenario steps will only be saved when the whole scenario is saved.
See also a real-life example of how web monitoring steps can be configured.
Configuring authentication
The Authentication tab allows you to configure scenario authentication options.
Authentication parameters:
| Parameter | Description |
|---|---|
| Authentication | Authentication options. None - no authentication used. Basic authentication - basic authentication is used. NTLM authentication - NTLM ( authentication is used. Selecting an authentication method will provide two additional fields for entering a user name and password. User macros can be used in user and password fields, starting with Áú»¢¶Ä²© 2.2. |
| SSL verify peer | Mark the checkbox to verify the SSL certificate of the web server. The server certificate will be automatically taken from system-wide certificate authority (CA) location. You can override the location of CA files using Áú»¢¶Ä²© server or proxy configuration parameter SSLCALocation. This sets the cURL option. This option is supported starting with Áú»¢¶Ä²© 2.4. |
| SSL verify host | Mark the checkbox to verify that the Common Name field or the Subject Alternate Name field of the web server certificate matches. This sets the cURL option. This option is supported starting with Áú»¢¶Ä²© 2.4. |
| SSL certificate file | Name of the SSL certificate file used for client authentication. The certificate file must be in PEM1 format. If the certificate file contains also the private key, leave the SSL key file field empty. If the key is encrypted, specify the password in SSL key password field. The directory containing this file is specified by Áú»¢¶Ä²© server or proxy configuration parameter SSLCertLocation.HOST.* macros and user macros can be used in this field.This sets the cURL option. This option is supported starting with Áú»¢¶Ä²© 2.4. |
| SSL key file | Name of the SSL private key file used for client authentication. The private key file must be in PEM1 format. The directory containing this file is specified by Áú»¢¶Ä²© server or proxy configuration parameter SSLKeyLocation.HOST.* macros and user macros can be used in this field.This sets the cURL option. This option is supported starting with Áú»¢¶Ä²© 2.4. |
| SSL key password | SSL private key file password. User macros can be used in this field. This sets the cURL option. This option is supported starting with Áú»¢¶Ä²© 2.4. |
[1] Áú»¢¶Ä²© supports certificate and private key files in PEM format only. In case you have your certificate and private key data in PKCS #12 format file (usually with extention *.p12 or *.pfx) you may generate the PEM file from it using the following commands:
Áú»¢¶Ä²© server picks up changes in certificates without a restart.
If you have client certificate and private key in a single file just specify it in a "SSL certificate file" field and leave "SSL key file" field empty. The certificate and key must still be in PEM format. Combining certificate and key is easy:
Display
To view detailed data of defined web scenarios, go to Monitoring → Web or Latest data. Click on the scenario name to see more detailed statistics.
An overview of web monitoring scenarios can be viewed in Monitoring → Dashboard.
Extended monitoring
Sometimes it is necessary to log received HTML page content. This is especially useful if some web scenario step fails. Debug level 5 (trace) serves that purpose. This level can be set in server and proxy configuration files or using a runtime control option (-R log_level_increase="http poller,N", where N is the process number). The following examples demonstrate how extended monitoring can be started provided debug level 4 is already set:
Increase log level of all http pollers:
shell> zabbix_server -R log_level_increase="http poller"
Increase log level of second http poller:
shell> zabbix_server -R log_level_increase="http poller,2"If extended web monitoring is not required it can be stopped using the -R log_level_decrease option.