[Top] [All Lists]

Re: [pcp] suitability of PCP for event tracing

To: Mark Goodwin <mgoodwin@xxxxxxxxxx>
Subject: Re: [pcp] suitability of PCP for event tracing
From: Greg Banks <gnb@xxxxxxxxxxx>
Date: Thu, 2 Sep 2010 12:04:49 +1000
Cc: "Frank Ch. Eigler" <fche@xxxxxxxxxx>, "systemtap@xxxxxxxxxxxxxxxxxx" <systemtap@xxxxxxxxxxxxxxxxxx>, "pcp@xxxxxxxxxxx" <pcp@xxxxxxxxxxx>
In-reply-to: <4C7DF1E8.70107@xxxxxxxxxx>
References: <20100827153906.GD3185@xxxxxxxxxx> <4C7A7DFE.2040606@xxxxxxxxxxxxxxxx> <20100831194941.GC5762@xxxxxxxxxx> <4C7DF1E8.70107@xxxxxxxxxx>
User-agent: Thunderbird (X11/20090817)
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.


<Prev in Thread] Current Thread [Next in Thread>