pcp
[Top] [All Lists]

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

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: [pcp] automatic derived metrics slowing down remote pcp clients, esp. pmlogconf
From: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Date: Sat, 14 May 2016 22:40:19 -0400
Cc: pcp developers <pcp@xxxxxxxxxxx>, mgoodwin@xxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5737DC21.6030509@xxxxxxxxxxxxxxxx>
References: <20160514193945.GC1418@xxxxxxxxxx> <5737DC21.6030509@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.4.2.2i
Hi -

> Therein lies a potential problem ... pmlogconf (or pmieconf) were
> only created to make the process of creating a pmlogger (or pmie)
> configuration file easier, and were never intended for frequent
> execution ... they are more in the "use once now and then" camp.
> [...]

For hosts where the configuration is fixed, sure, pmlogconf is
unnecessary (and can be disabled in pmmgr).  But IMHO the default case
would need to be tolerance of changes to sets of hosts and/or host
configuration, thus pmlogconf.


> and (worse) (b) generate _exactly_ the same pmlogger configuration
> file as the last time pmlogconf was run (for this host).

Heh, but how would we know, unless we run it? :-)

Hmmmmmm....  

Maybe save pminfo metric-lists from previous pmlogconf runs, and
assume that if the metric-list now is the same, reuse the previous
pmlogger.config.  So basically use the PMNS as a cache validation key.
Though we'd also need to hash in the pmlogconf input files, should
they change.  pmlogconf could implement such a cache internally.

- FChE

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