[ZBX-4585] Discovery keeps adding deleted hosts Created: 2012 Jan 26 Updated: 2019 Aug 28 Resolved: 2019 Aug 28 |
|
| Status: | Closed |
| Project: | ZABBIX BUGS AND ISSUES |
| Component/s: | Server (S) |
| Affects Version/s: | 1.8.9 |
| Fix Version/s: | None |
| Type: | Incident report | Priority: | Critical |
| Reporter: | Attilla de Groot | Assignee: | Unassigned |
| Resolution: | Won't fix | Votes: | 4 |
| Labels: | discovery | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Linux Debian |
||
| Attachments: |
Screen Shot 2012-01-26 at 11.00.13 AM.png
Screen Shot 2012-01-26 at 11.00.23 AM.png
Screen Shot 2012-01-26 at 11.50.30 AM.png
Screen Shot 2012-01-26 at 11.56.18 AM.png
|
| Description |
|
For a period of time there were two hosts configured in my setup by the discovery rule. This all worked fine. These two hosts have now been taken out of production (and deleted from Zabbix), but the discovery rule keeps adding them again. The IP isn't reachable, snmp queries fail, yet it keeps adding the hosts and there is absolutely nothing there. I deleted the A-record and PTR record to see if that had anything to do with it, but that didn't change the situation (except that the Zabbix hostname is now the ip address). Please see attached screenshots for configuration information. attilla@zabbix:~$ ping 91.200.18.168 attilla@zabbix:~$ ping 91.200.18.138 attilla@zabbix:~$ dig a 91.200.18.138 ; <<>> DiG 9.7.3 <<>> a 91.200.18.138 ;; QUESTION SECTION: ;; ANSWER SECTION: ;; Query time: 0 msec attilla@zabbix:~$ snmpget -v 2c -c xxx 91.200.18.138 1.3.6.1 Timeout: No Response from 91.200.18.138. |
| Comments |
| Comment by richlv [ 2012 Jan 26 ] |
|
what are the action conditions ? what do these hosts have shown for them in monitoring -> discovery ? |
| Comment by Attilla de Groot [ 2012 Jan 26 ] |
|
All checks for these hosts are "red" in the monitoring -> discovery overview, except for the snmp OIDs that have never been available for that host, they are grey. (see added screenshot). I have 132 actions that might be applicable for this discovery rule. I've added a screenshot of this, but of course not all are visible. You can see rules for Slot1 and 2, but they continue until 32. |
| Comment by richlv [ 2012 Jan 26 ] |
|
my first suspicion is about the actions that match "down" state and try to unlink from templates - they might be the ones readding those hosts |
| Comment by Attilla de Groot [ 2012 Jan 26 ] |
|
Do you have any suggestion on how to do this differently? These hosts are switches with removable linecards. If a linecard is removed, the template has to be unlinked as well. |
| Comment by Mark Strey [ 2013 May 28 ] |
|
I have the same Trouble here and i figured out that this is happening because the "Received Values" from a passed successful discovery-cycle for this IP-Adress will not be removed from the Database when you delete a host with this IP. The next discovery-cylce will raise the configuration-actions again with "Discovery Status=Down" and the old "Received-values" (databasetable "dservices")for the discovered IP-Adress. I modified the configuration-actions to add a host only when the discovery-status is "up" or "Discovered". This solves the Problem. |
| Comment by Ronny M [ 2013 Oct 22 ] |
|
I have the same problem, but in my case it's already version 2.0.6. I can disable, clear/unlink templates and delete the host as much as I want but it keeps coming back. The eth1 interface is still live but the agent is not listening on it. The result is that the host is being added twice once with the fqdn and ip of eth0 (with right monitoring) and once with the fqdn and ip of eth1 with only puppet monitoring configured, but with monitoring status in error and items have nodata because it can't find an agent listening on the eth1 ip. |
| Comment by Vladislavs Boborikins (Inactive) [ 2019 Aug 28 ] |
|
Hello, Since this version of Zabbix is no longer supported, we've decided not to prioritize this bug for the near future and close the issue with "Won't fix" resolution. Please let us know if this decision should be reconsidered. Regards |
