> -----Original Message-----
> From: pcp-bounces@xxxxxxxxxxx [mailto:pcp-bounces@xxxxxxxxxxx] On Behalf
> Of Frank Ch. Eigler
> Sent: Friday, 17 April 2015 1:29 AM
> To: David Smith
> Cc: pcp@xxxxxxxxxxx
> Subject: Re: [pcp] JSON PMDA
>
> Hi, David -
>
> > [...]
> > That sounds good, except in the case where when the JSON PMDA was
> > started there were 3 JSON sources, and during the run a 4th was added.
> > Now the JSON PMDA gets restarted
>
> ... but according to normal practice, a "restarted pmda" means "restarted
> pmcd", which means active pcp contexts are dropped, which means clients
are
> to reconnect & recalculate name->pmid mappings.
I think we need to be a bit more careful.
Clients may or may not re-explore the PMNS in this situation ... I just
experimented with pmie and it does NOT do this. 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. I can think of a whole raft of changes that a PMDA
might make that are pretty sure to break one or more clients, e.g. change
metric semantics or units, change the semantics of an instance domain (so
"foo" is instance 0 now and instance "1" later on), ... and I think changing
the name --> pmid mapping falls into this camp.
But there is another class of issues around archives. pmlogextract (and
indeed anything that processes a set of archives that claim to be from the
same host) must assume that the PMNS and the metadata for the metrics are
consistent from one archive to the next.
In the PCP data model, an instance domain is the only metadata that is
timestamped and expected and allowed to change over time ... and even then
the changes are expected to be limited to "some instance(s) appear", "some
instance(s) go away", and if an instance re-appears it will have the same
external and internal instance ids.
Any PMDA that wishes to change it's metadata outside this envelope needs to
be careful. If the changes are rare and driven by extensions or bug fixes
to the code then most clients may see some oddness when the change happens,
and pmlogrewrite provides the bridge to smooth the transition for the
historical archives. If the changes need to be more frequent (because the
base data is dynamic) then we need to try and make the PMDA as temporally
consistent as possible, so that if object X exists some time ago and still
exists now, we are using the same PCP data (metrics and instances) to
describe X at both points in time.
>
> > In case the above isn't clear, let's say that on startup the JSON PMDA
> > sees the following sources:
> > bar (cluster #1), foo (cluster #2), zoo (cluster #3) Then the
> > following gets added:
> > dog (cluster #4)
> >
> > Then the PMDA gets restarted. A sort of the pathnames would give:
> > bar (cluster #1), dog, (cluster #2), foo (cluster #3), zoo (cluster
> > #4)
I think you'd want to avoid the "sort" here if possible, so bar stays
cluster #1 (I assume this is the cluster component of the PMID).
And in this context, the sort of extension to the pmdaCache services being
discussed yesterday might provide a means to maintain a persistent "name" to
"id" map where the "id" values are constrained to the range that would work
for a pmid's cluster component.
> Yes, or the same sort of thing (for pmid "instance" numbers) if the
contents of
> the metadata files change across a pmda/pmcd restart. Or if the indoms
inside
> the data files drastically.
As I said above, indom's are special and treated differently).
|