On Sat, Feb 7, 2009 at 3:20 PM, Peter Tribble <peter.trib...@gmail.com> wrote: > 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.
What I wanted to do initially was expose the data used by vmstat, mpstat, and fsstat -- I think the data being exposed is stable enough that we could do that. Possibly also include some ZFS arc data as well. I have an initial stab at a MIB that I wrote up Friday I could post this week (for discussion) if you think that would be useful, but I didn't want to get too deep into implementation for the discussion. _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
