Hi Ken,
----- "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> wrote:
> ... And finally the stateful computation of
> delta(value) / delta(other_value) can only be sensibly done at the
> per-process level on the client side.
>
> So one could consider a derived metrics module to be an old SysV-style
> streams module that has a private configuration file and is inserted
> between a PMAPI client and the source of PCP metrics.
>
> I'd like some initial feedback on the following set of initial
> limitations and assumptions.
> 1. Only works for platforms with ELF binaries. I'm planning to use
> $LD_PRELOAD to optionally insert a DSO between the PCP client
> and libpcp.so to intercept calls and rewrite them as needed.
Hmm. That seems quite unwieldy (obviously, wont work on Windows too).
What's the rationale for that instead of working in libpcp directly?
> 2. Only guaranteed to work for the synchronous PMAPI variants.
> So for example I'll make pmLookupName() work, but invest no
> effort in the asynchronous pair pmRequestNames() and pmReceiveNames().
> As an aside does any know of a living user of these asynchronous
> interface extensions to the original PMAPI?
(Not that I know of... perhaps these can die. They are not implemented on
Win32 & AFAICT cannot be, so I would rather noone started using them).
> 3. Configuration file pathname comes via a new PCP environment
> variable, probably $PCP_DERIVED_CONFIG.
This seems unwieldy too.
Would it be feasible to go more for something that can be specified
all-at-once, and as a (easily identified) drop-in replacement for a
metric name (I assume these will be given "made-up" PMIDs by Lookup
Name?)? ... so maybe:
$ pmval 'expr: delta(kernel.all.pswitch) * 1000'
Or some other not-valid-as-metric-name keyword in place of "expr:" like
'derive:' or 'formula:' or 'infer:'. Or perhaps force them to be brace
enclosed, e.g.
$ pmval '(delta(kernel.all.pswitch) * 1000 + 42)'
Or perhaps require something with an assignment, like the optional pmie
syntax - "cputime = delta(simple.time.user) + delta(simple.time.sys)".
I have plans to revisit the pmchart metric selection process for gadgets
down the track, and it would be good to allow the metric selector dialog
to allow derived metric syntax too (even just if its as free form text),
whatever that syntax turns out to be... if it can be done "inline" like
this, without needing environment variables, temporary files, etc - that
would be great.
> 4. No recursive definitions. Each derived metric is an
> expression involving metrics that are NOT derived.
That seems fair enough.
cheers.
--
Nathan
|