Eric Schrock <eric.schrock at sun.com> said: >>> >>>On Fri, Jun 24, 2005 at 10:55:33PM +0100, Peter C. Tribble wrote: >>>> >>>> I wrote a java kstat browser, and I'm tempted to do the same for prtpicl >>>> (and maybe some of the other prt* commands), to make it easier to see the >>>> hierarchy and drill down into it. It's hard to wade through prtconf and >>>> prtpicl output (especially with -v on). >>>> >>> >>>On a further note, if you're willing to work on a complete libkstat JNI >>>interface, this could be extremely beneficial to Solaris. We're just >>>starting to really elevate Java to a first class participant in systemic >>>observability within Solaris. We have the DTrace JNI nearly finished, >>>and we're developing a SMF JNI interface as well. A kstat interface >>>would fill a very useful gap in this portfolio.
This is the one project I'm interested in doing right now. It's something I've been thinking of for a while, and I've spent a reasonable amount of time playing around with it. I can't lay claim to any great programming expertise, but it wasn't that hard to get a functional interface. So yes, I'm very interested in this and willing to work at it. There is an existing implementation of a JNI interface to libkstat in resource pools. The first decision would be whether to work with that or develop a completely independent interface. >>>I can imagine a tool which presents kstats in a heirachial manner on >>>regular intervals, and the user can click on one the kstats and transfer >>>to a DTrace view where we can see the kstats on a per-process basis. >>>This would obviously only work for those kstats covered by the vminfo >>>and sysinfo providers, but would be _incredibly_ cool, since it answers >>>the first two questions any administrator tendds to have: >>> >>> "What is happening to my system?" Which often extends to a network of a hundred or more interrelated systems, and it's the interactions between them that are interesting (hence my interest in network observability). A fairly common case I see is where a process on a client node has gotten into a wierd state (often a loop) and is making odd requests to an NFS server. Sometimes it's making a big (negative) impact on the fileserver; more often the server isn't impacted but the easiest way to spot it happening on the network is to look for the pattern on the server. >>> "Who is doing that to my system?" Absolutely. Although after a little while you get to have a list of the usual suspects ;-) >>>Assuming that the problem is due to a particular process, of course. >>>But you get the picture. -Peter Tribble MRC Rosalind Franklin Centre for Genomics Research http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
