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. But there is a potential problem, derived
metrics only work for the current set of definitions at the time of a
pmNewContext() or pmReconnectContext() ... so presenting the currently
derived metrics in a UI component is OK (assuming we had some new API to
export this from libpcp), but if the UI was to allow the definition of
new derived metric expressions this could be very disruptive to the
client (from the client's perspective close and open all contexts is the
same as pmcd being restarted).
- 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).
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.
- 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.
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.
|