Hi guys,
----- Original Message -----
> On 12/04/2015 07:20 AM, Ken McDonell wrote:
> > This arises in the context of pmrep discussions, but is a more general
> > issue that has just come to light.
> >
> > Derived metrics are (by design) equivalent to real metrics above the PMAPI
> > interfaces ... they have a pmDesc and their values appear in pmResults and
> > neither the expression used to define the derived metric nor the operand
> > values at the time of a pmFetch are made visible.
> >
> > Derived metrics are assigned "special" PMIDs (domain field == 511 ==
> > DYNAMIC_PMID) and this is how all the PDU rewriting is done in libpcp.
> > For example the pmDesc for a derived metric comes from the expression tree,
> > not from an archive or pmcd, and when a pmFetch is done the PMID of a
> > derived metric must be replaced with the PMID(s) of the operands needed to
> > compute the derived metric value.
> >
> > All good so far.
> >
> > But pmlogger plays by the same rules, so if a derived metric appears in the
> > pmlogger configuration (or via pmlc control change), then the derived
> > metric (and its metadata) will be logged.
> >
> > So we end up with a PMID 511.*.* in the archive's metadata and in the
> > archive's pmResults ... kaboom! libpcp gets very confused trying to
> > handle this because it looks like a derived metric but behaves like a real
> > metric in the archive.
Ouch. :)
> > The simple suggestion is to claim another domain, and in pmlogger
> > dynamically map any PMID of the form 511.*.* to <new>.*.*
Makes sense.
Marko, from a pmrep config POV I guess for metrics with a "formula" we'd
want to ignore that formula (the derived metric spec, iow) if pmLookupName
succeeds on the metric name (which it would in this case for an archive,
but not in live mode).
> > Initially I thought <new> might be 510, but that may cause conflict with
> > some existing user PMDA, so I'm suggesting 384 (the end of the range
> > reserved for PCP PMDAs and well short of where we're up to so far).
A couple of alternatives - there are some free ranges earlier in the stdpmid
set, which we've begun reusing (24 would be the next - grep on "FREE SLOTS").
Another option might be to reuse the PMI_DOMAIN (245) for these metrics too?
> > Can anyone see a flaw in this logic?
>
> Ken, if a derived metric appears in a pmlogger config then can we just ensure
> the operands are logged
> rather than logging the derived metric itself? That would avoid the kaboom
> scenario wouldn't it? Then
> replaying derived metrics would be the same as live - they'd get re-derived
> by the same fetch code.
> Or am I missing something here?
That has the downside that the derived metrics spec would have to travel with
the archive, and be setup in the environment of any tool replaying it - which
would be sub-optimal from a user-experience POV I guess.
cheers.
--
Nathan
|