Re: [pcp] suitability of PCP for event tracing

[Greg Banks <gnb at evostor dot 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.