On Tue, Feb 10, 2009 at 11:08 PM, Brendan Gregg - Sun Microsystems <bren...@sun.com> wrote: > G'Day Folks, > > On Tue, Feb 10, 2009 at 08:03:17PM +0000, Peter Tribble wrote: > [...] >> Create a net-snmp module that exposes well known Solaris performance >> metrics via SNMP. If possible, this will include presenting kstat >> metrics in a generic fashion via SNMP. > > Writing an SNMP agent to export kstats isn't too hard. What will be the hard > part is designing the MIB - picking which statistics should be exported, and > documenting them. Some challanges: > > 1) kstats aren't generally documented in the first place. > although the source code gives you a good idea what they are for. > > 2) kstats aren't generally a stable interface. > some end up generally stable as they are used by tools such as iostat > and vmstat, which have an expectation of stability. > > 3) customers don't need more numbers. > useful numbers, sure, but lets not export kstats just because they > are there. > > We could pick a small set of kstats that are most useful and document them, > and > the code to export them via SNMP will suggest that these are now supposed to > be stable. It's picking which kstats (or other statistic source) to use that > will be (or should be) tough. > > There may be too much 'making do' with which kstats kernel engineers leave > behind. I'd much rather we picked ideal statistics first, then saw if kstats > satisfied them - and added kstats if needed. > > To help pick useful statistics, we can list use cases. When designing the > DTrace IP provider (and others), I had written the end-user scripts before > completing the provider - which helped guide the design towards what was and > wasn't useful, and highlight what was missing (I stalled writing a few scripts > when I realized crucial data was missing - which I wasn't able to spot from > the design alone.) From there, if have use cases for statistics that don't > exist as kstats - we can then add the kstats! > > ... and if we start with what's needed instead of what Solaris provides, then > we may have a generic enough performance MIB to port to other systems. :)
Well what I wanted to start with is the data presented by the *stat commands (vmstat, mpstat, etc.). In most cases, they are just showing the difference between a number of kstats over a chosen time interval, which just happens to make the implementation a bit easier. Or to think of it another way, for the initial piece at least, the interface is the same metrics seen using the *stat commands (so to speak), the fact kstats are used in obtaining the numbers is an implementation detail. I think with that would address most of the stability concerns. If (as was suggested) we add the ability to present kstats in a more generic fashion (I think that would be in addition to the above piece), it would need to be in a way that if new kstats are added, or old ones deleted, the MIB would not need to be updated. I think everyone here knows that kstats are subject to change without notice. However if that's all that's available at the time, a working 'wrong' solution is better than a non-existant 'right' solution. As it is, the initial impetus for this was trying to do a basic compare box A to box B for work, to be able to do at least rudimentary evaluation for consolidation for zones. This means looking at historic data. Today the only bundled option is to parse the sar data. That is painful for a number of reasons (group that admins box B has sar collecting over different intervals, just manipulating the data in general is rather annoying and time comsuming, etc.) Going forward, one could write a bunch of custom scripts to run vmstat, mpstat, etc. and write them to a log or a database or a central server, or one could just avoid reinventing the wheel and just make them available via snmp. One round wheel is as good as another, so I don't feel the need to make another one :) _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
