Our first steps in website testing were fairly simple. Let's do something more fancy now. We will attempt to log in to the Zabbix frontend, check whether that succeeds, and then log out. We should also verify that the logout operation was successful, by the way.
We will do this with a larger number of individual steps for greater clarity:
We will set up this scenario on A test host
. Go to Configuration | Hosts, click on Web next to A test host, and click on Create web scenario. Fill in these values:
Zabbix frontend
Zabbix frontend
{user}=Admin {password}=zabbix
The variables we filled in use a different syntax than other macros/variables in Zabbix. We will be able to use them in the scenario steps, and we'll see how exactly that is done in a moment. And now, on to the steps—switch to the Steps tab. For each of the steps, first click on the Add link in the Steps section. In the end, click on the Add button in the step properties, and proceed to the next step. For all the steps, adapt the URL as needed—the IP address or hostname and the actual location of the Zabbix frontend.
On the first page, fill in the following details:
First page
http://127.0.0.1/zabbix/index.php
Zabbix SIA
200
In the URL, we also appended index.php
to reduce the amount of redirects required. Required string will be checked against the page contents. That also includes all the HTML tags, so make sure to list them if your desired string has any included. We also chose a text that appears at the bottom of the page to ensure that the page is likely to have loaded completely. And the status code: the HTTP response code of 200
is ok; we require that specific code to be returned.
Log in
http://127.0.0.1/zabbix/index.php
name={user}&password={password}&enter=Sign in
200
Most of the things in this step should be clear, except maybe the new Post string. It follows the standard syntax of specifying multiple values, concatenated with an ampersand. We are finally using the variables we specified earlier, and we pass them according to the input field names in the login form. The last variable, enter
, is a hidden input in the Zabbix frontend login page, and we must pass a hardcoded value of Sign in
to it. To find out these values for other pages, check the page source, use browser debugging features, or sniff the network traffic.
We could assume that the logging in succeeded. But it is always best to check such things. We could have missed some hidden variable, or we could have made a mistake in the password. So, we'll use a separate step to be sure that logging in really succeeded. Note that all further steps in this scenario will act as a logged-in user until we log out. Zabbix keeps all received cookies for latter steps during the whole scenario. When logged in, one distinguishing factor is the profile link, which uses the top-nav-profile
class—and that would be the string we would check for:
Check login
http://127.0.0.1/zabbix/index.php
top-nav-profile
200
Don't add this step yet. Before continuing with the next step—logging out—we should discuss what will we need for it. Logging out is considered an action that modifies something, so we actually have to pass a session ID as an sid
variable. We must obtain it somehow now, and that can be done by extracting the ID from the page source here. Values can be extracted from the web page, assigned to variables, and reused in subsequent steps. Let's also fill in the following:
Variables: {sid}=regex:sid=([0-9a-z]{16})
Now, the step can be added. The syntax here deserves to be discussed in more detail. While the first part of the variable assignment is the same as assigning some value manually, the second part, after the equals sign, starts with the keyword regex
. Then, separated by a colon, a regular expression follows. It is matched against the page source. In our case, we start by looking for the sid=
string, followed by 16
alphanumeric characters. These alphanumeric characters are the session ID, and we have included them in a capture group. Note that this is not Zabbix-specific but a standard regular expression functionality. The contents of the matched capture group will be assigned to the variable. Extracting and reusing the session ID is the most common use of this functionality, but anything one might want to reuse in subsequent steps can be extracted from the page and assigned to a variable if we can come up with a regex for that.
Now that we have the session ID, we are ready to log out. We have to use a different URL, though. If you look at the page source, the logout control uses JavaScript to redirect to a relative URL, like this:
index.php?reconnect=1&sid=b208d0664fa8df35
The two important variables here are reconnect
and sid
. The reconnect
one has to be simply set to 1
. As for sid
, we luckily extracted that value in the previous step, so we have all the components to log out:
Log out
http://127.0.0.1/zabbix/index.php?reconnect=1&sid={sid}
200
Logging out is important. Otherwise, the sessions won't be removed for a year by default, and every frontend check will add one session. A large number of sessions will slow down the Zabbix frontend. We'll discuss session maintenance in Chapter 22, Zabbix Maintenance.
We will check whether there's a string we only expect to see on the login page. Logging out could have invisibly failed otherwise:
Check logout
http://127.0.0.1/zabbix/index.php
Sign in
200
The final steps should look like this:
If everything looks good, click on the Add button at the bottom of the page to finally save this scenario. We could let the scenario run for a while now and discuss some step parameters we didn't use:
301
or some other valid redirect code.15
seconds, which can lead to Zabbix spending up to 30 seconds on a page.We could have used a user macro for a 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 Configuration with Templates.
After the scenario has had some time to run, let's go to Monitoring | Web page. Choose Linux servers in the Group dropdown and click on Zabbix frontend in the NAME column:
The scenario seems to be running correctly: log in and log out seem to work 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: Check login, the actual fault is likely in Step 2: Log in—that is, the login failed.
The approach we took with five steps was not the most simple one. While it allowed us to split out each action in its own step (and provided nice graphs with five values), we could have used a much more simple approach. To check login and logout, the simplest approach and the minimum number of steps would have been these:
As an extra exercise, consider creating a new scenario and achieving the same goal in two steps.