You might have noticed how items in Zabbix do not contain any configuration for the quality of the data—if the CPU load values arrive, the item does not care whether they are 0 or 500. Any definition of a problem condition happens in a trigger, whether it's a simple threshold or something more complex.

And when we created this trigger, we could click on any of the Triggers links, but we paid attention to the host selected in the drop-downs when choosing the item. It actually does not matter which of those Triggers links we click on, as long as the proper host is selected in that popup, or we manually enter the correct host name.

If we clicked on Triggers for host A and then chose an item from host B for that trigger, the created trigger would not appear for host A, but would appear for host B.

This decoupling of problem conditions from the value collection has quite a lot of benefits. Not only is it easy to check for various different conditions on a single item, a single trigger may also span multiple items. For example, we could check the CPU load on a system in comparison with the user session count. If the CPU load is high and there are a lot of users on the system, we could consider that to be a normal situation. But if the CPU load is high while there is a small number of users on the system, it would be a problem. An example trigger is as follows:

{host:system.cpu.load.last()}>5 and {host:user.sessions.last()}<100 

This would trigger if the CPU load was above 5, but only if there were fewer than 100 users on the system.

A trigger could also reference items from multiple hosts. We could correlate a database statistic with the performance of an application on a different host, or free disk space on file servers with the number of users in the Lightweight Directory Access Protocol (LDAP).

We will discuss and configure some slightly more advanced trigger expressions later in this chapter.