pcp
[Top] [All Lists]

Re: Introducing pmrep - Performance Metrics Reporter

To: Marko Myllynen <myllynen@xxxxxxxxxx>
Subject: Re: Introducing pmrep - Performance Metrics Reporter
From: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Date: Fri, 30 Oct 2015 12:38:36 -0400
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <563395F1.6040303@xxxxxxxxxx>
References: <560278D5.8010305@xxxxxxxxxx> <5603F9D6.7050306@xxxxxxxxxxx> <159724763.42718898.1443163436257.JavaMail.zimbra@xxxxxxxxxx> <560A9715.4060905@xxxxxxxxxx> <1542966539.49294102.1444091627491.JavaMail.zimbra@xxxxxxxxxx> <563099B1.7000802@xxxxxxxxxx> <980961654.65506823.1446187043033.JavaMail.zimbra@xxxxxxxxxx> <y0mvb9os78v.fsf@xxxxxxxx> <563395F1.6040303@xxxxxxxxxx>
User-agent: Mutt/1.4.2.2i
Hi, Marko -

On Fri, Oct 30, 2015 at 06:08:17PM +0200, Marko Myllynen wrote:
> [...]
> > The fetchgroup widgets will get a reasonably high-level pmapi.py
> > representation.
> 
> to me it almost looks like we already have enough such API user
> candidates without pmrep (and actually it might be better to start with
> them rather than with pmrep).

Quite possibly.


> [...] However, pmrep's archive and stdout outputs have some
> peculiarities which might then provide a use case on how to use the
> generic APIs with custom properties in play (like field width,
> decimal count, header printing, etc, all irrelevant for pcp2graphite
> and such).

The fetchgroup widget would be only for -fetching-.  So it is neutral
as to formatting or disposal of the resulting values.


- FChE

<Prev in Thread] Current Thread [Next in Thread>