pcp
[Top] [All Lists]

Re: [pcp] automatic derived metrics slowing down remote pcp clients, esp

To: Mark Goodwin <mgoodwin@xxxxxxxxxx>, "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Subject: Re: [pcp] automatic derived metrics slowing down remote pcp clients, esp. pmlogconf
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Sun, 15 May 2016 12:21:22 +1000
Cc: pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <13cab833-217d-a771-8deb-60ee5c23347f@xxxxxxxxxx>
References: <20160514193945.GC1418@xxxxxxxxxx> <d2f3f657-fe0b-c967-b7c0-e4603c9f5f9c@xxxxxxxxxx> <20160514220852.GD1418@xxxxxxxxxx> <13cab833-217d-a771-8deb-60ee5c23347f@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
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.

Consider

foo = real.metric.a + real.metric.b

user asks to log foo (potentially from a pmchart "record" operation, where the definition of foo may not be visible or obvious).

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.

<Prev in Thread] Current Thread [Next in Thread>