Zabbix Network Monitoring(Second Edition)
上QQ阅读APP看书,第一时间看更新

Information flow in Zabbix

We have now configured various things in the Zabbix frontend, including data gathering (Item), threshold definition (Trigger), and instructions on what to do if a threshold is exceeded (Action). But how does it all work together? The flow of information between Zabbix entities can be non-obvious at first glance. Let's look at a schematic showing how the pieces go together:

In our Zabbix server installation, we created a host (A test host), which contains an item (CPU load). A trigger references this item. Whenever the trigger expression matches the current item value, the trigger switches to the PROBLEM state. When it ceases to match, it switches back to the OK state. Each time the trigger changes its state, an event is generated. The event contains details of the trigger state change: when it happened and what the new state is. When configuring an action, we can add various conditions so that only some events are acted upon. In our case, we did not add any, so all events will be matched. Each action also contains operations, which define what exactly has to be done. In the end, some operation is actually carried out, which usually happens outside of the Zabbix server, such as sending an e-mail.

A trigger can also be in the UNKNOWN state. This happens if there is not enough data to determine the current state. As an example, computing the average value for the past 5 minutes when there's no data for the past 10 minutes will make the trigger go into the UNKNOWN state. Events that cause a change to or from the UNKNOWN state do not match normal action conditions.