FYI: it is one well know woraroud for this issue but it is only dirty hack :/
You can add alias key over which you can add second instance of the same for example agent key to be able use it in other LLD iterator.
Like:
In zabbix_agentd.conf. However this requires fiddling in agent cfg which I'm always trying to avoid by any cost.
With SNMP LLDs already is possible to have multiple LLDS with iterator the same key.
i have version of my IF-MIB template which has more than one LLD which is using "discovery[{#IFDESCR},IF-MIB::ifDescr,{#IFOPERSTATUS},IF-MIB::ifOperStatus]| and it works.
I should say that zabbix has no issue with such LLDs but it causes to much SNMP timeouts (as it makes snmp agent more busy and exposed on internal locking known issues) so I've decided to not push this template with such such adaptation to my git repo :-/
I've been trying to use this approach as kind of workaround on not be able to disable populating graphs and triggers in cases like using only if{in,Out}Octets without ifHC{In,Out}Octets or vice versa on some devices.
As I said on this occasion I've hit wall of the zabbix limitation to be able (transparently) aggregate some agent or agent less items when physically over interface like jmx, odbc or even agent type is possible to query multiple points in single request (in case SNMP using bulk queries).
Only IF-MIB has so many possibilities that some mechanism to stop populating some IF-MIB OIDs is needed to have flexible/universal MIB based template which only partially always will be used on most of the devices.
Nevertheless looks like more or less it is only limitation of the configuration.import() zabbix API rules and/ur rules which are used on create/modify LLD iterator keys.
You can add alias key over which you can add second instance of the same for example agent key to be able use it in other LLD iterator.
Like:
Alias=vfs.fs.discovery.inioes:vfs.fs.discovery
With SNMP LLDs already is possible to have multiple LLDS with iterator the same key.
i have version of my IF-MIB template which has more than one LLD which is using "discovery[{#IFDESCR},IF-MIB::ifDescr,{#IFOPERSTATUS},IF-MIB::ifOperStatus]| and it works.
I should say that zabbix has no issue with such LLDs but it causes to much SNMP timeouts (as it makes snmp agent more busy and exposed on internal locking known issues) so I've decided to not push this template with such such adaptation to my git repo :-/
I've been trying to use this approach as kind of workaround on not be able to disable populating graphs and triggers in cases like using only if{in,Out}Octets without ifHC{In,Out}Octets or vice versa on some devices.
As I said on this occasion I've hit wall of the zabbix limitation to be able (transparently) aggregate some agent or agent less items when physically over interface like jmx, odbc or even agent type is possible to query multiple points in single request (in case SNMP using bulk queries).
Only IF-MIB has so many possibilities that some mechanism to stop populating some IF-MIB OIDs is needed to have flexible/universal MIB based template which only partially always will be used on most of the devices.
Nevertheless looks like more or less it is only limitation of the configuration.import() zabbix API rules and/ur rules which are used on create/modify LLD iterator keys.
Comment