Thank you for your response. Just to be clear, you are stating that there is no way for Observium to calculate the amount of RAM being used without including the amount of RAM used by shared/buff/cache? The reason I ask is because we have alerts setup for the mempool_perc metric and a few of our systems hold a lot of RAM in shared/buff/cache which produces constant alerts even though the amount of RAM actually being used (excluding RAM in shared/buff/cache) is below the alert threshold.
You're reading the graph wrong. The second
like is "excluding cached, shared, buffers". The actual cached number is
towards the bottom of the legend.
It's functionally not possible to get the same data from SNMP that you
get from free, it just doesn't expose the numbers in the same way. There
is a lot of messy maths happening to try to approximate the free output
from the data we get from SNMP, but it never matches. I think we're
missing a value or two needed to calculate everything properly.
Long ago I was going to expose it with custom code, but the Linux kernel
changed the way it exposed the numbers a couple of times too, so I
didn't bother.
adam.
NGS Webmaster via observium wrote on 20/07/2023 17:43:
The memory plots appear to be
mislabeled in Observium. Below is a plot for one of our systems.
It reports that
32.19GB of memory is being used and that 5.67GB of memory is cached.
However when I run the free -h command on the system the values for
these fields are different.
This makes it
difficult to accurately monitor the memory usage and setup accurate
alerts for memory usage for systems.
Can this bug be fixed?
Our version information is below.