Triggers are things that fire. They look at item data and raise a flag when the data does not fit whatever condition has been defined. As mentioned before, simply gathering data is nice, but awfully inadequate. If you want any historical data gathering, including notifications, there would have to be a person looking at all of the data all of the time, so we have to define thresholds at which we want the condition to be considered worth looking into. Triggers provide a way to define what those conditions are.

Earlier, we created a single trigger that was checking the system load on A test host. It checks whether the returned value is larger than a defined threshold. Now, let's check for some other possible problems with a server, for example, when a service is down. The SMTP service going down can be significant, so we will try to look for such a thing happening now.

Navigate to Configuration | Hosts, click on any of the Triggers links, and click on the Create trigger button. In the form that opens, we will fill in some values, as follows:

• Name: The content of this field will be used to identify the trigger in most places, so it should be human-readable. This time, enter SMTP service is down. Notice how we are describing what the problem actually is. As opposed to an item, which gathers statuses, a trigger has a specific condition to check, thus, the name reflects it. If we have a host that should never have a running SMTP service, we could create a trigger named SMTP service should not be running.
• Expression: This is probably the most important property of a trigger. What is being checked, and for what conditions, will be specified here. Trigger expressions can vary from very simple to complex ones. This time, we will create a simple one, and we will also use some help from the frontend for that. Click on the Add button next to the Expression field to open the expression building dialog. It has several fields to fill in as well, so let's look at what those are:
  • Item: Here, we can specify which item data should be checked. To do that, click on the Select button. Another popup will open. Select Linux servers from the Group drop-down, and then select Another host from the Host drop-down. We are interested in the SMTP service, so click on SMTP server status in the Name column. The popup will close, and the Item field will be populated with the name of the chosen item.
  • Function: Here, we can choose the actual test to be performed. Perhaps we can try remembering what the SMTP server status item values were right, 1 was for the server running, and 0 was for the server being down. If we want to check when the last value was 0, the default function Last (most recent) seems to fit quite nicely, so we won't change it.
  • Last of (T): This is a function parameter if the function supports a time period. We used 180 in seconds for our first trigger to check the values during the previous 3 minutes, but when taking the last item value, a time period would make no sense.
  • Time shift: We will discuss this functionality later in this chapter, in the Relative thresholds or time shift section.
  • Result: This field allows us to set the constant used in the previous function. We want to find out whenever an SMTP server goes down (or the status is 0). So, here, the default of 0 fits as well:

With the values set as illustrated in the previous screenshot, click on the Insert button. The Expression field will now be populated with the {Another host:net.tcp.service[smtp].last()}=0 trigger expression.

• • Severity: There are five severity levels in Zabbix, and an additional Not classified severity level, as shown in the following screenshot:

We will consider this problem to be of average severity, so click on Average.

Before continuing, make sure that the SMTP server is running on another host, and then click on the Add button.

Let's find out what it looks like in the overview now:

1. Go to Monitoring | Overview and make sure that the Type drop-down has Triggers selected
2. Then, expand the filter, choose Any in the Acknowledge status drop-down, and click on Filter:

Great, we can see that both hosts now have a trigger defined. Since the triggers differ, we also have two unused cells:

Let's look at the trigger expression in more detail. It starts with an opening curly brace, and the first parameter is the hostname. Separated by a colon is the item key— this is net.tcp.service[smtp] here. The item key must be replicated exactly as in the item configuration, including any spaces, quotes, and capitalization. After the exact item key comes a dot as a separator, which is followed by the more interesting and trigger-specific thing—the trigger function. One of the most common functions is being used here—last(). It always returns a single value from the item history. There are trigger functions that require at least a parameter to be passed, but for the last() function, this is optional, and if the first parameter is just a number, it is ignored.

On the other hand, if the first parameter is a number prefixed with a hash, it is not ignored. In that case, it works like an nth value specifier. For example, last(#9) would retrieve the 9th most recent value. As we can see, last(#1) is equal to last(0) or last(). Another overlapping function is prev. As the name might suggest, it returns the previous value; thus, prev() is the same as last(#2).

Continuing with the trigger expression, curly braces are closed to represent a string that retrieves a value, that is, host and item reference, followed by the trigger function. Then, we have an operator, which in this case is a simple equals sign. The comparison here is done with a constant number, 0.