Congrats on the OGB seat. Good work on the tool. I haven't explored it properly yet, but it sounds good. I think the idea of getting everything automatically is great. We often find we need to examine a problem using X stats. "Oh, wait. We don't collect X." "Add X then, and hope the problem happens again." -- Seems a little backwards.
I think having a simple mechanism to map disks would be very good. Too many times, I had to do this manually to find what was really going on. When I finally (found time to) automated it, examining disk stats became much more useful and meaningful much more quickly. Unfortunately, that work was on someone else's dime, and I only have one x64 server at home now. Hard to replicate the many possible combinations I saw when working in a decent-sized shop. Rainer On 3/18/2010 2:29 PM, Peter Tribble wrote: > Some may remember a discussion where I was talking about replacing > sar by a simple archive-of-kstats. I've blogged about this here: > > http://ptribble.blogspot.com/2010/03/beyond-sar.html > > And I've also been working on enhancing jkstat to be able to handle > such forms of archival input. (The precise form of archival format isn't > really critical - all the changes to jkstat were to handle stepping through > a static set of archival data rather than data that was continually changing > in real time.) > > It works really rather well, although my java code to parse kstat -p > output is (ahem) rather slow. But that's an opportunity for optimization > or a better format rather than a problem with the concept. > > (There's other metadata that would be nice to have to create a complete > picture. For example, mnttab so that you can map fsstat output to a given > filesystem, or a map of disk names to translate sd0<-> c0t0d0. I'm not > sure how to handle that, or whether to consider it.) > -- Mind the Gap Web: http://www.dragonhearth.com Blog: http://chaos.dragonhearth.com
