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?
|