Uploaded image for project: 'ZABBIX FEATURE REQUESTS'
  1. ZABBIX FEATURE REQUESTS
  2. ZBXNEXT-5147

Zabbix LLD macro indexing and filtering doesn't work as intended

    Details

    • Type: New Feature Request
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 4.0.5
    • Fix Version/s: None
    • Component/s: Frontend (F), Server (S)
    • Labels:
      None

      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.

       

        Attachments

          Activity

            People

            • Assignee:
              zabbix.dev Zabbix Development Team
              Reporter:
              vaku Vadims Kurmis
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated: