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.
The simple suggestion is to claim another domain, and in pmlogger dynamically map any
PMID of the form 511.*.* to <new>.*.*
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).
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?
Cheers
-- Mark
|