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
_______________________________________________
observability-discuss mailing list
observability-discuss@opensolaris.org
