Nested LLD and master items

[jonybat]

Hi

Recently upgraded to 7.4, specifically to take advantage of the nested LLD feature. However, i am hitting a limitation that i dont quite understand yet.

Basically, is it expected to be able to select a master item (for dependent item) of an upper discovery level?

LLD0 > ITEM_A prototype that gets all data > dependent item of ITEM_A as discovery prototype (LLD1) > item prototype as dependent item of ITEM_A

There was some discussion about this in the feature ticket (https://support.zabbix.com/browse/ZBXNEXT-1527), but it seems to have faded

Thanks in advance for the input

[Bazoogle]

It's not clear to me if it's expected, but I believe it should be either fixed if it's a bug, or added as a feature if it isn't a bug. Though we need to know the expected behavior before we can either make a bug report or create a feature request.

[cyber]

I think you cannot use that "item a" prototype as source for next level discovery... you define nested discoveries separately (type nested)

[rigor]

I would also agree we should ask for a feature extension for that. Also, the first two ‘segments’ of the “LLD0 > ITEM_A prototype that gets all data > dependent item of ITEM_A as discovery prototype (LLD1) > item prototype as dependent item of ITEM_A” are already possible, I also would very welcome addition of the last one (ability to use parent level (LLD0) item prototype as a master item for the LLD1 discovered item prototypes.


That would cover a lot of use cases where some types of hosts can either contain or not contain items of a certain type. For instance, the same type of NGFW can run either as a hardware appliance or as a virtual machine. For example, we want to monitor the temperature of all firewalls we run; this usually goes through a single API request for all the sensors. If we have both VMs and physical appliances of them, would we setup a template with the normal master item for this API call, we would end up with it polling virtual machine-based firewall with no reason, as there will be no sensors in such a case - no any dependent items will be discovered, but master item will still run and put some load on the device. But, if we create the same master item via LLD0 prototype, it would be only created if at least one sensor is discovered on a device (easy to do right now), so we would avoid both unnecessary Zabbix proxy/server load on running useless API calls and the device we monitoring extra load on reporting empty data…Unfortunately, for now, also we can create the master item prototype in such a way, but can’t access it at a next nesting level discovery.

Sure, another straightforward solution to the same monitoring optimization issue involves creating the master item only once on the same discovery level, irrespective of the number of discovery array elements returned. But that is also not possible for now, as requires the same key to be served for the master item prototype, and that generates an error and skips discovery items processing for now.