[ZBX-19011] Zabbix discovering phantom hosts Created: 2021 Feb 12  Updated: 2021 Apr 20  Resolved: 2021 Apr 19

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Server (S)
Affects Version/s: 5.0.8
Fix Version/s: None

Type: Problem report Priority: Trivial
Reporter: Shane Arnold Assignee: Oleksii Zagorskyi
Resolution: Declined Votes: 0
Labels: discovery, discoveryrule
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File 10.39.25.110 - Disabled Host-1.png     PNG File 10.39.25.110 - No Discovery in 8 Days.png     PNG File image-2021-03-09-15-57-06-527.png     PNG File image-2021-03-09-15-57-42-130.png     PNG File image-2021-03-09-15-58-53-468.png     PNG File image-2021-03-09-15-59-37-865.png     PNG File image-2021-04-20-12-59-38-809.png     PNG File image-2021-04-20-13-00-41-990.png    

 Description   

Steps to reproduce:

  1. Discover a host using a Discovery Rule
    1. Discovery rule checks for IP range and Discovery Status = Up
  2. Add the host using a Discovery Action
    1. If <Discovery Rule>, Add Host, Add to Group
  3. Change the IP address of the host in your environment
  4. Delete the host from Zabbix

Result:

  1. Zabbix re-adds the host using the old IP address

Expected:

  1. Zabbix does not re-add hosts that are not discovered or contactable.

Screenshots

1) Device not discovered for over 8 days

2) Device having to be disabled by Administrators because of erroneous rediscovery.



 Comments   
Comment by Shane Arnold [ 2021 Mar 09 ]

Another instance repeated today;

IP: 192.168.10.36. Deleted this host from Zabbix

Zabbix shows it has not been detected using any checks in 4 months;

Yet it is still being added to Zabbix with appropriate actions;

The host definitely does not exist and does not respond to SNMP or ICMP;

Comment by Dmitry Krupornitsky [ 2021 Apr 19 ]

Dear Shane, 

As I got from your ticket, that can be a designed behavior. The host is still listed in "dhosts" and "dservices" tables in Zabbix database even after it is not discovered anymore so to preserve data for future actions. As you change IP address, you create a new host while the old one is disconnected. You may want to alter the database so to exclude offline hosts explicitly or suggest ZBXNEXT functionality to automatically purge entries for offline autodetected hosts.

Comment by Shane Arnold [ 2021 Apr 19 ]

Thankyou Dmitry,

So that I understand the functionality better, you're saying that a host that still exists in those two tables, although offline, will be actioned as if they were online, come next discovery check?

The issue I have reported here is that discovery actions are triggered for hosts that are offline.

Are there any conditions I can add to a discovery rule to only act on hosts that are online by a discovery check? I don't fully understand the Up, Discovered criteria and how they relate to the state of the hosts or discoverability.

A ZBXNEXT for purge on discovery down age sounds perfect, and in the meantime I might address it via SQL or API.

Thanks
Shane

Comment by Dmitry Krupornitsky [ 2021 Apr 20 ]

Dear Shane, 

As you may have an explicit rule for host removal, the Zabbix server needs to calculate the time passed since last host online 'event' to current time. Since you have not defined a rule for host removal, Zabbix server may consider them temporary offline. You may refer to this topic via link in manual: Host Discovery The tables mentioned are for that, an entries will be deleted from them ASAP the removal rule will take place on its condition. The host autoremoval (purge) is documented only for removal hosts that are not a part of discovery network.

Are there any conditions I can add to a discovery rule to only act on hosts that are online by a discovery check? I don't fully understand the Up, Discovered criteria and how they relate to the state of the hosts or discoverability.

So, if the host fulfills a "Discovery check" user-defined rule, it has a state of "Discovered" and "Up". So (lets say we're discovering hosts, not services, with fping/ping build-in utility), the following events will take place:

  • Host discovered - mostly first discovery
  • Host up - several successful discovery tests

A further scenario depends on your settings in "Update interval" and actions for discovered hosts. Let's say you did not discovered your host in 5 checks, each takes place in 10 minutes. Then you'll have 5 "Host lost" or "Host down" (All services of a host are 'down', consecutively) events, that can lead to one way of behavior (probably to notification). If there are any other event type for host/services, you may want to modify your actions as needed.

May be you got confused by 'discovery' and 'up/down' event terminology, so discovery - is a process, in which we iterate through all specified hosts and try to figure out their availability, while up/down - is an event, in which we judge what had happened to a host and what can be its status. You may substitute host to service, the aim is the same.

What I recommend you is to pay an extra attention to discovery rules you may have and try to define a host removal rule, which, I think, may help you. Please refer to manual link I enclosed above.

Comment by Shane Arnold [ 2021 Apr 20 ]

Thanks Dmitry for your very detailed response, I really appreciate your taking the time 😊

So I currently have two discovery actions which could cause this behaviour;

and

Am I right in understanding that my "Client" actions checking for SNMP/Agent for a given rule will result in the host being added due to the host still being in the dhosts table? And the actions for Service Type will result in the hosts being added due to the services being in dservices?

If I changed these actions to include "Discovery status = Up", and then deleted the host, would this then mean it won't add the device, because although the host and services exist in their respective discovery tables, the host is not Up at the time of the next discovery?

I have multiple Client actions for our managed clients, but the Service Type (and other checks like sysObjectID) are applied to service checks only

Kind Regards

Shane Arnold

Comment by Dmitry Krupornitsky [ 2021 Apr 20 ]

Dear Shane,

Just forget about tables, it is an internal structure of Zabbix, which can change at any time.

The first step you're writing about is to discover device, so you're looking for Zabbix agent and SNMPv2 agent. It means, that if any of these checks are true, we pass the discovered host to step 2 (actions) with Host Up event/status. A host is up if it has at least one active discovered service, the device is discovered and still responding to checks. So, if you pay an extra attention to Zabbix API, you'll see that discovery is a really straight-forward process. 

If I changed these actions to include "Discovery status = Up", would this then mean it won't add the device, because although the host and services exist in their respective discovery tables, the host is not Up at the time of the next discovery?

It only means it won't add a new device which is not up. All already added devices remain in their groups and can be removed manually or by the use of other rules. If hosts become not available by any reasons, they will remain there unless manually deleted or if there are some Action rules that would delete them based on conditions.

Generated at Fri Apr 04 15:58:58 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.