[ZBX-16156] SNMP LLD creates duplicated items for "complex" indexes Created: 2019 May 22  Updated: 2020 Jun 03  Resolved: 2020 Jun 03

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Proxy (P), Server (S)
Affects Version/s: None
Fix Version/s: None

Type: Problem report Priority: Trivial
Reporter: Oleg Ivanivskyi Assignee: Vladislavs Boborikins (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File duplicates.png     XML File zbx_export_templates-9.xml    
Sprint: Sprint 52 (May 2019), Sprint 53 (Jun 2019)

 Description   

You have an SNMP device with this information:

.1.3.6.1.2.1.4.20.1.1.192.168.33.101 = IpAddress: 192.168.33.101
.1.3.6.1.2.1.6.13.1.3.192.168.33.101.22.192.168.33.1.54979 = INTEGER: 22
.1.3.6.1.2.1.6.13.1.1.192.168.33.101.22.192.168.33.1.54979 = INTEGER: established(5)

You would like to use "Interface 192.168.33.101(22): status" item name and monitor status for each discovered IP (i.e. established). It looks like this LLD should do the trick:

discovery[{#VALUE},1.3.6.1.2.1.6.13.1.3,{#IP},1.3.6.1.2.1.4.20.1.1]

It won't.

Steps to reproduce:

  1. Import attached template
  2. Configure snmpd on a Linux host
  3. Import template, link it and use "check now" for the LLD

Result:
2 items were created: see "duplicates" screenshot.

Expected:
One item with a correct name, key and OID should be created (i.e. NAME: "Interface 192.168.33.101(22): status", KEY: "status[192.168.33.101.22.192.168.33.1.54979]", OID: .1.3.6.1.2.1.6.13.1.1.192.168.33.101.22.192.168.33.1.54979)

 Comments   
Comment by Oleg Ivanivskyi [ 2019 May 22 ]

Zabbix 4.2.1

Comment by Aleksejs Sestakovs [ 2019 Jun 19 ]

Hi Oleg,

Thank you for the detailed description. In my understanding this behavior is expected. OIDs .1.3.6.1.2.1.4.20.1.1 and .1.3.6.1.2.1.6.13.1.3 have different indexes and therefore will not be grouped together during discovery:

 

{
   "data": [
      {
         "{#SNMPINDEX}": "192.168.33.101",
         "{#IP}": "192.168.33.101"
      },
      {
         "{#SNMPINDEX}": "192.168.33.101.22.192.168.33.1.54979",
         "{#VALUE}": "22"
      }
   ]
}

So the item created for "{#SNMPINDEX}": "192.168.33.101.22.192.168.33.1.54979" will not have any value for {#IP} macro resulting in "Interface {#IP}(22): status" item as shown in your screenshot. In the same manner the other item will not have any value for {#VALUE} macro. This behavior is described in the documentation:

A built-in macro {#SNMPINDEX} containing index of the discovered OID is applied to discovered entities. The discovered entities are grouped by {#SNMPINDEX} macro value. (...) If an entity does not have the specified OID, then the corresponding macro will be omitted for this entity.

Please correct me if I'm mistaken on this topic.

Comment by Vladislavs Boborikins (Inactive) [ 2019 Jul 26 ]

Hi, Oleg,

We still are waiting for your reply.

Regards,

Vladislavs

Comment by Vladislavs Boborikins (Inactive) [ 2020 Jun 03 ]

Unfortunately, we have not received your reply. With that in mind, we are closing the case. Please feel free to reopen the ticket if the problem persists.

Generated at Fri Apr 26 01:24:57 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.