Zabbix WEB Monitoring support is developed with the following goals:
Zabbix provides effective and very flexible WEB monitoring functionality. The module periodically executes WEB scenarios and keeps collected data in the database. The data is automatically used for graphs, triggers and notifications.
The following information is collected per each step of WEB scenario:
Zabbix also checks if a retrieved HTML page contains a pre-defined string.
Zabbix WEB monitoring supports both HTTP and HTTPS.
Scenario is set of HTTP requests (steps), which will be periodically executed by Zabbix server. Normally a scenario is defined for one particular part of functionality of a WEB application. Scenarios are very convenient way of monitoring user experience. WEB Scenario is linked to a host application for grouping. WEB Scenario is periodically executed and consists of one or more Steps. All cookies are preserved during execution of a single scenario.
Monitoring of Zabbix GUI
If we want to monitor availability and performance of Zabbix GUI, we have to login, check how quickly Overview and Status of Triggers screens work and then logout.
The scenario may have the following steps:
If a step cannot be performed, execution of scenario fails.
| Parameter | Description |
|---|---|
| Application | WEB scenario will be linked to this application. The application must exist. For example: Zabbix Server |
| Name | Name of the WEB scenario. The name will appear in Monitoring → Web For example: Zabbix GUI |
| Update interval | How often this scenario will be executed, in seconds. For example: 60 |
| Agent | Zabbix will pretend to be the selected browser. Useful for monitoring of WEB sites which generate different content for different WEB browsers. For example: Opera 9.02 on Linux |
| Status | Active: active scenario, it will be executed Disabled: disabled scenario, it will NOT be executed |
| Variables | List of macros to be used in configuration of the steps. Syntax: {macro}=value The macro {macro} will be replaced by “variable” in Step's URL and Post variables. For example: {user}=guest {password}=guest |
| Steps | Steps of the scenario. |
As soon as a scenario is created, Zabbix automatically adds the following items for monitoring and links them to the selected application. Actual scenario name will be used instead of “Scenario”.
| Item | Description |
|---|---|
| Download speed for scenario 'Scenario' | This item will collect information about download speed (bytes per second) of the whole scenario, i.e. average for all steps. Item key: web.test.in[Scenario,,bps] Type: float |
| Failed step of scenario 'Scenario' | This item keeps number of failed step of the scenario. If all steps are executed successfully, 0 is returned. Item key: web.test.fail[Scenario] Type: integer |
These items can be used to create triggers and define notification conditions.
Trigger “WEB scenario failed”
The trigger expression can be defined as:
{host: web.test.fail[Scenario]}.last(0)#0
Do not forget to replace the Scenario with real name of your scenario.
Trigger “WEB application is slow”
The trigger expression can be defined as:
{host: web.test.in[Scenario,,bps]}.last(0)<10000
Do not forget to replace the Scenario with real name of your scenario.
Step is basically a HTTP request. Steps are executed in a pre-defined order.
| Parameter | Description |
|---|---|
| Name | Name of the step. For example: Login |
| URL | URL For example: www.zabbix.com |
| 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. |
| Timeout | Do not spend more than Timeout seconds for execution of the step. Actually this parameter defines maximum time for making connection to the URL and maximum time for performing an HTTP request. Therefore, Zabbix will not spend more than 2 x Timeout seconds on the step. For example: 15 |
| Required | The string (given as POSIX regular expression) must exist in retrieved content. Otherwise this step fails. If empty, any content will be accepted. For example: Homepage of Zabbix |
| Status codes | List of HTTP status codes to be considered as success. If retrieved status code is not in the list, this step fails. If empty, any status code is accepted. For example: 200,210 |
As soon as a step is created, Zabbix automatically adds the following items for monitoring and links them to the selected application. Actual scenario and step names will be used instead of “Scenario” and “Step” respectively.
| Item | Description |
|---|---|
| Download speed for step 'Step' of scenario 'Scenario' | This item will collect information about download speed (bytes per second) of the step. Item key: web.test.in[Scenario,Step,bps] Type: float |
| Response time for step 'Step' of scenario 'Scenario' | This item will collect information about response time of the step in seconds. Response time is counted from the beginning of the request until all information has been transferred. Item key: web.test.time[Scenario,Step] Type: float |
| Response code for step 'Step' of scenario 'Scenario' | This item will collect response codes of the step. Item key: web.test.rspcode[Scenario,Step] Type: integer |
These items can be used to create triggers and define notification conditions.
Trigger “Zabbix GUI login is too slow”
The trigger expression can be defined as:
{zabbix: web.test.time[ZABBIX GUI,Login]}.last(0)>3
Let's use Zabbix Web Monitoring for monitoring of Zabbix Web interface. We want to know if it is available, provides right content and how quickly it works. First we login with our user name and password.
Add new host application.
This step is not required if you already have a suitable application. You may also want to create a host if one does not exist. Open Configuration → Hosts, then click on Applications next to the host you want to use for web monitoring. In the application section, click Create application.
Add new Web scenario.
We will add a new scenario for monitoring of Zabbix Web interface. The scenario will execute number of steps.
Navigate to Configuration → Web, select a host, then click Create scenario button. Click on Select next to the Application field and choose the application we just created.
Note that we also created two macros, {user} and {password}.
Define steps for the scenario.
Click on Add button in the Steps section to add individual steps.
Web scenario step 1
We start by checking that the first page responds correctly, returns with HTTP response code 200 and contains text SIA Zabbix.
When done configuring the step, click Add.
Web scenario step 2
We continue by logging in the Zabbix frontend, and we do so by reusing the macros (variables) we defined on the scenario level, {user} and {password}.
All the post variables must be on a single line and concatenated with & symbol. Example string for logging into Zabbix frontend:
name=Admin&password=zabbix&enter=Enter
If using the macros as in this example, login string becomes:
name={user}&password={password}&enter=Enter
Web scenario step 3
Being logged in, we should now verify the fact. To do so, we check for a string that is only visible when logged in - for example, Profile link appears in the upper right corner.
Web scenario step 4
Now that we have verified that frontend is accessible, we can log in and retrieve logged-in content, we should also log out - otherwise Zabbix database will become polluted with lots and lots of open session records.
Final step configuration
The final web scenario step configuration should look like this:
Save the finished web monitoring scenario.
The list of applications and linked scenarios will appear in Monitoring → Web:
Click on the scenario name to see more detailed statistics:
Discussion
I have many scenarios and very often add/remove them, and monitor same parameter (fail test), but at now I must create the separate trigger for each item.