-
New Feature Request
-
Resolution: Unresolved
-
Minor
-
None
-
4.0.5
-
None
Steps to reproduce:
This is related to a very common situation, when dealing with low level discovery of Cisco and other vendor MIB OIDs.
- Suppose you want to discover Fans for Cisco Nexus 5000.
- I set up discovery rule as follows:
- discovery{#FAN_STATUS},1.3.6.1.4.1.9.9.117.1.4.1.1.1,{#ENTITY},1.3.6.1.2.1.47.1.1.1.1.7
- {#FAN_STATUS} 1.3.6.1.4.1.9.9.117.1.4.1.1.1 (cefcFanTrayOperStatus) - this is indexed by "entPhysicalIndex", means that output is like this:
.1.3.6.1.4.1.9.9.117.1.4.1.1.1.534 = INTEGER: 2 .1.3.6.1.4.1.9.9.117.1.4.1.1.1.535 = INTEGER: 2 .1.3.6.1.4.1.9.9.117.1.4.1.1.1.536 = INTEGER: 2 .1.3.6.1.4.1.9.9.117.1.4.1.1.1.537 = INTEGER: 2 .1.3.6.1.4.1.9.9.117.1.4.1.1.1.538 = INTEGER: 2 .1.3.6.1.4.1.9.9.117.1.4.1.1.1.539 = INTEGER: 2 .1.3.6.1.4.1.9.9.117.1.4.1.1.1.100000534 = INTEGER: 2 .1.3.6.1.4.1.9.9.117.1.4.1.1.1.100000535 = INTEGER: 2 .1.3.6.1.4.1.9.9.117.1.4.1.1.1.100000536 = INTEGER: 2 .1.3.6.1.4.1.9.9.117.1.4.1.1.1.110000534 = INTEGER: 2
, where the last number is entPhysicalIndex, ID of physical entity.
- Now where is the problem?
- We want to have item prototypes like this
Fan{#ENTITY} Status
Fan{#ENTITY} Speed (%)
Fan{#ENTITY} Speed (RPM)
, which makes sense, so that it is clear, where this fan is located, at which entity.
Not just unclear variants of Fan{#SNMPINDEX} which would produce unclear item names like: Fan[1000121] Status.
- The problem is that Zabbix for whatever reason decides that it should index ALL MACROs by the most largely indexed one MACRO, which is not how this should work.
Result:
In result I get all items like should be and working fine:
BUT, there is this thing for discovery rule, which should not even occur in this case:
This is shown because Zabbix tries to index ALL macros by a macro which has a larger index.
Expected:
The indexing should be made by the first element in discovery rule.