cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

FEATURE REQUEST - Showing the correct used percent of Linux FileSystems using Net-SNMP

FEATURE REQUEST - Showing the correct used percent of Linux FileSystems using Net-SNMP

Note: These request is related to case 352423.

When monitoring Linux Filesystem using Net-SNMP with Orion, the used percent that it shows is lower than real used percent.

The situation is that GNU/Linux systems (and the like) generally have a reserved block, which is (generally) by default 5%. The reserved block is inaccessible for common use and reserved for system (for it's safety should the disk run out of space). Because the reserved block is not generally accessible it's often excluded from the reported used space. This results in slightly awkward reporting of disk space usage.

For example, this is what Orion shows: (see picture "filesystem in Orion.png" attach)

And these is what shows the Linux server using the df-k command:

Filesystem                                        1K-blocks            Used                     Available            Use%    Mounted on

/dev/mapper/vg00-usr                1523568               1114532               330400                 78%       /usr

Now the tricky part is that the standard SNMP hrStorage OID only provides Size and Usage, but not the available space. And if you don't know which percent is used as inodes space (reserved block), you can't calculate the available space.

Anyway, in a previous case that we have opened (Case 308578), SolarWinds Technical Support Team told as that for Linux using net-snmp, Orion takes some metrics using OIDs different from standards.

For example, to obtain the CPU Utilization they said the following to as (see the email attached):

For Net-SNMP, Orion uses OID= 1.3.6.1.4.1.2021.11.11.0 to search for Cpu Idle.

The OID = hrProcessorLoad  1.3.6.1.2.1.25.3.3.1.2. is for Windows and Generics.

And for FileSystems, Linux using net-snmp also has an enterprise mib that gives all the information that doesn’t show the standard as you can see in the picture attached (dskPercent.JPG)

We know that we could obtain these metrics using Universal Device Poller but that solution has two problems:
• The first and less important: We are not using APM together with NPM so we don’t have UnDP in the Orion server with APM.
• Second: We would like to have all servers monitored in the same manner. It’s more simple to administrate and more simple for users to see the information. We don’t want to have volumes of Linux servers monitored in one manner and volumes of Windows servers in another way.

We want to have an unified view and we would like to see all Volumes in the same manner, not some using the default view of Orion for Volumes and another using the custom poller view. (see picture "filesystems.jpg" attach).

According to Orion description, it supports Linux monitoring and we think that as you could obtain the CPU Idle from an enterprise mib for Linux using net-snmp, you could also obtain the FileSystems from an enterprise OID like UCD-SNMP-MIB:dskPercent (OID: 1.3.6.1.4.1.2021.9.1.9).

We think that as Orion shows CPU, Memory and Volumes in the same manner for all devices but obtains these metrics from different OIDs depending on which type of device is, it would be great if Orion can solve these problem from his side and shows as the correct information all in the same manner despite of how Orion obtains the metric.

I hope we could see these problem solved in a future release.

Best Regards,

Diego Mole

Tenaris Argentina

17 Comments
Level 20

I'm using the linux agent from SW for all my linux now... it works great and covers most everything.

Level 11

This seems to work properly on Red Hat 7.5, our older Red Hat 6.10 and Suse 11 servers still have this issue and it is annoying.

Level 11

What is the point?  This is a HUGE pain for some of us and has been a suggestion for 6 YEARS!  And look at all the votes!  Obviously voting for these "feature requests" does nothing.

Product Manager
Product Manager

After consulting with my colleague, we've determined that the release of the linux agent addresses this long standing feature request. As a result I'm happy to close as implemented referencing his original post here: Linux Agent Deployment 

Level 9

In a simple deployment and test I found the agent numbers are way off as

well.

as an example:

/PS --> 53830283264bytes, or 50.13 GB

Agent reports: 47.58 GB

That is a difference of 2.55 GB!

/PS is 19% consumed

Agent reports 18% consumed

How, with a smaller reported overall size of the volume does the reported

consumption decrease as well?

No, I do not believe the agent is fully cooked either.

Product Manager
Product Manager

chisle​, what version of Orion Platform are you currently running, and have you opened a support case regarding this issue?

Level 9

6.8, and yes, I opened a case. I think we'll get it straightened out.