Cambium ePMP CPU usage not reporting correctly


I have LibreNMS monitoring a number of Cambium ePMP devices, and it appears the CPU usage for these devices is not being graphed correctly.

The OID returns CPU usage as an integer from 0-1000, divided by 10 to get 0-100% in 0.1% increments. From what I can see in the includes/polling/processors/ file, this doesn’t appear to be a poller issue (as the value is retrieved and the file specifies dividing it by 10) but when I view the graph in the UI, the data seems to be scaling from 0-1 instead of 0-100%?

The graph looks like this;


As you can see, it should be showing 48.3% CPU - but I get 483.54m, which is quite odd as this variable shouldn’t even have that many digits of precision…

Am I missing something obvious? I have discovery and poller runs behind those links on pastebin, but I suspect they’re not of much use.

This happens on two separate up-to-date LibreNMS instances, too. I had a brief look into the graphing code to see if I could see what’s going wrong or how to fix it, but I’ve not gotten anywhere - not enough PHP knowledge…

Output of validate.php;

Component | Version
--------- | -------
LibreNMS  | 1.30-73-g149857f
DB Schema | 204
PHP       | 7.0.22-0ubuntu0.16.04.1
MySQL     | 10.0.31-MariaDB-0ubuntu0.16.04.2
RRDTool   | 1.5.5
SNMP      | NET-SNMP 5.7.3

[OK]    Database connection successful
[OK]    Database schema correct


Quick follow-up, this appears to actually be an issue with RRD storage;

Here’s the RRDtool command being run for the graph;

rrdtool graph /tmp/PGkcifvosdxC8dRu  
-l 0 
-u 100 
--start 1502928000 
--end 1503014400 
--width 1728 
--height 492 
-c FONT#000000 
-c GRID#a5a5a5 
-c MGRID#FF9999 
-c FRAME#5e5e5e 
-c ARROW#5e5e5e 
-R normal 
--font LEGEND:8:DejaVuSansMono 
--font AXIS:7:DejaVuSansMono 
--font-render-mode normal 
COMMENT:'Load %               Now      Min      Max     Avg\l' 
LINE1.25:ds0#CC0000:'Processor      ' 

If I go pull the latest update from that RRD;

# rrdtool info processor-cambium-cpu-0.rrd
filename = "processor-cambium-cpu-0.rrd"
rrd_version = "0003"
step = 300
last_update = 1503014704
header_size = 3080
ds[usage].index = 0
ds[usage].type = "GAUGE"
ds[usage].minimal_heartbeat = 600
ds[usage].min = -2.7300000000e+02
ds[usage].max = 1.0000000000e+03
ds[usage].last_ds = "0.18"
ds[usage].value = 8.6367204000e-01
ds[usage].unknown_sec = 0

So maybe it IS a poller/data storage issue?

It’s just the poller

Processor Processor... Cambium CPU UsageSNMP[/usr/bin/snmpget -v2c -c COMMUNITY -OvQ -M /opt/librenms/mibs:/opt/librenms/mibs/cambium:/opt/librenms/mibs/cambium udp:HOSTNAME:161 CAMBIUM-PMP80211-MIB::sysCPUUsage.0]

It takes the 50 value and divides it by 100 instead of 1. That can be fixed in the processor polling file.

Interesting, I hadn’t caught that part of the poller run.

That’s actually what I needed - the poller appears to be taking the raw value, dividing it by 10, and then dividing it by 100 again.

In the raw value is retrieved and divided by 10 to give the actual value, but then divides whatever that file spits out by processor_precision;

Processor precision for the device is set to 100 in the database;

MariaDB [librenms]> SELECT * FROM processors WHERE device_id = '7'\G
*************************** 1. row ***************************
       processor_id: 6
   entPhysicalIndex: 0
      hrDeviceIndex: NULL
          device_id: 7
      processor_oid: CAMBIUM-PMP80211-MIB::sysCPUUsage.0
    processor_index: 0
     processor_type: cambium-cpu
    processor_usage: 1
    processor_descr: Processor
processor_precision: 100
processor_perc_warn: 75
1 row in set (0.00 sec)

This causes the value to be divided by 1000, all-up, which isn’t super helpful. Removing the division in the cambium-cpu file and setting processor_precision to 10 instead of 100 would resolve this, I think?

So that’s two changes, one in includes/discovery/processors/ to change the precision divider from 100 to 10, and one in includes/polling/processors/ to remove the division by 10.

With those changes made, discovery updated the DB;

Discover Processor: CAMBIUM-PMP80211-MIB::sysCPUUsage.0, 0, cambium-cpu, Processor, 10, 610, ,
SQL[SELECT COUNT(processor_id) FROM `processors` WHERE `processor_index` = '0' AND `device_id` = '7' AND `processor_type` = 'cambium-cpu']
.SQL[UPDATE `processors` set `processor_descr` ='Processor',`processor_oid` ='CAMBIUM-PMP80211-MIB::sysCPUUsage.0',`processor_usage` ='610',`processor_precision` ='10' WHERE `device_id`='7' AND `processor_index`='0' AND `processor_type`='cambium-cpu']

And the poller works too;

#### Load poller module processors ####
SQL[SELECT * FROM processors WHERE device_id = '7']
Processor Processor... Cambium CPU UsageSNMP[/usr/bin/snmpget -v2c -c '_cl38rnw_' -OvQ -M /opt/librenms/mibs:/opt/librenms/mibs/cambium:/opt/librenms/mibs/cambium CAMBIUM-PMP80211-MIB::sysCPUUsage.0]

RRD[update /opt/librenms/rrd/ N:14]
RRDtool Output: OK u:0.00 s:0.00 r:3.12
SQL[UPDATE `processors` set `processor_usage` ='14' WHERE `processor_id` = '6']

I notice most processor discovery definitions have a processor_precision of 1 set - is it considered better practice to put the division in the poller include file or changing processor_precision?

I’ve made a pull request for these two tiny changes here - this topic is nice and resolved now :slight_smile: