Zabbix offers automatic network discovery functionality that is effective and very flexible.
With network discovery properly set up you can:
Zabbix network discovery is based on the following information:
It does NOT provide:
Network discovery basically consists of two phases: discovery and actions.
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.
If a discovery rule is changed during execution, then the current discovery execution will be aborted.
Every check of a service and a host (IP) performed by the network discovery module generates a discovery event.
Event | Check of service result |
---|---|
Service Discovered | The service is 'up' after it was 'down' or when discovered for the first time. |
Service Up | The service is 'up', after it was already 'up'. |
Service Lost | The service is 'down' after it was 'up'. |
Service Down | The service is 'down', after it was already 'down'. |
Host Discovered | At least one service of a host is 'up' after all services of that host were 'down' or a service is discovered which belongs to a not registered host. |
Host Up | At least one service of a host is 'up', after at least one service was already 'up'. |
Host Lost | All services of a host are 'down' after at least one was 'up'. |
Host Down | All services of a host are 'down', after they were already 'down'. |
Discovery events can be the basis of relevant actions, such as:
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.
Linking templates to a discovered host will fail collectively if any of the linkable templates has a unique entity (e.g. item key) that is the same as a unique entity (e.g. item key) already existing on the host or on another of the linkable templates.
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:
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 is the criterion for finding a host in the system. If a host with that IP address and interface type already exists, that host will be the target for performing operations.
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.
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:
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, a new host is not created. However, if the discovery action contains operations (link template, add to host group, etc), they are performed on the existing host.
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.
When hosts are added as a result of network discovery, they get interfaces created according to these rules:
The hosts discovered by different proxies are always treated as different hosts. While this allows to perform discovery on matching IP ranges used by different subnets, changing proxy for an already monitored subnet is complicated because the proxy changes must be also applied to all discovered hosts.
For example the steps to replace proxy in a discovery rule: