Re: systemtap GUI Requirements

["James Dickens" <jamesd dot wi at gmail dot com>]

On 5/2/06, Vara Prasad <prasadav@us.ibm.com> wrote:
> Ryan Morse wrote:
>
> > Hi-
> >
> > We have finished writing the systemtap GUI requirements document.  If
> > interested, please look over the pdf I attached.
> >
> > -Ryan
>
> Sorry for the delay in my review. This is a good start for the
> requirements, i think these requirements are a good basic building block.
> I have divided my comments into two sections general and specific
> comments to the doc.
>
> General:
> We need a section that specifies the h/w and s/w environment that is
> needed to install the GUI, for example this section lists if one needs
> to download Eclipse or not etc.
>
> I think we need to add a section called intended audience or customers,
> that should cover who all e.g. kernel developers, sysadmins etc. could
> use this and how would they benefit from the GUI vs the existing command
> line.
>
> If you look at what is the purpose of SystemTAP, it is a tool to do
> functional and performance analysis in a production environment in real
> time (realtime i meant here is almost instant to the happening of an
> event). The customer base for SystemTAP includes all the way from
> sysadmins to kernel developers. When i read through the document i got a
> feeling that the proposed requirements are to develop an IDE for people
> to develop systemtap scripts. This to me is useful but not really giving
> me a GUI interface for functional and performance analysis (which is the
> goal of systemtap).  In my view GUI should present a dash board of
> various resources in the system like memory, cpu, I/O, n/w, locks etc.
> Once i have that i should be able to kind of watch how resources are
> being used and should be able to freely drill down on any resource.  A
> similar view can be done for applications using the application specific
> tapsets behind the screens.
systemtap is the wrong tool for this job. This information is all
availible with current user land tools(sar, top, prstat, lockstat,
iostat, etc.) or at worst walking some /proc data structures. To make
this type of system to work with systemtap, you would need to start a
daemon that monitors these type of things from system boot.

Where systemtap will excell at is attaching your systemtap scripts to
one user or application and monitoring I don't know how well the
dashboard metaphore works when you need 3 or more of them to monitor 
users or tasks meaning multiple dashboards on the screen.

> For example if i have a high level question "my system is running low on
> memory", the GUI should let me drill down on which process is hogging
> the memory, once i figure out the process i should know be able to get
> the details of from what are all the different memory pools this process
> is allocating memory. Another related question i may have (which many
> times Linux customers run into on x86) is i am running out of lowmem,
> GUI should be able to let me find out who are all the top 10 consumers
> of lowmem. Similarly for locking i should be able to see who is holding
> what locks, what is the queue statistics (min, max, avg etc.) on various
> locks.
>
> GUI should use behind the screens systemtap and predefined scripts and
> tapsets to gather the data. GUI should generate various probe modules as
> needed to help user explore various system properties.  Unless a user
> explicitly would like to develop their own probe scripts the probe IDE
> interface should be mostly in the background. Hope this gives an idea of
> what my view of SystemTAP GUI for the wide customer base we are trying
> to serve.

a better use for the gui would to employ intelligence to better format
systemtap output and start and stop systemtap scripts as desired, The
application  if it see's a table of data being output it would be good
if the gui presented this in a spreadsheet type layout, and made it
easy to filter, sort, graph, and print min, max, and other statisical
data for the data perhaps make saying the formatted data in other
formats would be handy as well.

For the programmers or higher level sysadmin as I don't see too many
normal users writing systemtap scripts, C language isn't all that
common these days among normal users, wizzards would be a good
addition to an IDE, perhaps an addition to  elcipse or netbeans would
make it alot easier to develop systemtap code.

James Dickens
uadmin.blogspot.com

[snip]>
> bye,
> Vara Prasad