On 05/15/2016 12:21 PM, Ken McDonell wrote:
On 15/05/16 08:22, Mark Goodwin wrote:
...
patch looks good - HOWEVER, thinking about this a bit more, ideally if
a pmlogger config (or pmlogconf config) asks for a derived metric to be
logged,
it should expand this and log the leaf operand metrics.
-1 from me.
pmlogger should continue to log derived metrics. If you don't do this, then
the archive
cannot be properly replayed unless you also carry around the derived metric
definitions.
Ok good point then, but there are nits
Then the user sends the archive off to someone else for analysis ... and "foo"
remains a complete mystery
... the archive only contains real.metric.a and real.metric.b.
I could argue that 'foo' may be a complete mystery in both cases - since the
derived
config is not logged. Perhaps we should log the derived configs in force at the
time
the log was created?in e.g. perhaps in pmcd.pmlogger.derived ?
Also - should we suppress the warnings when a log containing derived metrics is
replayed
on a machine that has those same derived metrics defined too? e.g. :
# echo 'log mandatory on 2 sec { disk.dev }' | pmlogger -s 6s disks
# pmrep -a disks disk.dev.util
Warning: disk.dev.await: derived name matches metric 511.2048.3: derived ignored
Warning: disk.dev.r_await: derived name matches metric 511.2048.4: derived
ignored
Warning: disk.dev.w_await: derived name matches metric 511.2048.5: derived
ignored
Warning: disk.dev.avg_qlen: derived name matches metric 511.2048.6: derived
ignored
Warning: disk.dev.avg_rqsz: derived name matches metric 511.2048.7: derived
ignored
Warning: disk.dev.util: derived name matches metric 511.2048.8: derived ignored
d.d.util
sda
N/A
N/A
N/A
2.148
2.148
# PCP_DERIVED_CONFIG= pmrep -a disks disk.dev.util
d.d.util
sda
N/A
N/A
N/A
2.148
2.148
|