So far, we have used only very simple trigger expressions, comparing the last value to a constant. Fortunately, that's not all that trigger expressions can do. We will now try to create a slightly more complex trigger.

Let's say we have two servers, A test host and Another host, providing a redundant SSH File Transfer Protocol (SFTP) service. We would be interested in any one of the services going down. Navigate to Configuration | Hosts, and click on Triggers next to Another host. Then, click on the Create trigger button. Enter the following values:

• Name: One SSH service is down.
• Expression: Click on the Add button. In the resulting popup, click on Select next to the Item field. Make sure Another host is selected in the Host drop-down, click on the SSH server status item in the Name column, and then click on Insert. Now, position the cursor at the end of the inserted expression and enter  or without quotes (that's a space, or, and a space). Again, click on the Add button. In the resulting popup, click on Select next to the Item field. Select A test host from the Host drop-down, click on the SSH server status item in the Name column, and click on Insert.
• Severity: The value of severity should be Average (remember, these are redundant services).

The final trigger expression should look like this:

{Another host:net.tcp.service[ssh].last()}=0 or {A test host:net.tcp.service[ssh].last()}=0 

When you are done, click on the Add button at the bottom.

The process we followed here allowed us to create a more complex expression than simply comparing the value of a single item. Instead, two values are compared, and the trigger fires if either of them matches the comparison. That's what the or operator does. Another logical operator is and. Using the SSH server as an example trigger, we could create another trigger that would fire whenever both SSH instances go down. Getting the expression is simple, as we just have to modify that single operator, that is, change or to and, so that the expression looks like this:

{Another host:net.tcp.service[ssh].last()}=0 and {A test host:net.tcp.service[ssh].last()}=0 

Trigger expressions also support other operators. In all the triggers we created, we used the most common one—the equality operator, =. We could also be using the inequality operator, <>. That would allow us to reverse the expression, like this:

{A test host:net.tcp.service[ssh].last()}<>1 

While not useful in this case, such a trigger is helpful when the item can have many values and we want the trigger to fire whenever the value isn't the expected one.

Trigger expressions also support the standard mathematical operators +, -, *, and /, and comparison operators <, >, <=, and >=, so complex calculations and comparisons can be used between item data and constants.

Let's create another trigger using a different function. In the frontend section Configuration | Hosts, choose Linux servers from the Group drop-down, click on Triggers next to A test host, and click on the Create trigger button. Then, enter the following values:

• Name: Critical error from SNMP trap
• Expression: {A test host:snmptrap.fallback.str(Critical Error)}=1
• Severity: The value of severity should be High

When you are done, click on the Add button at the bottom.

This time, we used another trigger function, str(). It searches for the specified string in the item data and returns 1 if it's found. The match is case-sensitive.

This trigger will change to the OK state whenever the last value for the item does not contain the string specified as the parameter. If we want to force this trigger to the OK state manually, we can just send a trap that does not contain the string the trigger is looking for. Sending a success value manually can also be useful when another system is sending SNMP traps. In the case where the problem trap is received successfully but the resolving trap is lost (because of network connectivity issues, or for any other reason), you might want to use such a fake trap to make the trigger in question go back to the OK state. If using the built-in trap-processing functionality, it would be enough to add trap information to the temporary file. If using the scripted solution with Zabbix trapper items, zabbix_sender could be used. SNMP trap management was discussed in Chapter 4, Monitoring SNMP Devices.