Node Labels discovered using SNMP not applied correctly to foreign source

Description

My understanding is that Node labels are set based on a determinitic heirarchy, described here where a User Defined (U in nodelabelsource) label is persistent, and when not user-defined, re-scans follow the DNS, SMB, SNMP order and finally if there is no other source, the IP address is set.

In the case of a newly discovered node, this seems to work as expected (I did not test SMB) with reverse DNS providing an overriding value, and SNMP sysName being used when the service is present.

When extending this node label discovery process, to additionally place a node into a foreign source however, there appears to be a gap in this expected behavior as it relates to the SNMP sysName.

Using the following discovery definition as an example, discovered nodes that match the defined detectors and include ranges would be placed into the foreign source “UPS”.

This definition works as expected for discovery, and a discovered node matching the definition that does not have a DNS name is created in the OpenNMS inventory/database with a label set to its SNMP sysName. The node is also added to the “UPS” requisition in the case shown above. The problem however, is that in the requisition, the Node Label is set to the IP Address, instead of the SNMP sysName used in the OpenNMS dataabase. The result of this, is that if that requisition is re-synced, causing a re-scan, or if the node is manually re-scanned, the node label changes back to just the IP Address as the Node Label in the requisition overwrites the OpenNMS database as a ‘User Defined’ node label.

We can assume this is not the expected behavior, as when a DNS name is present for the same scenario, the Node Label in the requisition is set correctly to that DNS name. Subsequent re-scans or re-syncs of the requisition do not result in the Node Label being changed to the IP Address as the User-Defined label from the requisition was already set properly during the initial discovery.

One simple workaround is to put in place reverse DNS entries temporarily to match the SNMP sysName using /etc/hosts , or even better to use a policy script in the foreign source definition to lookup the SNMP sysName and correctly set the node label. If I had such a Groovy script I would post it here.

This issue may extend to SMB as well, but that was not tested.

Environment

Debian 11.11, postgresql-13

Acceptance / Success Criteria

None

Activity

Show:

Ian B MacDonald January 14, 2025 at 5:23 PM

Found these where sysName adpotion has been fixed in slightly different scenarios.

Details

Assignee

Reporter

HB Grooming Date

HB Backlog Status

Components

Fix versions

Affects versions

Priority

PagerDuty

Created January 14, 2025 at 5:04 PM
Updated February 7, 2025 at 3:36 PM