> -----Original Message-----
> From: Frank Ch. Eigler [mailto:fche@xxxxxxxxxx]
> ...
> > Clients may or may not re-explore the PMNS in this situation ... I
> > just experimented with pmie and it does NOT do this.
>
> That's unfortunate. (OTOH, in src/pmie/eval.c enable() / reconnect(), it
calls
> reinitMetric(), which does redo all the pmLookup* business; in what
scenario
> doesn't and cannot pmie do this?)
If a PMDA is installed/removed/restarted, this may (or may not) involve
losing the connection to PMCD ... the reconnect code in pmie is triggered
when the PMCD connection is lost ... so this won't help if the PMCD
connection is maintained while the PMDA is reconfigured.
> > Most clients that keep running when a PMDA or PMCD is missing have
> > been written with some assumptions about the consistency of metric
> > names and metadata across invocations of a PMDA. [...]
>
> Can you point at another example by any chance?
Sure ... pmchart, pmval, pmdumptext, pmlogger (and probably others) will all
fetch the pmDesc for a metric once and assume that does not change for the
life of their execution.
> This sounds like that single tool's limitation. (Certainly pmwebd is not
affected,
> and it looks like pmchart isn't either.) It would not be a big deal for
> pmlogextract to canonicalize the output PMNS as it goes along. (Similar
> canonicalization logic could come in handy for making brolley's
multi-archive-
> transparency project even more powerful.)
If it is a limitation it is in the archive format ... the PMNS is not
timestamped in the archive, so there is no scope for describing foo.bar is
PMID 1.2.3 now and foo.bar is 1.3.3 at some later point in time in the same
archive.
> ... But even such a cache is by nature temporary & lossy, so sooner
> or later those pmids will be mixed up again, and the tooling will have to
deal.
> Why not make the consumer tooling robust now?
I think this is may hinge on the timescale over which the changes (and
possible reuse) might occur ... and this all sounds like more reason to
invest in the effort to document what's expected here from a PMDA as I
foreshadowed in my earlier mail.
|