Anexo IX: Detalle Sprint 3 Backlog

We now have one service being watched. Though there are some more monitored and now we can try to create a trigger for a HTTP server. Go to Configuration |

Hosts, click on Triggers next to Another Host, then click on Create Trigger. Fill in the following values:

Name: Enter WEB service is down.

Expression: Click on Select, then again on Select next to the Item field. Make sure Linux servers is selected in the Group field and Another Host in the host field, then click on WEB server status in the Description column. Both function and its parameter are fine, so click on Insert.

• •

That inserts the expression {Another Host:net.tcp.service[http,,80]. last(0)}=0.

The trigger depends on: Our host runs software that is a bit weird—the web service is a web e-mail frontend, and it goes down whenever the SMTP server is unavailable. This means the web service depends on SMTP service. To configure that, click on Add next to the New dependency. In the resulting window, make sure Linux servers is selected in the Group dropdown and

Another Host is selected in the Host dropdown, then click on the only entry in the Description column—SMTP service is down.

Severity: Select Average.

Comments: Trigger expressions can get very complex. Sometimes the complexity can make it impossible to understand what a trigger is supposed to do without serious dissection. Comments provide a way to help somebody else, or yourself, to understand the thinking behind such complex triggers later. While our trigger still is very simple, we might want to explain the reason for the dependency, so enter something like Web service goes down if SMTP is inaccessible.

When you are done, click Save. Notice how, in the trigger list, trigger dependencies are listed in the Name column. This allows for a quick overview of any dependent triggers without opening the details of each trigger individually.

•

• •

[ 170 ]

Item name colors in the Expression column match their state – green for

OK, red for disabled, and grey for unsupported.

With the dependency set up, let's find out whether it changes anything in the frontend. Navigate to Monitoring | Overview.

Indeed, the difference is visible immediately. Triggers involved in the dependency have arrows drawn over them. So an upwards arrow means something depends on this trigger or was it the other way around? Luckily, you don't have to memorize that. Move the mouse cursor over the SMTP service is down trigger for Another Host, the upper cell with the arrow.

A pop up appears, informing you that there are other triggers dependent on this one. Dependent triggers are listed in the pop up. Now move the mouse cursor one cell below, over the downwards pointing arrow.

Let's see what effect other than the arrows does this provide. Open Monitoring |

Triggers and make sure both Host and Group dropdowns say all, then bring down web server on "Another Host". Wait for the trigger to fire, look at the entry. Notice how an arrow indicating dependency is displayed here as well. Move the mouse cursor over it again, and the dependency details are displayed in a pop up.

Hey, what's up with the Show link in the Comments column? Let's find out—click on it. As can be seen, the comment we provided when creating the trigger is displayed. This allows for easy access to comments from the trigger list both for finding out more information about the trigger and updating the comment as well. Click on Cancel to return to the trigger list. Now, stop the SMTP service on the "Another Host". Wait for the trigger list to update and look at it again. The web server trigger has disappeared from the list, and is replaced by the SMTP server one. That's because Zabbix does not show dependent triggers if the dependency upstream trigger is active. This helps to keep the list short and concentrate on the problems that actually cause other downtime.

There's actually a minor bug with dependent trigger displaying in Zabbix 1.8.1 – most likely, you will see both triggers instead. This problem is

fixed in version 1.8.2.

Trigger dependencies are not limited to a single level. We will now add another trigger to the mix. Before we do that, we'll also create an item that will allow an easy manual condition change without affecting system services. In the frontend, navigate to Configuration | Hosts, click on Items next to Another Host, then click on Create Item. Fill in the following values:

Description: Enter Testfile exists

Key: Enter vfs.file.exists[/tmp/testfile].

When you are done, click Save. As the key might reveal, this item simply checks whether a particular file exists and returns 1 if it does, 0 if it does not.

Using a constant filename in /tmp in real life situations might not be

desirable, as any user could create such a file.

• •

[ 172 ]

In the bar above the item list, click on Triggers, then click on CreateTrigger button. Enter these values:

Name: Enter Testfile is missing.

Expression: Click on Select, then again Select next to the Item field. In the item list for Another Host, click on Testfile exists in the Description

column, then click on Insert (again, the default condition works for us). The

Expression field is filled with the following expression: {Another Host: vfs.file.exists[/tmp/testfile].last(0)}=0.

Severity: Select Warning.

When you are done, click Save. Let's complicate the trigger chain a bit now. Click on the SMTP service is down trigger in the Name column, then click on Add next to the New dependency entry. In the upcoming dialog, click on the Testfile is

missing entry in the Name column. This creates a new dependency for the SMTP service trigger.

Click Save. Now we have created a dependency chain, consisting of three triggers. "WEB service is down" depends on "SMTP service is down", which in turn depends on "Testfile is missing". Zabbix calculates chained dependencies, so all upstream dependencies are also taken into account when determining the state of a particular trigger—in this case, "WEB service is down" depends on both the other triggers. With Zabbix versions 1.8.2 and latter, this will mean only single trigger being displayed

• •

•

in Monitoring | Triggers section. Now we should get to fixing the problems the monitoring system has identified. Let's start with the one at the top of the dependency chain—the missing file problem. On "Another Host", execute: $ touch /tmp/testfile

This should deal with the only trigger currently on the trigger list. Wait for the trigger list to update. You will see two triggers, with their status flashing.

Again, with version 1.8.1 you will see all triggers. This problem has been corrected in 1.8.2.

Remember, by default Zabbix shows triggers that have recently changed state flashing, and that includes also triggers in the "OK" state.

Looking at the list, we see one large difference this time—the SMTP trigger now has two arrows, one pointing up, and the other pointing down. Moving your mouse cursor over them you will discover that they denote the same thing as before—the triggers that this particular trigger depends on or that depend on this trigger. If a trigger is in the middle of the dependency chain, two arrows will appear.

Our testfile trigger worked as expected for the chained dependencies, so we can remove it now. Open Configuration | Hosts, click on Triggers next to Another Host and click on the SMTP service is down trigger in the Name column. Mark the checkbox next to the Testfile is missing entry in the dependencies list, then click

Delete selected button. Now click the Save button. Note that you always have to save your changes for the editing form of any entity. In this case, simply removing the dependency would not be enough. If we navigate to some other section without explicitly saving the changes, any modifications will be lost. Now you can also restart any stopped services on "Another Host".