| To: | Mark Goodwin <mgoodwin@xxxxxxxxxx>, PCP <pcp@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: [pcp] RFC: derived metrics in PCP archives |
| From: | Ken McDonell <kenj@xxxxxxxxxxxxxxxx> |
| Date: | Fri, 4 Dec 2015 10:07:31 +1100 |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <5660C64B.3030408@xxxxxxxxxx> |
| References: | <5660B237.7000709@xxxxxxxxxxxxxxxx> <5660C64B.3030408@xxxxxxxxxx> |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
G'day Mark. On 04/12/15 09:46, Mark Goodwin wrote: On 12/04/2015 07:20 AM, Ken McDonell wrote: ... 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? ... pmlogger _could_ (but does not currently) know that the metric is derived ... but it has no way (nor does any other PMAPI client) to determine the operand metrics involved in the expression defining the derived metric. It is less intrusion to fix pmlogger than to add API support to return metrics used to define a derived metric. If the derived metric definition is unchanged, then replay would produce the same results as live. If the derived metric definition was subject to change, you have no choice but to log the operands, not the derived metric. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [pcp] RFC: derived metrics in PCP archives, Mark Goodwin |
|---|---|
| Next by Date: | Re: [pcp] RFC: derived metrics in PCP archives, Nathan Scott |
| Previous by Thread: | Re: [pcp] RFC: derived metrics in PCP archives, Mark Goodwin |
| Next by Thread: | Re: [pcp] RFC: derived metrics in PCP archives, Nathan Scott |
| Indexes: | [Date] [Thread] [Top] [All Lists] |