# Metricbeat system.memory.actual.free - is it accurate?

**URL:** <https://discuss.elastic.co/t/metricbeat-system-memory-actual-free-is-it-accurate/80650>\
**Category:** Beats\
**Tags:** metricbeat\
**Created:** [March 30, 2017, 10:01am UTC](https://discuss.elastic.co/t/metricbeat-system-memory-actual-free-is-it-accurate/80650 "2017-03-30T10:01:21Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![simonl](https://avatars.discourse-cdn.com/v4/letter/s/f17d59/32.png) [@simonl](https://discuss.elastic.co/u/simonl)\
**Post date:** [March 30, 2017, 10:01am UTC](https://discuss.elastic.co/t/metricbeat-system-memory-actual-free-is-it-accurate/80650/1 "2017-03-30T10:01:21Z")

</div>

Hello,  
I want to replace all my home grown & Nagios plugins with the marvelous metricbeat, but I don't trust the Linux memory figures ie. I rely on avail memory to alert on when a system is going to swap.

For older kernels I use the values discussed here:

[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773)

For new ones I lazily

$ cat /proc/meminfo | grep Avail  
MemAvailable: 1996488 kB

but on the same system at the same time metricbeat shows, the below - can I trust the beat? 😉

"system": {  
"memory": {  
"actual": {  
**"free": 619864064,**  
"used": {  
"bytes": 3355496448,  
"pct": 0.8441  
}

---

<div class="post-metadata">

**Author:** ![andrewkroh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/andrewkroh/32/3784_2.png) [@andrewkroh](https://discuss.elastic.co/u/andrewkroh)\
**Post date:** [March 30, 2017, 2:42pm UTC](https://discuss.elastic.co/t/metricbeat-system-memory-actual-free-is-it-accurate/80650/2 "2017-03-30T14:42:58Z")

</div>

From looking at the library used by Metricbeat the value reported is

```
`system.memory.actual.free = MemFree + Buffers + Cached`

```

Source: [https://github.com/elastic/gosigar/blob/v0.2.0/sigar\_linux\_common.go#L55-L74](https://github.com/elastic/gosigar/blob/v0.2.0/sigar_linux_common.go#L55-L74)

The value reported on other operating systems take a similar approach.

Based on that commit message it sounds like Metricbeat could report a more accurate estimate if it used `MemAvailable`. And for older kernels it would need to do the calculation on it's own like you do with your Nagios plugin. Would you be interested in contributing the improvement to the [gosigar](https://github.com/elastic/gosigar) library?

> It is wrong because Cached includes memory that is not freeable as page  
> cache, for example shared memory segments, tmpfs, and ramfs, and it does  
> not include reclaimable slab memory, which can take up a large fraction  
> of system memory on mostly idle systems with lots of files.

---

<div class="post-metadata">

**Author:** ![simonl](https://avatars.discourse-cdn.com/v4/letter/s/f17d59/32.png) [@simonl](https://discuss.elastic.co/u/simonl)\
**Post date:** [March 30, 2017, 3:53pm UTC](https://discuss.elastic.co/t/metricbeat-system-memory-actual-free-is-it-accurate/80650/3 "2017-03-30T15:53:34Z")

</div>

Ay Up Andrew, thanks for your reply. I've seen 5 different fancy monitoring products show 5 different values for this. Servers start swapping and no one understands why. The truth is out there (or in the kernel) ...

At the moment I'm in the middle of pumping beats and nagios perf data into your cloud service in some kind of crazy monitoring face off; beats wins hands down in most cases up to yet. If I get some time I'll consider contributing in the future.

Cheers. Simon

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [April 27, 2017, 3:53pm UTC](https://discuss.elastic.co/t/metricbeat-system-memory-actual-free-is-it-accurate/80650/4 "2017-04-27T15:53:34Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.