1 Network discovery

Overview

Zabbix offers automatic network discovery functionality that is effective and very flexible.

With network discovery properly set up you can:

• speed up Zabbix deployment
• simplify administration
• use Zabbix in rapidly changing environments without excessive administration

Zabbix network discovery is based on the following information:

• IP ranges
• Availability of external services (FTP, SSH, WEB, POP3, IMAP, TCP, etc)
• Information received from Zabbix agent (only unencrypted mode is supported)
• Information received from SNMP agent

It does NOT provide:

• Discovery of network topology

Network discovery basically consists of two phases: discovery and actions.

Discovery

Zabbix periodically scans the IP ranges defined in network discovery rules. The frequency of the check is configurable for each rule individually.

Each rule has a set of service checks defined to be performed for the IP range.

Discovery rules are processed by the discovery manager. The discovery manager creates a job per each rule with a list of tasks (network checks). Network checks are performed in parallel by the available discovery workers (the number is configurable in the frontend per each rule). Only checks with the same IP and port are scheduled sequentially because some devices will not accept parallel connections on the same port.

The queue size of network checks is limited to 2000000 or 4 GB of memory approximately. If the queue becomes full then the discovery rule will be skipped and a warning message will be printed in the log. You may use the zabbix[discovery_queue] internal item to monitor the number of discovery checks in the queue.

Discovery checks are processed independently from the other checks. If any checks do not find a service (or fail), other checks will still be processed.

Every check of a service and a host (IP) performed by the network discovery module generates a discovery event.

Actions

Discovery events can be the basis of relevant actions, such as:

• Sending notifications
• Adding/removing hosts
• Enabling/disabling hosts
• Adding hosts to a group
• Removing hosts from a group
• Adding tags to a host
• Removing tags from a host
• Linking a template to hosts/unlinking a template from hosts
• Executing remote scripts

These actions can be configured with respect to the device type, IP, status, uptime/downtime, etc. For full details on configuring actions for network-discovery based events, see action operation and conditions pages.

Since network discovery actions are event-based, they will be triggered both when a discovered host is online and when it is offline. It is highly recommended to add an action condition Discovery status: up to avoid such actions as Add host being triggered upon Service Lost/Service Down events. Otherwise, if a discovered host is manually removed, it will still generate Service Lost/Service Down events and will be recreated during the next discovery cycle.

Host creation

A host is added if the Add host operation is selected. A host is also added, even if the Add host operation is missing, if you select operations resulting in actions on a host. Such operations are:

• enable host
• disable host
• add host to a host group
• link template to a host

Created hosts are added to the Discovered hosts group (by default, configurable in Administration > General > Other). If you wish hosts to be added to another group, add a Remove from host groups operation (specifying "Discovered hosts") and also add an Add to host groups operation (specifying another host group), because a host must belong to a host group.

The IP address of the discovered device, together with the discovery source (Zabbix server, Zabbix proxy, or proxy group) and the interface type, is used as the criterion for finding a host in the system. If a host with the same IP address, interface type and discovery source already exists, that host will be the target for performing operations. If the discovery source differs, the discovered entity is treated as a different host and a new host may be created.

If the IP address of the discovered host is changed or the interface is deleted, a new host will be created upon the next discovery.

Host naming

When adding hosts, a host name is the result of reverse DNS lookup or IP address if reverse lookup fails. Lookup is performed from the Zabbix server or Zabbix proxy, depending on which is doing the discovery. If lookup fails on the proxy, it is not retried on the server. If the host with such a name already exists, the next host would get _2 appended to the name, then _3 and so on.

It is also possible to override DNS/IP lookup and instead use an item value for host name, for example:

• You may discover multiple servers with Zabbix agent running using a Zabbix agent item for discovery and assign proper names to them automatically, based on the string value returned by this item
• You may discover multiple SNMP network devices using an SNMP agent item for discovery and assign proper names to them automatically, based on the string value returned by this item

If the host name has been set using an item value, it is not updated during the following discovery checks. If it is not possible to set host name using an item value, default value (DNS name) is used.

If a host already exists with the discovered IP address and the discovery source (Zabbix server, proxy or proxy group) has not changed, a new host is not created. If the discovery source differs, the discovered entity is treated as distinct and a new host may be created. However, if the discovery action contains operations (link template, add to host group, etc), they are performed on the existing host that matches by IP address, interface type and discovery source.

Host removal

Hosts discovered by a network discovery rule are removed automatically from Monitoring > Discovery if a discovered entity is not in the rule's IP range any more. Hosts are removed immediately.

Interface creation when adding hosts

When hosts are added as a result of network discovery, they get interfaces created according to these rules:

• The services detected - for example, if an SNMP check succeeded, an SNMP interface will be created.
• If a host responded both to Zabbix agent and SNMP requests, both types of interfaces will be created.
• If uniqueness criteria are Zabbix agent or SNMP-returned data, the first interface found for a host will be created as the default one. Other IP addresses will be added as additional interfaces. Action's conditions (such as Host IP) do not impact adding interfaces. Note that this will work if all interfaces are discovered by the same discovery rule. If a different discovery rule discovers a different interface of the same host, an additional host will be added.
• If a host responded to agent checks only, it will be created with an agent interface only. If it would start responding to SNMP later, additional SNMP interfaces would be added.
• If 3 separate hosts were initially created, having been discovered by the "IP" uniqueness criteria, and then the discovery rule is modified so that hosts A, B and C have identical uniqueness criteria result, B and C are created as additional interfaces for A, the first host. The individual hosts B and C remain. In Monitoring > Discovery the added interfaces will be displayed in the "Discovered device" column, in black font and indented, but the "Monitored host" column will only display A, the first created host. "Uptime/Downtime" is not measured for IPs that are considered to be additional interfaces.

Changing proxy setting

The hosts discovered by different proxies are not always treated as different hosts. Discovery and uniqueness checks depend on the proxy group structure: when a proxy runs a discovery rule and creates a host, that host is added to the proxy's parent proxy group, not assigned to the proxy itself. When Zabbix evaluates IP uniqueness during discovery, it checks hosts monitored by the parent proxy group. Hosts monitored by individual proxies within that group (including the proxy that ran the discovery) are ignored for the uniqueness check, which can result in duplicate hosts if multiple proxies monitor overlapping subnets.

While this behavior allows discovery to operate across overlapping IP ranges used by different subnets, changing the proxy assigned to an already monitored subnet is more complicated because proxy changes must be applied consistently to discovered hosts and to the membership of the parent proxy group to avoid duplicates.

For example the steps to replace proxy in a discovery rule:

1. disable discovery rule
2. sync proxy configuration
3. replace the proxy in the discovery rule
4. replace the proxy for all hosts discovered by this rule (ensure hosts in the parent proxy group and any hosts monitored by individual proxies in that group are updated to avoid duplicates)
5. enable discovery rule