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

[Ken McDonell <kenj@xxxxxxxxxxxxxxxx>]

On 15/05/16 12:40, Frank Ch. Eigler wrote:
> 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? :-)
Why not simple rate limit? e.g. run pmlogconf for host X if (a) 
configfile does not exist, or (b) pmlogconf not run in the last XYZ for 
host X ... where XYZ is "10mins" or "hour" or "day" or "week" or ... 
some config option
> 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.
Seems like a bit of a sledge hammer ... collecting, saving and comparing 
the "metric-lists" may be more work than you're trying to save ... and 
where does the "metric-list" come from?  if it is _all_ available 
metrics from host X then PMDAs with a dynamic PMNS may trip this up.