Same here, it’s only a 3800 stack which seems to be affected, both 15.18.0013 and 16.02.0022m.
We came from 15.12.0010 which didn’t seem to have the issue, but I haven’t gone back as it’s one of our core switches.
It’s weird as if you query the OID 1.3.6.1.4.1.11.2.14.11.5.1.9.6.1.0 it shows the correct value, and running a debug discovery as above seems to suggest that it’s getting it’s data from there.
YAML Discovery Data: Array
(
[data] => Array
(
[0] => Array
(
[oid] => hpSwitchCpuStat
[num_oid] => .1.3.6.1.4.1.11.2.14.11.5.1.9.6.1.{{ $index }}
[type] => procurve-fixed
)
)
)
Data hpSwitchCpuStat: Array
(
[0] => Array
(
[hpSwitchCpuStat] => 9
)
)
Discovered LibreNMS\Device\Processor Array
(
[processor_id] =>
[entPhysicalIndex] => 0
[hrDeviceIndex] => 0
[device_id] => 163
[processor_oid] => .1.3.6.1.4.1.11.2.14.11.5.1.9.6.1.0
[processor_index] => 0
[processor_type] => procurve-fixed
[processor_usage] => 9
[processor_descr] => Processor
[processor_precision] => 1
[processor_perc_warn] => 75
)
SQL[SELECT * FROM processors WHERE device_id=? AND processor_index=? AND processor_type=? [163,“0”,“procurve-fixed”] 0.47ms]
.SQL[SELECT * FROM processors WHERE device_id=? AND processor_index=? AND processor_type=? [163,“0”,“procurve-fixed”] 0.33ms]
.SQL[SELECT * FROM processors WHERE device_id=? AND processor_id NOT IN (?,?) [163,73,73] 0.29ms]
SQL[DELETE T FROM processors T LEFT JOIN devices ON devices.device_id = T.device_id WHERE devices.device_id IS NULL 0.53ms]
Runtime for discovery module ‘processors’: 15.1600 seconds with 486480 bytes
SNMP: [5/14.95s] MySQL: [4/0.00s] RRD: [0/0.00s]