pcp
[Top] [All Lists]

Re: [pcp] Calculated/derived metrics?

To: pcp@xxxxxxxxxxx
Subject: Re: [pcp] Calculated/derived metrics?
From: Marko Myllynen <myllynen@xxxxxxxxxx>
Date: Wed, 06 May 2015 12:54:21 +0300
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5547DE11.5050800@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> <55472B40.7050800@xxxxxxxxxx> <5547DE11.5050800@xxxxxxxxxxxxxxxx>
Reply-to: myllynen@xxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
Hi,

On 2015-05-05 00:01, Ken McDonell wrote:
> On 04/05/15 18:18, Marko Myllynen wrote:
>> ...
>> I think it would still be interesting to hear experiences around this,
>> if calculated/derived metrics are needed in some cases, how to get them
>> most efficiently?
> 
> There is already a pretty complete derived metrics implementation.
> 
> It uses a configuration file to define the expressions for the derived
> metrics and assign names to them, then the implementation sits in the
> data path so that all PMAPI calls for metadata or metric values are
> translated appropriately.

right, I was blissfully unaware of this.

> Refer to pmRegisterDerived(3) for the expression syntax. PCPIntro(1)
> describes the environment variable $PCP_DERIVED_CONFIG that needs to be
> set to pathname to a file containing the definitions of the derived
> metrics in form needed by pmLoadDerivedConfig(3).
> 
> If this does not address your needs I'd be keen to hear how and why.

I see that pmRegisterDerived(3) describes both C API and the expressions
used to construct derived metrics. There are also Python bindings for
it. And pminfo(1) can read such a "dmfile" specified with -c,
PCP_DERIVED_CONFIG should be used with tools like pmval(1).

I don't see Perl bindings for this, not sure is that a biggie. Usage
seems otherwise pretty straightforward except when dealing with multiple
instances. For example, I tried to derive the bytes-written/s for a
process being monitored with hotproc. A process' lifetime can roughly be
calculated with kernel uptime - the process' start_time / 100. But
testing with something like:

write_per_sec = hotproc.io.write_bytes / (kernel.all.uptime -
hotproc.psinfo.start_time/100)

leads to an (expected) error as there are several instances. This
calculation gives the expected result when only one instance is present:

write_per_sec = max(hotproc.io.write_bytes) / (kernel.all.uptime -
max(hotproc.psinfo.start_time)/100)

but I cannot figure out how to do this for all instances.

Otherwise this certainly looks very much I was asking for, thanks for
the pointer.

Cheers,

-- 
Marko Myllynen

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