Hi,
On 2015-05-07 10:29, Ken McDonell wrote:
> On 07/05/15 16:19, Nathan Scott wrote:
>>
>> A few possibilities spring to mind ...
>> - presenting some pmchart UI for adding new derivations interactively
>> (may need a parser-helper routine for this that pmchart can use to
>> give feedback about parsing error locations),
>
> This is also on the BZ list.
I see PCP_DERIVED_CONFIG commented out in pmwebd.options, I presume
predefined derived metrics are thus available via pmwebd for Web UIs?
>> - provide a mechanism to persist derivations (in ~/.pcp/ &| /etc/pcp)
>> and make libpcp automatically load those metrics so that all client
>> tools see 'em immediately (without env vars, etc).
>
> Yep that's certainly possible, although if that directory gets cluttered
> it could significantly slow PMAPI operations both at startup and on the
> error paths (derived metrics are usually tried when all else fails for
> pmns and metadata operations).
I added PCP_DERIVED_CONFIG to /etc/pcp.conf and all of pminfo, pmval,
and pmdumptext "just worked" with derived metrics. Not sure is this the
ideal solution but if no better ones are in sight then perhaps adding
PCP_DERIVED_CONFIG to pcp.conf in comments might be somewhat helpful.
> If we can gather these definitions from a number of places ... env,
> /etc/pcp/.., ~/.pcp, command line args ... then there is a more pressing
> need for an export API.
Having some examples provided or a "library of derived metrics" would
certainly help - few weeks ago I was asking about using PCP as a 1:1
drop-in replacement for sar/sysstat and otherwise it's already possible
but there were three (or four) metrics that were not readily available
(disk.dev.avqsz, disk.dev.avrqsz, disk.dev.await, disk.dev.svctm), it
might be a nice real world example that even if such calculated metrics
are not provided by default, they can be derived. (The needed
calculations should already be present in a slightly different form in
pmiostat I presume).
>> - as we find useful, general derivations we could install them below
>> /etc/pcp (ie as part of the package installation) so they're always
>> automatically available
>
> Nod.
Yup.
>>>> I don't see Perl bindings for this, not sure is that a biggie. ...
>>>
>>> The Python bindings are probably there by accident (no Python code
>>> appears to
>>> be using them). Perl bindings would be simple to add if the need arose.
>>
>> There are no general PMAPI perl client bindings (only the PMDA APIs).
>
> Ah, good point.
Ok so with Perl scripts one would just defined the env variable?
Thanks,
--
Marko Myllynen
|