[ZBXNEXT-9518] Support uneven OID depths in "SNMP walk to JSON" Created: 2024 Oct 02  Updated: 2025 Jan 30

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

Type: New Feature Request Priority: Minor
Reporter: user185953 Assignee: Valdis Murzins
Resolution: Unresolved Votes: 3
Labels: LLD, SNMP, lld, sensors
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

While trying to process sensor MIBs (eg ZBXNEXT-9517) I often run into situation where I need data from two tables.

$ snmpwalk -On -c foobar -v2c r1.brueve 1.3.6.1.2.1.31.1.1.1.1.4671
.1.3.6.1.2.1.31.1.1.1.1.4671 = STRING: "et-8/0/5"
$ snmpwalk -On -c foobar -v2c r1.brueve 1.3.6.1.4.1.2636.3.60.1.2.1.1.6.4671
.1.3.6.1.4.1.2636.3.60.1.2.1.1.6.4671.0 = INTEGER: -230
.1.3.6.1.4.1.2636.3.60.1.2.1.1.6.4671.1 = INTEGER: -146
.1.3.6.1.4.1.2636.3.60.1.2.1.1.6.4671.2 = INTEGER: -209
.1.3.6.1.4.1.2636.3.60.1.2.1.1.6.4671.3 = INTEGER: -265

Notice how table with interface names has one level (4671), but its sensors have two levels (4671.x).

 
Currently "SNMP walk to JSON" does not handle this in useful way:

Field name OID prefix Format
{#IFNAME}|1.3.6.1.2.1.31.1.1.1.1|Unchanged|
|{#SENSOR_VALUE}|1.3.6.1.4.1.2636.3.60.1.2.1.1.6|Unchanged|


[
{
"{#SNMPINDEX}": "4671.2",
"{#SENSOR_VALUE}": "-209"
},
{
"{#SNMPINDEX}": "4671.1",
"{#SENSOR_VALUE}": "-146"
},
{
"{#SNMPINDEX}": "4671.0",
"{#SENSOR_VALUE}": "-230"
},
{
"{#SNMPINDEX}": "4671",
"{#IFNAME}

": "et-8/0/5"
},

Unknown macro: { "{#SNMPINDEX}": "4671.3",
"{#SENSOR_VALUE}": "-265"
}
]



It would be more useful if shorted SNMPINDEX values get expanded and give this:


[
{
"{#SNMPINDEX}"}

,

Unknown macro: { "{#SNMPINDEX}"}

]




 Comments   
Comment by user185953 [ 2024 Oct 02 ]

Aaa. I really wish I can edit my issues. Table merged with code after it and I can't fix it

Field name OID prefix Format
{#IFNAME} 1.3.6.1.2.1.31.1.1.1.1 Unchanged
{#SENSOR_VALUE} 1.3.6.1.4.1.2636.3.60.1.2.1.1.6 Unchanged
Comment by user185953 [ 2024 Oct 02 ]

Current output of "SNMP walk to JSON":

[
  {
    "{#SNMPINDEX}": "4671.2",
    "{#SENSOR_VALUE}": "-209"
  },
  {
    "{#SNMPINDEX}": "4671.1",
    "{#SENSOR_VALUE}": "-146"
  },
  {
    "{#SNMPINDEX}": "4671.0",
    "{#SENSOR_VALUE}": "-230"
  },
  {
    "{#SNMPINDEX}": "4671",
    "{#IFNAME}": "et-8/0/5"
  },
  {
    "{#SNMPINDEX}": "4671.3",
    "{#SENSOR_VALUE}": "-265"
  }
] 
Comment by user185953 [ 2024 Oct 02 ]

It would be more useful if shorter SNMPINDEX values get expanded and give this:

[
  {
    "{#SNMPINDEX}": "4671.2",
    "{#IFNAME}": "et-8/0/5",
    "{#SNMPINDEX_ARRAY}": ["4671", "2"],
    "{#SENSOR_VALUE}": "-209"
  },
  {
    "{#SNMPINDEX}": "4671.1",
    "{#IFNAME}": "et-8/0/5",
    "{#SNMPINDEX_ARRAY}": ["4671", "1"],
    "{#SENSOR_VALUE}": "-146"
  },
  {
    "{#SNMPINDEX}": "4671.0",
    "{#IFNAME}": "et-8/0/5",
    "{#SNMPINDEX_ARRAY}": ["4671", "0"],
    "{#SENSOR_VALUE}": "-230"
  },
  {
    "{#SNMPINDEX}": "4671.3",
    "{#IFNAME}": "et-8/0/5",
    "{#SNMPINDEX_ARRAY}": ["4671", "3"],
    "{#SENSOR_VALUE}": "-265"
  },
  {
    "{#SNMPINDEX}": "4671",
    "{#IFNAME}": "et-8/0/5",
    "{#SNMPINDEX_ARRAY}": ["4671"]
  }
]
Comment by user185953 [ 2024 Oct 02 ]

Losing information that {#IFNAME} came from shorter OID (not {#SNMPINDEX}) is no problem,
because all discovered items need only full {#SNMPINDEX} to get freash monitoring values.

But if this turns out to be needed, I propose adding {#SNMPINDEX_ARRAY} that will have javascript array like [4671.3] instead of text like "4671.3".
Then users can select SNMPINDEX componets they need by JSONpath in LLD Macros tab.

Comment by user185953 [ 2024 Oct 02 ]

In UI this can work as "expand suffix if needed" checkbox on either on top of "SNMP walk to JSON" step or per each line.
Alternatively it can be "Target SNMPINDEX length" number input on top of "SNMP walk to JSON" if that is easier to implement.

Thank you!

Comment by user185953 [ 2024 Oct 11 ]

Here is javascript solution

target_depth = 1; // ZBXNEXT-9518 
try {
    var sensors = JSON.parse(value);
} catch (e) {
    throw "Failed to parse JSON of \"SNMP walk to JSON\".";
}

byDepth = [];
// Sort elements by depth and create SNMPINDEX_ARRAY
sensors.forEach(function (element) {
    index = element['{#SNMPINDEX}'];
    index_array = index.split('.');
    depth = index_array.length;
    if (byDepth[depth] == null) {
         byDepth[depth] = {};
    }  
    element['{#SNMPINDEX_ARRAY}'] = index_array;
    byDepth[depth][index] = element;
});

result = [];
// Go through elements from longest depth to target_depth
for(var depth = byDepth.length-1; depth >= target_depth; depth--){
    if (byDepth[depth] == null) {
        continue;
    }
    Object.keys(byDepth[depth]).forEach(function (index) {
        new_element = {};
        for(var sub_depth = depth-1, sub_index = index; sub_depth >= 1; sub_depth--){
            // Cut away last level from sub_index and merge to new_element
            sub_index = sub_index.replace(/[.][^.]*$/, "");;
            if (byDepth[sub_depth] != null) {
                Object.assign(new_element, byDepth[sub_depth][sub_index]);
            }
        }
        // Merge object itself last for correct SNMPINDEX and SNMPINDEX_ARRAY
        Object.assign(new_element, byDepth[depth][index]);
        result.push(new_element);
    });
}

return JSON.stringify(result);
Comment by Ken Buska [ 2025 Jan 30 ]

Thank you for this. I've been looking for a way to reference different SNMP tables but have common indices but perhaps one extends further. I'm working to determine if your JS script works in my case.

Generated at Wed Jul 02 09:26:42 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.