pcp
[Top] [All Lists]

Re: JSON PMDA

To: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Subject: Re: JSON PMDA
From: David Smith <dsmith@xxxxxxxxxx>
Date: Thu, 16 Apr 2015 10:21:12 -0500
Cc: Nathan Scott <nathans@xxxxxxxxxx>, pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <y0mfv80ubzj.fsf@xxxxxxxx>
References: <54F9F92D.4010202@xxxxxxxxxx> <448002717.7934024.1427683964254.JavaMail.zimbra@xxxxxxxxxx> <552699FE.7040801@xxxxxxxxxx> <2139482617.15593599.1428634701360.JavaMail.zimbra@xxxxxxxxxx> <552D6524.1030803@xxxxxxxxxx> <y0mfv80ubzj.fsf@xxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
On 04/15/2015 07:56 PM, Frank Ch. Eigler wrote:

... stuff deleted ...

> Even if it were desirable to work around pmlogextract shortcomings,
> this need not mean that there has to be a sophisticated or long-term
> uniqueness guarantee.  It may well be sufficient to make it likely
> that if pmcd is restarted, with no change to json metadata files, that
> the same numbers be produced.  That in turn could be handled
> straightforwardly by deterministic traversal of the json metadata
> files (such as by sorting by their pathnames).

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 and a simple sort of the pathnames
gives different cluster values.

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)

-- 
David Smith
dsmith@xxxxxxxxxx
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

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