[ZBXNEXT-5147] Zabbix LLD macro indexing and filtering doesn't work as intended Created: 2019 Mar 28  Updated: 2019 Mar 29

Status: Open
Project: ZABBIX FEATURE REQUESTS
Component/s: Frontend (F), Server (S)
Affects Version/s: 4.0.5
Fix Version/s: None

Type: New Feature Request Priority: Minor
Reporter: Vadims Kurmis Assignee: Zabbix Development Team
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File image-2019-03-28-15-53-43-239.png     PNG File image-2019-03-28-16-00-07-007.png    

 Description   

Steps to reproduce:

This is related to a very common situation, when dealing with low level discovery of Cisco and other vendor MIB OIDs.

  1. Suppose you want to discover Fans for Cisco Nexus 5000.
  2. I set up discovery rule as follows:
  3. 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
  4. {#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.

  1. Now where is the problem?
  2. 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.

  1. 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.

 



 Comments   
Comment by Vadims Kurmis [ 2019 Mar 29 ]

When we set up a multi-macro discovery rule i.e:

discovery[{#FAN_SPEED},.1.3.6.1.4.1.9.9.117.1.4.1.1.1,{#ENTITY_NAME},1.3.6.1.2.1.47.1.1.1.1.7]

, then the first macro should be treated as a key-macro and the rest macros should be indexed only by the index of first macro OIDs.

That way only the required indexes would be processed for all specified OIDs in discovery rule.

And if the second macro OID has more elements, than the first key item, those would be automatically discarded and false-positive errors in zabbix would not be produced.

Comment by Edgars Melveris [ 2019 Mar 29 ]

Hello Vadims, I'm not sure this can be considered a bug. Sounds more like a feature request.

Because I believe it works as intended and could possibly break the existing workflow for some users.

I believe, that a better solution would probably be to let user choose from which OID the index should be taken, otherwise use all.

Comment by Vadims Kurmis [ 2019 Mar 29 ]

Hi Edgars,

Yes, that might brake existing workflow, if user has defined custom filters to fit in macro indexes.

And Yes, ability to select which OID the index should be taken from is a much more flexible solution.

Comment by Edgars Melveris [ 2019 Mar 29 ]

Ok, I've moved this to feature requests

Generated at Fri Mar 29 08:39:47 EET 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.