Greg Banks <gnb@xxxxxxxxxxx> 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
|