Ok. It's fixed now! 

On 22/02/2017 01:46:35, Adam Armstrong <adama@memetic.org> wrote:

I think these are just dupes due to some parser derp somewhere.

They don't seem to be messing with the real entities, so once we squash the bug they should just vanish.

Adam.

Sent from BlueMail

On 22 Feb 2017, at 00:07, Michael <obslist@smarsz.com> wrote:

We are also seeing this same issue on ASA firewalls.  Memory graphs appeared for

    cpu R0/0
    MEMPOOL_DMA

We don't have any ASR9Ks, but we do have some ASR1Ks and they are now showing memory graphs for

    Processor
    vpu R0/0

I haven't had the spare cycles to dig further into it yet...

Michael





On 21 February 2017 8:20:46 PM LHDT, Robert Williams <Robert@CustodianDC.com> wrote:

Hi,

Have there just been some changes to the ASR9k RAM detection? Suddenly
after the overnight svn up we are seeing this for all 9k chassis:

[cid:image001.png@01D28C23.56E5F220]

These 3 new items are in alarm. The “reserved” and “image” are filtered
from all other devices by existing config.php – but obviously no
brackets on these ones.

$config['ignore_mempool_string'][] = '(reserved)';
$config['ignore_mempool_string'][] = '(image)';

However, the ‘processor’ one is actually wrong as it seems to be using
the CPU0 usage but a strange maximum of 3.81GB instead of 7.81GB. I
can’t filter this out because it will drop all ‘processor’ types.

I remember something historic relating to this where the maximums were
showing as around 4GB even though there is 8GB installed and someone
(Adam?) found and sorted it. This may or may not be related though.

Cheers!

Robert Williams
Custodian Data Centre
Email: Robert@CustodianDC.com
http://www.CustodianDC.com

observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium