In this chapter, we explored another aspect of host properties in Zabbix—host inventory. Host inventory may be manually populated, but the more useful aspect of it is its ability to receive values from any item in any inventory field. This still allows you to manually edit inventory fields that do not receive values from items.

Host and Host group maintenance allows us to create on-time or recurring maintenance entries on a daily, weekly, and monthly basis. Problems with hosts that are in maintenance are distinguished visually in the frontend, and in many views we can also choose not to show such problems at all.

It's important to remember the main rules about permissions in Zabbix:

• Permissions can be assigned to user groups only
• Permissions can be granted on host groups only

This means that, for fancy permission schemes, you might have to do some planning before starting to click around. We can also safely say that, to avoid mysterious problems in the future, every host should be in at least one host group, and every user should be in at least one user group. Additionally, there were two factors that combined to determine effective permissions—the permissions set for groups and the user type. We can try summarizing the interaction of these two factors:

Looking at the preceding table, we can see that the Zabbix Super Admin user type cannot be denied any permissions. On the other hand, Zabbix User cannot be given write permissions. Still, it is very important to remember that, at this time, they would gain write privileges through the Zabbix API.

With this knowledge, you should be able to group hosts, manage host inventories, and host maintenance, as well as create groups, sub-groups, and users, not to mention assign  fine-grained permissions.

In the next chapter, we'll look at a way to check whether item values indicate a problem or not. While we have items collecting data, items in Zabbix are not used to configure thresholds or any other information to detect bad values. Items don't care what the values are as long as the values are arriving. To define what a problem is, a separate configuration entity, called a trigger, is used. Trigger logic, written as an expression, can range from very simple thresholds to fairly complex logical expressions.