We now have one service being watched. There are some more being monitored, so now we can try to create a trigger for an HTTP server. Let's assume that our host runs software that is a bit weird. The web service is a web email front-end, and it goes down whenever the SMTP server is unavailable. This means that the web service depends on the SMTP service.

Go to Configuration | Hosts, click on Triggers next to Another host, and then click on Create trigger. Fill in the following values:

• Name: Web service is down.
• Expression: Click on Add, and then again on Select next to the Item field. Make sure that Linux servers is selected in the Group drop-down and Another host in the Host drop-down, and then click on Web server status in the Name column. Both the function and its parameter are fine, so click on Insert:

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

• Severity:  The value of this field should be Average.
• Description: 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, understand the thinking behind such complex expressions later. While our trigger is still very simple, we might want to explain the reason for the dependency, so enter something such as Web service goes down if SMTP is inaccessible.

Now, switch to the Dependencies tab. To configure the dependency of the web frontend on the SMTP service, click on the Add link in the Dependencies section. In the resulting window, make sure that Linux servers is selected in the Group drop-down and Another host is selected in the Host drop-down, and then click on the only entry in the Name column, that is, SMTP service is down:

When done, click on the Add button at the bottom. 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:

Both triggers in the dependency list and items in the Expression column act as links, allowing easy access to their details.

With the dependency set up, let's find out whether it changes anything in the front-end. Navigate to Monitoring | Overview, make sure Type is set to Triggers, expand the filter, then switch Triggers status to Any, and click on Filter:

The difference is visible immediately. Triggers involved in the dependency have arrows drawn over them. So, an upward arrow means something depends on this trigger—or was it the other way around? Luckily, you don't have to memorize that. Make sure that the web service and the SMTP service are down on another host first. Move the mouse cursor over the SMTP service is down trigger for Another host, which is the upper cell with the arrow:

A popup appears, informing us that there are other triggers that are dependent on this one. Dependent triggers are listed in the popup. If we click on the arrow and then on Description from the popup menu, we will see the description we added in the trigger box before.

Let's see what happens if we turn our SMTP service on and keep our web service down. After a few seconds, when Zabbix notices that the SMTP service is up, we can see that our trigger has changed. We can now see that our web service is down and that the arrow is pointing downward, telling us that there is a dependency on this trigger:

The web server trigger has disappeared from the list and has been replaced by the SMTP server trigger. That's because Zabbix does not show dependent triggers if the dependency upstream trigger is in the PROBLEM state. This helps to keep the list short and concentrate on the problems that actually cause downtime. 

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 provide an easy way to manually change the trigger state without affecting system services. In the frontend, navigate to Configuration | Hosts, click on Items next to Another host, and then click on Create item. Fill in the following values:

• Name: Testfile exists
• Key: vfs.file.exists[/tmp/testfile]

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

In the bar above the Item list, click on Triggers, and then click on the Create trigger button. Enter these values:

• Name: Testfile is missing.
• Expression: Click on Add and then on Select next to the Item field. In the item list for Another host, click on Testfile exists in the Name column, and then click on Insert (again, the default function works for us). The Expression field is filled with the following expression:

{Another Host:vfs.file.exists[/tmp/testfile].last()}=0 

• Severity: The severity value should be Warning.

When you are done, click on the Add button at the bottom. Let's complicate the trigger chain a bit now. Click on the SMTP service is down trigger in the Name column, switch to the Dependencies tab, and click on Add in the Dependencies section. 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 on Update. 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 those two other triggers. This means that only a single trigger will be displayed in the Monitoring | Overview section. If we place the most important trigger at the bottom and the ones depending on it above, we would get a dependency chain like this:

Now, we should move on 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 the following:

$ touch /tmp/testfile

This should create an empty file and deal with the only trigger currently on the trigger list. Wait for the trigger list to update. You will see that the list gets updated and that the trigger that tells us that the SMTP service is down will be visible in the trigger box.

Looking at the list, we can see one big difference this time—the SMTP trigger now has two arrows, one pointing up and the other pointing down. Moving your 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 a dependency chain, two arrows will appear, as has happened for the SMTP service is down trigger here.

The arrows here are shown in the same direction as in our previous schematic. We could say that the dependent trigger is supported by the more important trigger, as if we had bricks placed one on top of another. If any of the bricks disappear, the bricks above it will be in trouble.

Our testfile trigger worked as expected for the chained dependencies, so we can remove that dependency now:

1. Go to Configuration | Hosts, click on Triggers next to Another host, and click on the SMTP service is down trigger in the Name column
2. Switch to the Dependencies tab, click on Remove in the Action column, and click on the Update button

Note that you always have to save your changes in the editing form of any entity. In this case, simply removing the dependency won't be enough. If we navigate to some other section without explicitly updating the trigger, any modifications will be lost. Now, you can also restart any stopped services on another host.