Trigger dependencies
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:
- 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:
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:
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:
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.
- 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:
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:
- Go to Configuration | Hosts, click on Triggers next to Another host, and click on the SMTP service is down trigger in the Name?column
- 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.