pcp
[Top] [All Lists]

Re: [pcp] Queston about pcp performance metrics filesys.used

To: "Frank Ch. Eigler" <fche@xxxxxxxxxx>, William_Staten@xxxxxxxxxxxxxxx
Subject: Re: [pcp] Queston about pcp performance metrics filesys.used
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Wed, 10 Feb 2016 17:25:52 +1100
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <y0mlh6taakg.fsf@xxxxxxxx>
References: <OF1B9DD255.E1F86B08-ON85257F54.004E7C3F-85257F54.005054A1@xxxxxxxxxxxxxxx> <y0mlh6taakg.fsf@xxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
On 10/02/16 07:33, Frank Ch. Eigler wrote:

...  Ken, what do you think about a derived-metric facility
for this?

mounted_filesys.free = map_indom(filesys.free, filesys.mountdir)

Not sure. map_indom() is more like a declarative operator than an method (a la the other foo() thingies we support).

This is almost getting into the realm of pmlogrewrite(1) where we're asking for metadata changes on the fly ... I'm not convinced of the bang-for-buck proposition here, as it would be a big change for derived metrics (grammar, but worse put derived metrics clutter on almost every PMAPI code path, whereas the clutter is confined to the pmFetch code path at the moment) and this seems to be addressing a rare corner case.

If the instance domains are _really_ equivalent, then an alternative would be for the PMDA implementation to export _two_ groups of metrics, one for the first instance domain, and the second for the other instance domain ... the end user could then choose the naming convention they prefer.

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