The discovery monitoring page is interesting at first, but not that useful in the long term. Luckily, we can make Zabbix perform operations in response, and the configuration is somewhat similar to how we reacted to triggers firing.

To see how this is configured, follow these steps:

Navigate to Configuration | Actions and switch to Discovery in the Event source drop-down in the upper-right corner. Then, click on Create action. Fill in the name of Network discovery test, switch to the New conditions drop-down box, and expand the first drop-down in the New condition section:

The available conditions are completely different from what was available for trigger actions. Let's review them:

• Discovery check: A specific check in a specific discovery rule must be chosen here.
• Discovery object: Either a device or service can be chosen here. In our example, the discovered host would be a device object and SMTP would be a service object.
• Discovery rule: A specific network discovery rule must be chosen here.
• Discovery status: This condition has possible values of Up, Down, Discovered, and Lost. For devices, they are considered to be discovered or up if at least one service on them can be reached. Here is what the values mean:
  • Discovered: This device or service is being seen for the first time or after it was detected to be down
  • Lost: This device or service has been seen before, but it has just disappeared
  • Up: The device or service has been discovered, no matter how many times it might have happened already
  • Down: The device or service has been discovered at some point, but right now, it is not reachable, no matter how many times that has happened already
• Host IP: Individual addresses or ranges may be specified here.
• Proxy: Action may be limited to a specific Zabbix proxy. We will discuss proxies in Chapter 17, Using Proxies to Monitor Remote Locations.
• Received value: If we are polling a Zabbix agent item or an SNMP OID, we may react to a specific value—for example, if undertaking discovery according to the system.uname item key, we could link all hosts that have Linux in the returned string to the Linux template.
• Service port: Action may be limited to a specific port or port range on which the discovery has happened.
• Service type: Action may be restricted to a service type. This is similar to the Discovery check condition, except that choosing SMTP here would match all SMTP checks from all network discovery rules, not just a specific one.
• Uptime/Downtime: Time in seconds may be entered here to limit the action only after the device or service has been up or down for a period of time.

Most of these are pretty self-explanatory, but let's take a closer look at two of them. The Discovery status condition allows us to differentiate between the initial check or being discovered after downtime and periodic checks. As an example, if we matched the Up status and added the host to a Host group, this addition would be checked and performed every time the host can be reached. If somebody removed that host from that host group, it would be readded during every discovery cycle. If we matched the Discovered status, it would only happen when the host is first discovered and when it goes down and then up again. Automatic readdition to the group is most likely to happen later in this case.

The Uptime/Downtime condition allows us to react with a delay, not immediately. For example, we might want to have an uptime of a few hours before monitoring a device, as it might be a temporary troubleshooting laptop that is attached to the network. Probably even more importantly, we might not want to delete a host with all its history if that host is down for 5 minutes. Checking for a week-long downtime might be reasonable – if nobody bothered with that host for a week, it's safe to delete.

For now, let's leave the conditions empty and switch to the Operations tab. Adding a new operation and expanding the Operation type drop-down will reveal all the available operations. We will discuss them in more detail a bit later, but for now, let's choose Add to host groups. In the input field, start typing linux, and choose Linux servers from the drop-down. Then, click on the small Add control in the Operation details block. Be very careful here, as it is easy to lose some configuration. When done, click on the Add button at the bottom:

After a couple of minutes, go to Configuration | Hosts to observe the results. If discovering our test systems, we should see that one new host has been added.

Why only one host? The other host already existed as per Monitoring | Discovery earlier. For this host, you will see either its hostname or the IP address used as the hostname in Zabbix. If the Zabbix server was able to perform a reverse lookup on the IP address, the result will be used as the hostname. If not, the IP address will be used as the hostname.

Click on New host in the Name column. In the Groups section, this host is in the Linux servers group, as expected. But it is also in some other group, Discovered hosts. Where did that come from?

By default, all hosts discovered by network discovery are added to a specific group. Which group? That's a global setting.

Navigate to Administration | General and then choose Other in the drop-down. The Group for discovered hosts setting allows us to choose which group that is. What if you don't want the discovered hosts to end up in that group? In the action operations, we could add another operation, Remove from host group, and specify the Discovered hosts group.

Now let's review all available discovery operations:

• Send message: The same as for trigger actions, we may send a message to users and user groups. This could be used both to supplement an action that adds devices (Hey, take a look at this new server we just started monitoring) or as a simple notification that a new device has appeared on the network (This new IP started responding, but I won't automatically monitor it).
• Remote command: Zabbix can attempt to run a remote command on a passive Zabbix agent or Zabbix server, a command using IPMI, SSH, or Telnet, and even a global script. This would only succeed if remote commands are enabled on the Zabbix agent side. We discussed remote commands in Chapter 7, Acting upon Monitored Conditions.
• Add host: A host will be added and only included in the Discovered hosts group.
• Remove host: A host will be removed. This probably makes the most sense to perform when a host has not been discovered, and, to be on the safe side, only when the downtime exceeds a specified period of time.
• Add to host group: A host will be added to a host group. If there is no such host, one will be added first.
• Remove from host group: A host will be removed from a host group.
• Link to template: A host will be linked to a template. If there is no such host, one will be added first.
• Unlink from template: A host will be unlinked from a template.
• Enable host: A host will be enabled. If there is no such host, one will be added first.
• Disable host: A host will be disabled. This could be used as a safer alternative to removing hosts, or we could disable a host first and remove it later. If there is no such host, one will be added first.

When linking to a template, the host still needs all the proper interfaces, as required by the items in that template. During discovery, only successful discovery checks result in the adding of interfaces of a corresponding type. For example, if we only found SNMP on a host, only an SNMP interface would be added. If both SNMP and Zabbix agent discovery checks succeeded on a host, both interfaces would be added. If some checks succeed later, additional interfaces are created.