Discovering hosts

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:

  • The availability of a Zabbix agent
  • The availability of an SNMP agent
  • Response to simple external checks (FTP, SSH, and so on)
  • These checks can also be combined, as illustrated in the following example:
    Discovering hosts

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:

  • Responds to an ICMP ping probe
  • Has a correctly configured Zabbix agent that will return a value when asked for the system.uname item
  • Has an SMTP listening port, which is usually associated with a mail server

As 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:

Discovering hosts

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:

Discovering hosts

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.224.108.196