Datacollection is changing data that goes into the JRBs to the wrong value
Description
We have a current monitoring system setup on 1.10.3, and have created a test server on Redhat 7 and opennms 23.0.4. The MIBs that we were using on the old release are no longer working on version 23. One of them in particular that we were using for thresholds consistently puts the value of <v>+3.4717653463E18</v> for oid .1.3.6.1.4.1.29182.3.1.4.2.3.3 into the RRD file. The value when an snmpwalk is performed:
2019-05-15 12:59:01,151 DEBUG [Collectd-Thread-45-of-50] o.o.n.c.a.AbstractPersister: Persisting node[20].tgbNtpIndex[0].tgbNtpMaxError [.1.3.6.1.4.1.29182.3.1.4.2.3.3] = 0.000000 2019-05-15 12:59:01,151 INFO [Collectd-Thread-45-of-50] o.o.n.s.SnmpUtils: Value '0.000000' is entirely displayable but still meets our other checks to be treated as a proto-Counter64. This may not be what you want. 2019-05-15 12:59:01,151 DEBUG [Collectd-Thread-45-of-50] o.o.n.c.a.AbstractPersister: Storing attribute node[20].tgbNtpIndex[0].tgbNtpMaxError [.1.3.6.1.4.1.29182.3.1.4.2.3.3] = 0.000000 2019-05-15 12:59:01,151 INFO [Collectd-Thread-45-of-50] o.o.n.r.RrdMetaDataUtils: createMetaDataFile: creating meta data file /opt/opennms/share/rrd/snmp/20/tgbNtpIndex/0/tgbNtpMaxError.meta with values '{GROUP=tgb-snmp-ntp, SNMP_.1.3.6.1.4.1.29182.3.1.4.2.3.3.0=tgbNtpMaxError}' 2019-05-15 12:59:01,151 DEBUG [Collectd-Thread-45-of-50] o.o.n.r.j.JRobinRrdStrategy: createDefinition: filename /opt/opennms/share/rrd/snmp/20/tgbNtpIndex/0/tgbNtpMaxError.jrb already exists returning null as definition 2019-05-15 12:59:01,151 DEBUG [Collectd-Thread-45-of-50] o.o.n.r.j.JRobinRrdStrategy: createRRD: skipping RRD file 2019-05-15 12:59:01,151 INFO [Collectd-Thread-45-of-50] o.o.n.c.p.r.RrdPersistOperationBuilder: updateRRD: updating RRD file /opt/opennms/share/rrd/snmp/20/tgbNtpIndex/0/tgbNtpMaxError.jrb with values '1557939541:3471765346274258992'
This isn't what we want, but we can't figure out how to make it not change the values. I've attached our configuration to the case.
We have a current monitoring system setup on 1.10.3, and have created a test server on Redhat 7 and opennms 23.0.4. The MIBs that we were using on the old release are no longer working on version 23. One of them in particular that we were using for thresholds consistently puts the value of <v>+3.4717653463E18</v> for oid .1.3.6.1.4.1.29182.3.1.4.2.3.3 into the RRD file. The value when an snmpwalk is performed:
SNMPv2-SMI::enterprises.29182.3.1.4.2.3.3.0 = STRING: "0.000000"
The collectd.log shows:
2019-05-15 12:59:01,151 DEBUG [Collectd-Thread-45-of-50] o.o.n.c.a.AbstractPersister: Persisting node[20].tgbNtpIndex[0].tgbNtpMaxError [.1.3.6.1.4.1.29182.3.1.4.2.3.3] = 0.000000
2019-05-15 12:59:01,151 INFO [Collectd-Thread-45-of-50] o.o.n.s.SnmpUtils: Value '0.000000' is entirely displayable but still meets our other checks to be treated as a proto-Counter64. This may not be what you want.
2019-05-15 12:59:01,151 DEBUG [Collectd-Thread-45-of-50] o.o.n.c.a.AbstractPersister: Storing attribute node[20].tgbNtpIndex[0].tgbNtpMaxError [.1.3.6.1.4.1.29182.3.1.4.2.3.3] = 0.000000
2019-05-15 12:59:01,151 INFO [Collectd-Thread-45-of-50] o.o.n.r.RrdMetaDataUtils: createMetaDataFile: creating meta data file /opt/opennms/share/rrd/snmp/20/tgbNtpIndex/0/tgbNtpMaxError.meta with values '{GROUP=tgb-snmp-ntp, SNMP_.1.3.6.1.4.1.29182.3.1.4.2.3.3.0=tgbNtpMaxError}'
2019-05-15 12:59:01,151 DEBUG [Collectd-Thread-45-of-50] o.o.n.r.j.JRobinRrdStrategy: createDefinition: filename /opt/opennms/share/rrd/snmp/20/tgbNtpIndex/0/tgbNtpMaxError.jrb already exists returning null as definition
2019-05-15 12:59:01,151 DEBUG [Collectd-Thread-45-of-50] o.o.n.r.j.JRobinRrdStrategy: createRRD: skipping RRD file
2019-05-15 12:59:01,151 INFO [Collectd-Thread-45-of-50] o.o.n.c.p.r.RrdPersistOperationBuilder: updateRRD: updating RRD file /opt/opennms/share/rrd/snmp/20/tgbNtpIndex/0/tgbNtpMaxError.jrb with values '1557939541:3471765346274258992'
This isn't what we want, but we can't figure out how to make it not change the values. I've attached our configuration to the case.