pcp
[Top] [All Lists]

JSON PMDA (was Re: [pcp] PCP JMX PMDA)

To: Marko Myllynen <myllynen@xxxxxxxxxx>, Nathan Scott <nathans@xxxxxxxxxx>
Subject: JSON PMDA (was Re: [pcp] PCP JMX PMDA)
From: David Smith <dsmith@xxxxxxxxxx>
Date: Mon, 25 Apr 2016 11:58:05 -0500
Cc: pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5710CC97.5020209@xxxxxxxxxx>
References: <56D8858A.3020407@xxxxxxxxxx> <56F940C7.2080909@xxxxxxxxxx> <CF911C98-E061-46AF-A8DB-10A5361C413B@xxxxxxxxxx> <56FC0E5B.3040708@xxxxxxxxxx> <1847433648.36205882.1459557172304.JavaMail.zimbra@xxxxxxxxxx> <570AD655.7020108@xxxxxxxxxx> <1799198159.39292885.1460350959108.JavaMail.zimbra@xxxxxxxxxx> <570BC712.1080905@xxxxxxxxxx> <880763790.39521507.1460426029264.JavaMail.zimbra@xxxxxxxxxx> <5710CC97.5020209@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
On 04/15/2016 06:12 AM, Marko Myllynen wrote:
> Hi,
> 
> On 2016-04-12 04:53, Nathan Scott wrote:
>> ----- Original Message -----
>>
>>> With the JSON PMDA I think we can also have an acceptable compromise
>>> here (do it Right but still leave some rope on the floor for those who
>>> are tempted to shoot themselves in the foot or can't / don't want to
>>> generate complete metadata e.g. for in-house/proprietary components).
>>
>> +1

Sorry for the delay in responding here. I was away last week and didn't
see this email. I originally wrote the JSON PMDA (although I haven't
worked on it for awhile now), so I'll try to respond about the JSON PMDA
problems you saw.

> Oh, well, I think I was being overly optimistic here.. But perhaps (or
> even hopefully) some of the issues I'm listing below are due to my
> misunderstanding (see the previous README patch - the current README
> wasn't enough even to get a basic example working):
> 
> * (When *testing* metadata, deleting /var/lib/pcp/config/pmda/137*
> before each round may help to prevent some mysterious error messages)

Without seeing the "mysterious error messages", I'm afraid I don't
really know what the JSON PMDA was doing here.

> * In the non-array case metrics a.b.c and a.d.e work but a.b.f is
> silently omitted (so using a_b_c seems currently the only option)

I'm afraid you lost me here. Can you explain a bit more?

> * metadata.json updates are not picked up during JSON PMDA lifetime

Yes, that is true. As far as I know, that's fairly standard for PMDAs,
especially python ones.

> * JSON PMDA expects to have values in data.json for each metric listed
> in metadata.json during installation or otherwise it throws an exception
> and dies

That certainly sounds like a bug that could be fairly easily fixed.

> * I t was discussed earlier that perhaps we want to have separate
> configurations for each JVM. That would probably mean one config dir per
> one JVM. But config.json updates are not read during JSON PMDA lifetime
> so JVMs starting after JSON PMDA installation are ignored

This is the same complaint as earlier about metadata.json updates not
being noticed.

I think that basically you are trying to do some things that the JSON
PMDA wasn't designed to do. I'm sure patches would be welcome if you
decide to go this route.

-- 
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>