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
I rewrote the pulling of NFS stat, at current there are 3 implementations :
The problem with the last option is, it depends on a script that does not always report the correct value's. Line 8 of /proc/net/rpc/nfsd on older systems (centos 6) reports nfsv2 stats, and on newer systems (centos 7, debian) nfsv3. These are similar but not exactly the same. Therefore I believe the collected data is faulty in allot of cases.
I used nfs-v3-stats as template to write nfs-server, this also makes it possible to later add nfs-client. (which is also relevant data)
So my personal opinion would be to official drop the second option and leave in nfs-v3-stats for users that trust that the data they collected are correct.
I rewrote it, but took another approach on storing the data, I let rrd do the calculation instead of doing it with a script. This means :
I do have a few remarks tho, where your advice would be helpful
If you would like to test this pull request then please run:
So I guess to answer your questions:
If they are truly never used then drop them.
I'd be happy for the split.
This seems if we don't know how much data we are getting back. A lot of the time this is why agent/snmp scripts are written.
Fair few travis issues that need fixing :)
When the "normal" poller runs it generates device/A.rrd instead of the device/app-nfs-server-default.rrd. the app-nfs-server-proc[2,3,4,4ops].rrd aren't generated either. While manually running
Shows the correct rrd creation/update.