I am hoping there are solutions I am missing. Let me share my understanding and see if there are holes in it.
When one defines rules (at least through 2.4.6) you can put only one IP range in the rule, AND that range is then explored by only one discovery process. Thus if you have a large range (say a class B) and a number of checks that may need to time out, this can take just south of forever.
So to get quicker discovery, one might split the class B rule up into many pieces, maybe even 256 pieces, each with a class C to scan. This allows multiple discovery processes at once to scan the space. It's a bit tedious to do from the UI but possible.
HOWEVER, once you start having many rules, then the Action conditions related to specific checks become very difficult to manage. Say you had conditions for specific checks, e.g. did a check for a specific OID succeed or fail to determine which template to apply. Check specific conditions APPEAR to be linked to specific RULES, there is no way to apply one action (with conditions based on checks) to multiple rules. Yes, I realize one can apply SERVICE conditions, but not CHECK conditions. Right?
So if one has (say) 5 actions with CHECK specific conditions, and splits up a set of discovery rules into (say) 50 rules, you need to have 250 different actions to accommodate this, 5 for every rule.
What a pain! Or is it... is there a better approach?
At the moment I am working around some of these by using SQL to generate rules, an automated-clone provision that clones to different address space. But I'm realizing I probably need to propagate that cloning into the actions. I really hate using SQL for these things, but the API is just too darn tedious for set operations, and so far it is working.
But ... maybe I am misunderstanding the whole concept and there is a completely different paradigm?
When one defines rules (at least through 2.4.6) you can put only one IP range in the rule, AND that range is then explored by only one discovery process. Thus if you have a large range (say a class B) and a number of checks that may need to time out, this can take just south of forever.
Aside: I realize that one using tiny parts of a Class B should know WHICH parts were used, but realize that is not always the case or within the control of someone deploying zabbix.
So to get quicker discovery, one might split the class B rule up into many pieces, maybe even 256 pieces, each with a class C to scan. This allows multiple discovery processes at once to scan the space. It's a bit tedious to do from the UI but possible.
HOWEVER, once you start having many rules, then the Action conditions related to specific checks become very difficult to manage. Say you had conditions for specific checks, e.g. did a check for a specific OID succeed or fail to determine which template to apply. Check specific conditions APPEAR to be linked to specific RULES, there is no way to apply one action (with conditions based on checks) to multiple rules. Yes, I realize one can apply SERVICE conditions, but not CHECK conditions. Right?
So if one has (say) 5 actions with CHECK specific conditions, and splits up a set of discovery rules into (say) 50 rules, you need to have 250 different actions to accommodate this, 5 for every rule.
What a pain! Or is it... is there a better approach?
At the moment I am working around some of these by using SQL to generate rules, an automated-clone provision that clones to different address space. But I'm realizing I probably need to propagate that cloning into the actions. I really hate using SQL for these things, but the API is just too darn tedious for set operations, and so far it is working.
But ... maybe I am misunderstanding the whole concept and there is a completely different paradigm?