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
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.
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.
It certainly could do, but for firewall and AJAX friendliness I'd vote
for wrapping it in HTTP, XML-RPC style.
most promising, especially if it can be made to speak the native wire
protocol to pmdc.
This would seem to argue for a stateful
archive-serving pmdc, or perhaps a archive-serving proxy, as in Greg's
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:
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
One abomination here was
that a PMDA could also be a client - and potentially query itself
Alternately, and this is a lot more risky, I'd add rate conversion and
time-averaging features to pmcd.