Hi, Ken -
On Sun, May 15, 2016 at 06:12:34PM +1000, Ken McDonell wrote:
> >>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
Yeah, considered that, but that can only be a heuristic. If a
sysadmin had good reason to believe that those files will have a fixed
lifetime of correctness, then she could probably eschew pmlogconf
entirely and just supply a hand-made conf file rotated at that
lifetime. If on the other hand the network contains unpredictable
changes, then any particular lifetime heuristic would risk being
out-of-date.
> >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
Could it be just one PMNS_NAMES PDU (pminfo -h HOST)? Hm, maybe not,
if pmprobe's value-fetch-attempt fails. OK.
> if it is _all_ available metrics from host X then PMDAs with a
> dynamic PMNS may trip this up.
You mean if the list varied from pmlogconf cache-hit pminfo time to
pmlogconf cache-miss pmprobe*85 time? Yes, that could be a problem.
Though the problem would be similar if the list varied between
pmlogconf time and pmlogger time.
- FChE
|