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
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)
* 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)
* metadata.json updates are not picked up during JSON PMDA lifetime
* 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
* 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
>> Since we already have data flowing thru pmdajmx.pl I'd assume it'd be
>> easier to switch to the somewhat similar JSON PMDA than the MMV PMDA.
>
> Yep - for MMV we'd need a small amount of new code to allow proxying too -
> not tricky or difficult in any way, but I tend to agree that starting off
> producing JSON output is a good idea.
See above, unfortunately not that easy with JSON either :/ So looks like
we don't have perfect alternatives available at the moment (see also
below). One theoretical alternative would be to rewrite the current
pmdajmx.pl as pmdajmx.py which would allow dynamic metrics but that
would surely prevent reusing existing code so far from ideal. (But would
be most likely less effort than extending the Perl PMDA API to support
dynamic metrics.)
I think at this stage with lots of new ideas, requirements, and
understanding gained it might be a good time to take hands off the
keyboard for a while and collect a list requirements and nice-to-have
features (and things we don't want) and then re-evaluate how to get there.
Thanks,
--
Marko Myllynen
|