Hi,
On 2016-04-25 19:58, David Smith wrote:
> On 04/15/2016 06:12 AM, Marko Myllynen wrote:
>> On 2016-04-12 04:53, Nathan Scott wrote:
>>> ----- Original Message -----
>
>> 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.
Actually, I was a bit confused what was going on but nevertheless there
are few surprising things. With metadata.json and data.json looking like:
{
"prefix": "jsontest",
"metrics": [
{
"name": "a_b_c",
"pointer": "/a_b_c",
"type": "integer"
},
{
"name": "a_d_e",
"pointer": "/a_d_e",
"type": "string"
},
{
"name": "a_b_f",
"pointer": "/a_b_f",
"type": "integer"
}
]
}
{
"a_b_c": 1,
"a_d_e": "2",
"a_b_f": 3
}
First clear the cache and install the PMDA to see all is ok. Then change
1 to "1" in data.json, confusingly there's error printed for both a_b_c
and a_b_f (I'd expect error at most for a_b_c). Now revert "1" back to 1
and then verify things are ok again. Then change 3 to "3" and see how
the PMDA crashes.
Of course, the user is responsible for providing correctly formatted
data but when testing (possibly with hundreds of metrics) such
inconsistencies in error cases can be a bit confusing.
>> * 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?
The above metrics still work if you do s,_,.,g but in a simalar simple
array case the PMDA log is being filled with errors and tracebacks.
>> * 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.
Ok, Nathan mentioned earlier that the Python PMDA API was extended to
allow adding metrics dynamically so if metadata.json updates are not
picked up then on the fly then perhaps he meant something else.
>> * 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 can reproduce this in the array case only. One instance missing one
metric and it prevents output of other values and causes the JSON log
being filled with errors on each fetch.
>> * It 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.
Yeah, this concludes why the JSON PMDA currently isn't ready to be used
with PCPJMXConnector, an alternative which was speculated for a while
earlier.
> I think that basically you are trying to do some things that the JSON
> PMDA wasn't designed to do.
Given that the README didn't contain enough information even to
configure the JSON PMDA properly before the patch I sent last week it's
a bit hard to know what are the things the JSON PMDA was designed to do.
Cheers,
--
Marko Myllynen
|