pcp
[Top] [All Lists]

Re: Introducing pmrep - Performance Metrics Reporter

To: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Subject: Re: Introducing pmrep - Performance Metrics Reporter
From: Marko Myllynen <myllynen@xxxxxxxxxx>
Date: Fri, 30 Oct 2015 18:56:53 +0200
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <20151030163836.GB28852@xxxxxxxxxx>
Organization: Red Hat
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> <20151030163836.GB28852@xxxxxxxxxx>
Reply-to: myllynen@xxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
Hi,

On 2015-10-30 18:38, Frank Ch. Eigler wrote:
> On Fri, Oct 30, 2015 at 06:08:17PM +0200, Marko Myllynen wrote:
> 
>> [...] 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.

yes, exactly, that's why pmrep is probably not the best candidate as the
first user as it has additional requirements in addition to merely
fetching values. With others it'll probably be easier to find out
suitable abstraction level without the need to deal with those
formatting etc properties yet at that point.

Thanks,

-- 
Marko Myllynen

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