Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add percent_free to the API instead of only percent #234
I'm not going to redo the entire post, but from a forum post I made (https://support.nagios.com/forum/viewtopic.php?f=7&t=38822&p=186222#p186222) this is an inconsistency that may cause an order of magnitude problem for performance monitoring, capacity planning, threshold maintenance, and just plain head-banging-against-the-wall.
Here's the bottom line:
Nagios's default memory check is custom_check_mem which returns the % free memory. That's memory that is not in use by anything.
The problem is that memory on Linux systems can be in use by buffers and caches until it's needed for something else, and immediately reallocated with no penalty. So a better metric might be available memory; that is, memory that is available to applications.
NCPA's "api/memory/virtual/percent" node returns just that - the percent of memory that is available.
The problem is these two things are not the same, and are often 5% for custom_check_mem and 50% for NCPA's check. While still accurate, they are not the same thing. So switching from an NRPE-based memory check (with custom_check_mem) to an NCPA-based memory check (without changing anything else) is going to seriously upset anything that relies on the value being returned (warning, critical, SLA, etc).
Consider adding percent_free and percent_available to NCPA, and changing the default percent to be percent_free to match the default check, custom_check_mem. Both numbers can be easily calculated from the other available data.
I wanted this posted here to get more opinions, thanks for linking and posting on here.
First off, we cannot change the
I would not be against putting in a
I'd also like to point out that you can use the
Just a personal opinion at the end here. I'd argue that using the free percent (without buffer and cache as a part of it) is not a very good way to monitor memory usage. I do believe the user should be shown the data when the check is performed but since Linux loves eating up that free memory for cache and buffer there is no reason to ever think you only have < 10% free when in reality your apps have GBs of ram available. Why the
P.S. Looking at the
We can maintain backwards-compatibility by keeping
In this instance,
Make sense? It's late and I'm tired so my math might not be right, but the gist is "maintain back-compat while promising more logical names going forward".
If you need to maintain "percent" as "percent available" for backpat, that's fine, but I recommend something in API documentation that says it's not the same calculation as the "normal" custom_check_mem result.
I'm quite happy with specific strings for specific math. I prefer to know exactly what I'm getting anyway. Besides, all I care about is memory available to applications, or /percent_avail.
changed the title from
NCPA reports free available memory, not free unused memory (read why this is a problem)
[Linux] Add percent_free to the API instead of only percent
Jun 14, 2016
I believe this to be a mistake. The point of NCPA is to have one-stop shopping across all platforms for the same data, accessed through the same API. Now you're saying that I'll need to write a custom plugin that grabs the data from the API and calculates the used percentage by subtracting from one.
I understand where you are coming from, I do. But we already have multiple options to get the used amount, I am not sure how this relates. I am just not giving the exact percents of everything as API endpoints. You're right that it's supposed to be a one-stop shop which means it also should have the same values no matter what OS it's running on. Including the same calculations. I fail to see a reason why the below ways of finding memory are not sufficient. And of course, you can always just run the
Simplicity is the key here. Why make this more confusing than it needs to be? Getting the memory stats of a server already exists, and we cannot accommodate every request for an API endpoint or it would get messy really fast. Some ways to get the used memory amount of a server using NCPA:
I would say that the
The one thing that could be useful is making some sort of way to do math and whatnot on API endpoints without having to create a custom plugin to do that. However, due to the complexity in this based on the structure of NCPA I doubt it will happen until a larger re-write occurs.