Odd duplicate resource / interface graphs being created

Has anyone else ran into some hosts having resource graphs created in a iface-macaddr format with an asterisk after them?

Like this

Gi0_22-0024c36a7396 (*)

This appears to be happening on some of our switches, Cisco and Juniper. If I look at SNMP interfaces they aren’t present but they show up on the resource graphs.

It would appear that this started at version 30? Is anyone else experiencing this?

it results in collectd being flooded with messages like;

2022-07-12 08:31:01,857 WARN  [Collectd-Thread-23-of-50] o.o.n.t.ThresholdingSetImpl: passedThresholdFilters: can't find value of ifSpeed for resource node[285].interfaceSnmp[Gi0_42-0023349e82aa]
2022-07-12 08:31:01,859 WARN  [Collectd-Thread-27-of-50] o.o.n.t.ThresholdingSetImpl: passedThresholdFilters: can't find value of ifSpeed for resource node[266].interfaceSnmp[Fa0_47-00254655f033]
2022-07-12 08:31:01,860 WARN  [Collectd-Thread-27-of-50] o.o.n.t.ThresholdingSetImpl: passedThresholdFilters: can't find value of ifSpeed for resource node[266].interfaceSnmp[Fa0_47-00254655f033]
2022-07-12 08:31:01,880 WARN  [Collectd-Thread-26-of-50] o.o.n.t.ThresholdingSetImpl: passedThresholdFilters: can't find value of ifSpeed for resource node[236].interfaceSnmp[et_0_0_23-544b8c42cdb0]
2022-07-12 08:31:01,880 WARN  [Collectd-Thread-26-of-50] o.o.n.t.ThresholdingSetImpl: passedThresholdFilters: can't find value of ifSpeed for resource node[236].interfaceSnmp[et_0_0_23-544b8c42cdb0]
2022-07-12 08:31:01,927 WARN  [Collectd-Thread-36-of-50] o.o.n.t.ThresholdingSetImpl: passedThresholdFilters: can't find value of ifSpeed for resource node[216].interfaceSnmp[ge_0_0_5-3c8ab0e5d008]
2022-07-12 08:31:01,927 WARN  [Collectd-Thread-36-of-50] o.o.n.t.ThresholdingSetImpl: passedThresholdFilters: can't find value of ifSpeed for resource node[216].interfaceSnmp[ge_0_0_5-3c8ab0e5d008]

Gaps are resolved, seemed to have been a loading issue in our Scylla cluster. But we still have these errors and errant resources appearing. I have not been able to trace their creation down yet.

The (*) denotes an interface-MAC combination that OpenNMS found on the node, but that appears to have been removed. I see it a lot on ephemeral virtual interfaces, which are destroyed when the VM that allocated them is destroyed.

That makes perfect sense, thank you. A rescan does not seem to remove them, is there a way to remove them from the resource list?

Depends on what persistence strategy you’re using. Newts, nope. rrd or jrobin, you can delete the corresponding directory under $OPENNMS_HOME/share/rrd/nodeId/ifName-MAC e.g.

[root@opennms ~]# ls -l /opt/opennms/share/rrd/snmp/3/
total 568
drwxrwxr-x. 2 root root    248 May 25 08:34 ath0_15-68d79a7760d7
drwxrwxr-x. 2 root root    248 May 25 08:34 ath0-68d79a7760d7
drwxrwxr-x. 2 root root    248 May 25 08:34 ath1-6ed79a7760d7
drwxrwxr-x. 2 root root    248 May 25 08:34 ath2_3000-72d79a7760d7
drwxrwxr-x. 2 root root    248 May 25 08:34 ath2-72d79a7760d7
drwxrwxr-x. 2 root root    248 May 25 08:34 ath4_15-68d79a7860d7
drwxrwxr-x. 2 root root    248 May 25 08:34 ath4-68d79a7860d7
drwxrwxr-x. 2 root root    248 May 25 08:34 ath5-6ed79a7860d7
drwxrwxr-x. 2 root root    248 May 25 08:34 ath6_3000-72d79a7860d7
drwxrwxr-x. 2 root root    248 May 25 08:34 ath6-72d79a7860d7
drwxrwxr-x. 2 root root    248 May 25 08:34 br0_15-68d79a7660d7

Gotcha, we’re Newts so that explains that. Thank you for the detail.

With Newts, there’s no way to delete data other than the global TTL, so unfortunately you’re stuck until those interfaces expire out from Cassandra / Scylla.

Yea, it’s all good, we’ll live with it, at least now I know what it is and so when I get asked it’s something that can be answered, thank you!