On Fri, Feb 6, 2009 at 8:30 PM, Ben Rockwood <b...@cuddletech.com> wrote: > Jason King wrote: >> Doing some more digging, it appears that the number of performance >> metrics that can be viewed via SNMP on OpenSolaris is minimal. I am >> proposing a project that will enhance the number of metrics available >> via SNMP. Since SNMP is fairly widespread, it allows one to avoid the >> whole collector/recording problem -- there are many tools that can do >> this today with SNMP, so one can choose their favorite (instead of >> worrying about additional agents running on a box that might or might >> not work with OpenSolaris). >> >> I'd like the endorsement of the performance and/or sysadmin community >> (since there's a lot of overlap, I think either would be appropriate). >> >> I would suggest that it be limited to well know and relatively stable >> metrics initially (the type of data seen from the various *stat >> commands comes to mind), though it could be enhanced as time goes on.
I'm in favour. I agree that there's a gap in need of filling. I would like to see a slightly more evolved proposal to actually vote on. (As an aside, observability would seem equally relevant, but doesn't have any core contributors so doesn't count as an official community. Sigh.) > I would gladly stand behind this. > > One suggestion would be to create a generic pass-through that would > allow any Kstat be available via SNMP, with some type of control to > allow users to determine if or how much of the kstat tree is available > (perhaps by class, id, etc). Approaching the problem in this way allows > us to continue to focus on improving kstats for the purpose of data > access rather than managing the MIB separately. I think these are two separate projects. There was an ARC case recently for rpc.kstatd, which got withdrawn. I'm writing a remote kstat service as part of JKstat. I don't see random access to arbitrary kstats as being necessarily useful for an snmp client - it needs to have stronger guarantees as to the availability and meaning of the statistics than is typically the case. Which is another part of the puzzle really - looking through the kstats we have available to us, and maybe promoting the useful ones to more committed stability levels which could then be accessed via snmp. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
