pcp
[Top] [All Lists]

Re: [pcp] [PATCH] PCP pidstat PMDA

To: pcp@xxxxxxxxxxx
Subject: Re: [pcp] [PATCH] PCP pidstat PMDA
From: Marko Myllynen <myllynen@xxxxxxxxxx>
Date: Thu, 07 May 2015 13:38:02 +0300
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5536CF59.6050108@xxxxxxxxxxxxxxxx>
Organization: Red Hat
References: <5534C680.2020709@xxxxxxxxxx> <493537984.3276058.1429528962326.JavaMail.zimbra@xxxxxxxxxx> <5534EBA8.4030509@xxxxxxxxxx> <1644393599.3651017.1429563442835.JavaMail.zimbra@xxxxxxxxxx> <55364606.1000503@xxxxxxxxxx> <5536CF59.6050108@xxxxxxxxxxxxxxxx>
Reply-to: myllynen@xxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
Hi,

just for the record / archives..

On 2015-04-22 01:29, Ken McDonell wrote:
> On 21/04/15 22:43, Marko Myllynen wrote:
>> ...
>> hmm, so it is possible to provide a redirected metric from another
>> domain in C but is there a way to do that in Perl or Python? And is it
>> possible to read a metric from another domain to be used to calculate or
>> construct a new metrics in the current domain, not just redirect?
> 
> In general this is not possible.
> 
> Think about the flow of a request (you're building pmda A and pmda B has
> the metrics you're interested in):
> 
> client -> pmcd -> pmda A -> ???
> 
> If pmda A tries to use pmcd to get to pmcd B we have a callback into
> pmcd and all sorts of timeout headaches ... pmie in "secret agent mode"
> for the summary PMDA does this, but I would not recommend that as a
> precedent to be copied!
> 
> If pmda B has some non-pcp export channel (as well) that could be used.
> 
> Otherwise, source code replication from pmda B into pmda A is likely to
> be the simplest (and most efficient) strategy.

I think derived metrics would be helpful in the case I was thinking,
i.e., to construct a new metric based on metrics provided by pmda A and
by pmda B.

Thanks,

-- 
Marko Myllynen

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [pcp] [PATCH] PCP pidstat PMDA, Marko Myllynen <=