This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [pcp] suitability of PCP for event tracing
- From: Greg Banks <gnb at evostor dot com>
- To: Mark Goodwin <mgoodwin at redhat dot com>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, "systemtap at sources dot redhat dot com" <systemtap at sources dot redhat dot com>, "pcp at oss dot sgi dot com" <pcp at oss dot sgi dot com>
- Date: Thu, 2 Sep 2010 12:04:49 +1000
- Subject: Re: [pcp] suitability of PCP for event tracing
- References: <20100827153906.GD3185@redhat.com> <4C7A7DFE.2040606@internode.on.net> <20100831194941.GC5762@redhat.com> <4C7DF1E8.70107@redhat.com>
Mark Goodwin wrote:
On 09/01/2010 05:49 AM, Frank Ch. Eigler wrote:
For the static-pmns issue, the possibility of dynamic instance
domains, metric subspaces is probably sufficient, if the event
parameters are limited to only 1-2 degrees of freedom. (In contrast,
imagine browsing a trace of NFS or kernel VFS operations; these have
~5 parameters.)
PCP instance domains are traditionally single dimensional, though there
are a few exceptions such as kernel.percpu.interrupts. It's easy enough
to split multi-dimensional data structures out into multiple metrics with
a common instance domain.
Two comments.
Firstly, do you need to view the actual parameters involved when
fetching values, or just use those parameters for filtering purposes to
select some subset of all VFS operations (e.g. "show me read()s and
write()s to inode 12345 on /foo") ?
Secondly, there's a "convention" for encoding faux multiple-dimension
instance names, but it's really just a horrible hack for encoding an
arbitrary tuple as a single string, like awk does.
For the web-based frontend issue, yeah, javascript+svg+etc. sounds
most promising, especially if it can be made to speak the native wire
protocol to pmdc.
It certainly could do, but for firewall and AJAX friendliness I'd vote
for wrapping it in HTTP, XML-RPC style.
This would seem to argue for a stateful
archive-serving pmdc, or perhaps a archive-serving proxy, as in Greg's
old project.
Time averaging, aggregation and filtering were all ambitious aims
of the project Greg's talking about - I wonder if that code could
ever be resurrected and open sourced?
Euurgh, dear Lord nonono :(
Frank: that project didn't serve archives, it had a PMDA component which
presented new metrics which were rate converted and averaged versions of
existing metrics. This wasn't the best of ideas:
One abomination here was
that a PMDA could also be a client - and potentially query itself
for metrics(!)
Doing it again (the fourth time!), I would not try that particular stunt
again. Instead I would abandon all attempts at building a time machine,
push all the brains out to JS code in the browser, and create a very
simple stateless HTTP-to-PCP protocol bridge daemon to allow PCP data to
be shipped from pmcd to frontend code as either XML or JSON. Modern
browsers have sufficiently fast and functional JS engines that this is
now feasible.
Alternately, and this is a lot more risky, I'd add rate conversion and
time-averaging features to pmcd.
--
Greg.