On Tue, Jun 19, 2012 at 5:53 PM, Matthew Dempsky <[email protected]> wrote: > [+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.
So I trekked out to the land of Wikipedia last night. I didn't realize that Net-SNMP was actually called UCD-SNMP before being renamed to what it is now. I think that explains why I thought the UCD-SNMP-MIB was so prevalent; any system that runs or implements Net-SNMP will (should?) implement the UC-Davis MIBs. And since snmpd isn't Net-SNMP, I can see how adding UCD-*-MIB to it may not be wanted. (I do still think it'd be useful to have, mainly because of just how widespread Net-SNMP's usage is.) >> * 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). Yes, you're correct, that was my mistake in trying to rush the email out. And yeah, I'm familiar with the many threads about how OpenBSD's load average numbers are different from other OSes, but I guess what I was thinking was that even if it is different, the values should still be useful for trending a particular system. For instance, if I have historical data that suggests that a server's 5-minute load average usually hovers between 0.45 and 1.0, and then I see that server's numbers jump to 13.5 for a sustained period, then it might be a good idea to see what's going on. > 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. To be honest, I haven't matched up what's in HOST-RESOURCES-MIB with what snmpd implements to know how it would compare to UCD-SNMP-MIB. I should do that. > 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. Other than all the *TXT values, it *seems* to map fairly well, but then I don't know all I need to know about that (hence the request for someone who knows memory/uvm to look it over). For a few of those attributes I perused Net-SNMP to see how they handled it, and then figured it out from there. I think the only one that's really different from Net-SNMP's Free/NetBSD implementation is memCached; they don't implement that on NetBSD. I took a stab that it would be the same value as what is reported as "Cache:" by top(1). >> * 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. For what it's worth, that last diff was mangled and won't apply by copy/paste. I need to resend it, but before I do I need to fix a few things--for instance, the renaming I did in the second diff was wrong. I'll resend when I get the nitpicks fixed. Thanks for looking! Seth
