For an SNMP table with a multi-part index, use
SNMP Walk - OIDs as the instance discovery method. NetXMS walks the chosen column and uses the OID suffix — the entire composite index (e.g.
1.2,
2.1, ...) — as the instance name (docs (https://netxms.org/documentation/adminguide/data-collection.html#instance-discovery-methods)). You then reference that suffix in the DCI's OID via
{instance}.
Setup on the prototype DCI:
- Instance Discovery → Method: SNMP Walk - OIDs
- Base OID: a column that exists for every PSU — column 3 (name) works well: .1.3.6.1.4.1.47196.4.1.1.3.11.2.1.3
- Metric OID (the DCI itself): .1.3.6.1.4.1.47196.4.1.1.3.11.2.1.7.{instance}
{instance} is replaced with the composite suffix (e.g.
1.2) for each row, producing the correct per-PSU power OID.
For nice DCI display names, attach an Instance Discovery Filter Script that fetches the PSU name from column 3 at the same index and returns
[instance, name] — first element keeps the composite suffix for OID substitution, second populates
{instance-name} for the description (docs (https://netxms.org/documentation/adminguide/data-collection.html#instance-discovery-filter-script)).
Side note: the power-consumption OID in your message has an extra
.1 (
...11.2.1.1.7.x.y). If columns 1, 2, 3 are group/slot/name as you describe, the power column is
.1.3.6.1.4.1.47196.4.1.1.3.11.2.1.7.x.y — worth double-checking with
nxsnmpwalk before building the DCI.
Thanks for the help. I've got the instances discovering properly now. Thanks for spotting the power consumption oid not matching up with the base oid. When I checked it the base oid was wrong and the power consumption oid was right.