Step 5 – checking logout

We will check whether there's a string that we only expect to see on the login page. Logging out could have failed invisibly otherwise. Let's add a string to check for in our item:

• Name: Check logout
• URL: http://127.0.0.1/zabbix/index.php
• Required string: Username
• Required status codes: 200

If everything looks good, click on the Add button at the bottom of the page to save this scenario. We could let the scenario run for a while and discuss some of the step parameters we didn't use:

• Headers: Custom HTTP headers that will be sent when performing a request. They are specified as attribute and value pairs. Headers on the step level will overwrite the headers specified for the scenario.
• Follow redirects: This specifies whether Zabbix should follow redirects. If enabled, it follows up to 10 hardcoded redirects, so there is no way to check whether there's been a specific number of redirects. If disabled, we can check for the HTTP response code being 301 or some other valid redirect code.
• Retrieve only headers: If the page is huge, we may opt to retrieve headers only. In this case, the Required string option will be disabled, as Zabbix does not yet support matching strings in headers.
• Timeout: This specifies the timeout for this specific step. It is applied both to connecting and performing the HTTP request, separately. Note that the default timeout is rather long, at 15 seconds, which can lead to Zabbix spending up to 30 seconds on a page.

We could have used a user macro for part or all of the URL—that way, we would only define it once and then reference it in each step. We discussed user macros in Chapter 8, Simplifying Complex Configurations with Templates.

After the scenario has had some time to run, let's go to Monitoring | Web page. Choose Linux servers in the Group drop-down and click on Zabbix frontend in the Name column:

The scenario seems to be running correctly—the login and logout seem to have worked properly. Note that, if it fails for you, the failure could actually be in the previous step. For example, if it fails on Step 3 – checking login, the actual fault is likely to be in Step 2 – logging in, that is, the login failed.

The approach we took, with five steps, was not the simplest one. While it allowed us to split each action into its own steps (and provided nice graphs with five values), we could have used a much simpler approach. To check the login and logout, the simplest approach and the minimum number of steps would have been these:

• Log in and check whether it is successful
• Log out and check whether it is successful

As an extra exercise, create a new scenario that achieves the same goal in two steps.