pcp
[Top] [All Lists]

Re: [pcp] Derived Metrics with rate()

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: [pcp] Derived Metrics with rate()
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Thu, 23 Jul 2015 02:54:28 -0400 (EDT)
Cc: pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <55921568.8050007@xxxxxxxxxxxxxxxx>
References: <558BAC86.2090005@xxxxxxxxxx> <00e801d0b124$8b825d60$a2871820$@internode.on.net> <453884136.27463015.1435531286806.JavaMail.zimbra@xxxxxxxxxx> <55921568.8050007@xxxxxxxxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: lU0c7RshYoPkCAX3+IDbDuc+3cTjwQ==
Thread-topic: Derived Metrics with rate()
Hi Ken,

----- Original Message -----
> [...]
> > I think it would also be good to promote
> > the --derived pminfo option to be a standard option that all tools can
> > easily access (via pmGetOptions) - I'm happy to hack on that bit if people
> > tend to agree?
> 
> That would be a help to make derived metrics more usable, so I agree.
> And thanks for the offer to do the work.
> 

Finally back to this one - any objection to making pmLoadDerivedConfig
take a path list too? (while keeping its current single-file behaviour)

Otherwise, we would need a new API for the monitor tools to call (even
for pminfo, which is the only in-tree user of the current API).

I've pushed this approach into my tree for now, if you could check it out
that'd be great - the only non-obvious bit was error propagation from the
new derived-metric-path-handling code so that current pmLoadDerivedConfig
semantics can be maintained.

cheers.

--
Nathan

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