I have had problems with CentOS 6.4, FreeBSD 8.4. The two environments are physical, however one of them is large (3,000 hosts) and the other is a lab with 10 hosts.

I have the same problem when editing after I added a new criterion the discovery did not add more hosts on the platform, tested five tests and the results were the same. to work around this case, I had to delete and create a new discovery.

It also happens with server and proxy setups.

this is likely related to the serial fashion discovery is performed in - server probably starts working on the discovery and then it takes a long time to get to the changed one.

not a bug as such, and i seem to recall there being an issue about doing discovery in a more parallel/split up fashion

*richlv,

The network was / 17 and made ​​several networks / 20. The problem was the same. Tested with two / 24 networks and had the same problem.
Explain to me a little more about what you mean to mount something more parallelized.

the idea is that currently a discovery process grabs one discovery rule and starts on it - like your /17 network. it goes through all ips with all checks sequentially. if you have 100 discoverer processes, it does not help - only one works on a rule at a time.

haven't tested, but most likely editing a rule will not be taken into account until previous processing is finished - which might be a long time.

as a test you can try to restart server and see whether that helps to pick up discovery rule changes.

additionally, if you have one discovery process and one huge subnet and one small, the discovery process will not process the small one as often as it might have to because it will be busy in that large subnet - which it processes fully before looking for anything else to do.

• richlv

Are understanding. You mean, no point having a discovery with very large and diverse range checks discovery. If you have 200 ips in this range and 4 Discoverys checks, it will run there for 4x, using only 1 work of discovery.

Ie, we need to further separate, not only do subnet, but also trying to separate the discovery checks.
Correct thinking?

Adding information:

From what i saw on zabbix_server/discoverer/discoverer.c, each ip is fully checked.
If discovery hits 10.0.0.3, it will perform all checks that rule has against that ip, and the move to the next..

It also will only stop working when it finishes. If you remove the discovery, will break it too, but im not sure if you disable will work.
Cloning works if you have a worker avaiable for the new discovery rule.

For it to update, only a restart will update the execution of existing discovery rule.

I will perform some tests with smaller /24 networks and update here how that works out.

One of the things that would solve most certainly would be the discovery by adding the equipment returns (sys.Name.0 (SNMP) and system.name (zabbix agent))

duplicates ZBX-3336