A third way to link templates to hosts is to let the server do it automatically by combining Zabbix's host-discovery facility with discovery actions.
Zabbix's discovery facilities consist of a set of rules that periodically scan the network to look for new hosts or disappearing ones according to predetermined conditions.
The three methods that Zabbix can use to check for new or disappeared hosts, given an IP range, are:
As you can see, when enabled, this rule will check every hour in the IP range 192.168.1.1-255
for any server that:
system.uname
itemAs usual, with all things Zabbix, a discovery rule will not do anything by itself, except generate a discovery event. It will then be the job of Zabbix's actions facility to detect the said event and decide whether and how to act on it. Discovery event actions are virtually identical to trigger event actions. As you saw trigger event actions in Chapter 6, Managing Alerts, the following are the only differences when it comes to discovery events.
First, action conditions are a bit different, as can be expected, as shown in this following screenshot:
Instead of hostnames and trigger specifications, you can set conditions based on things such as Discovery status, Service type, and Uptime/Downtime. The Received value condition is of particular interest as it allows things such as differentiating between operating systems, application versions, and any other information you can get from a Zabbix or SNMP agent query.
This kind of information will be critical when it comes to configuring the action's operations. The following screenshot shows this:
Sending a message and executing a remote command are the exact equivalents of the same operations available to trigger event actions. On the other hand, if adding (or removing) a host is quite a self-explanatory action when it comes to adding to a host group or linking to a template, it becomes clear that a good set of actions with specific received value conditions and template-linking operations can give a high level of automation to your Zabbix installation.
This high level of automation is probably more useful in rapidly changing environments that still display a good level of predictability depending on the kind of hosts you can find, such as fast-growing grids or clusters. In these kinds of environments, you can have new hosts appearing on a daily basis and perhaps old hosts disappearing at almost the same rate, but the kind of host is more or less always the same. This is the ideal premise for a small set of well-configured discovery rules and actions, so you don't have to constantly and manually add or remove the same types of hosts. On the other hand, if your environment is quite stable or you have very high host-type variability, you may want to look more closely at what and how many hosts you are monitoring as any error can be much more critical in such environments.
On the other hand, limiting discovery actions to sending messages about discovered hosts can prove quite useful in such chaotic environments or where you don't directly control your systems' inventory and deployment. In such a case, getting simple alerts about new hosts, or disappearing ones, can help the monitoring team keep Zabbix updated despite any communication failure between IT departments—accidental or otherwise.