[+joel] On Tue, Jun 19, 2012 at 2:11 PM, Seth Wright <[email protected]> wrote: > I kind of thought the UCD-SNMP-MIB was fairly standard and/or > widespread, but perhaps not?
HOST-RESOURCES-MIB is an RFC standard, which I assume gives it more stature than UCD-SNMP-MIB, but I honestly haven't used SNMP much in the last few years, so I'm not the best person to make a decision here. > * HR-MIB includes hrProcessorLoad which is a percentage-based value > for each CPU (if I'm reading the MIB right) for the one-minute > timeframe. UCD-SNMP presents 1-, 5-, and 15-minute aggregate values, > which may be more useful. I think you're referring to how UCD-SNMP-MIB exposes 1, 5, and 15 minute load averages, which are different from CPU utilization. In particular, it tends to be a common source of confusion among users because OpenBSD calculates load averages very differently than other operating systems (e.g., http://www.undeadly.org/cgi?action=article&sid=20090715034920&mode=expanded). You should be able to calculate 5 and 15 minute rolling averages in your SNMP monitoring software too. > * HR-MIB, under the hrStorage* attributes, includes free and used > values for memory, but doesn't get any more granular than that. > UCD-SNMP tries to break it down a bit further. That's valid, though I believe we could expose much more fine grained memory via HOST-RESOURCES-MIB too. E.g., buffer cache, kernel pool(9) and malloc(9) buckets, and so on. I'm not sure off hand if the memory groups in UCD-SNMP-MIB maps well to our VM system either, but I guess they all say they can be left out if the OS doesn't support the category. > * UCD-SNMP includes a bunch of CPU stats that I'm only starting to > look at (the third "blank graph" in my monitoring templates) that I > can't find in a walk against base snmpd. Those were going to be in > diff number next. These might be interesting, and it's data not exposed otherwise currently. The closest HOST-RESOURCES-MIB has is hrSWRunPerfCPU and hrSWRunPerfMem, but those don't track interrupt CPU usage. > So yes, I think it does provide some value over what's already in > there, but that's just the opinion of a guy scratching a proverbial > itch. Understood, I'm just trying to make sure the diff makes sense to be committed.
