This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [pcp] suitability of PCP for event tracing


Greg Banks <gnb@evostor.com> writes:

> [...]
> 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") ?

You mean whether they may be needed only for filtering control, and
not for display?  I'm sure it's needed for display too - else a user
might not know what to filter on.


> 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.

Yeah.  OTOH if filtering needs to be done in an intermediate layer
like the PMCD or PMLOG* or PMPROXY, then tuple-wide data and its
operations would need to be more first-class, instead of being
smuggled in a PM_TYPE_STRING.


>>> 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.

Sure; that could be tackled later / orthogonally in principle.  But
since modern javascript appears to lack low level socket access APIs,
this may have to be done whether we like it or not.  (Or go Java.)


>> [...]
>> 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:

I can see how one could interpret filtering in the middle as
necessitating computing virtualized metrics, and that does seem
complicated, but I was not trying to get into that area.


> [...]  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.

OK, then it looks like we'd have at least a few separate pieces to
work on:

* extensions to the PMCD<->PMDA API/protocol to allow PMDAs to push
  event data, and corresponding extensions for PMclients<->PMCD

* teaching some of the existing clients to process such data

* a systemtap PMDA that listens to pmStore filtering/control instructions;
  probably using plain type STRING for JSON payload

* a PMCD<->XMLRPC bridge

* the web application itself


- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]