pcp
[Top] [All Lists]

Re: [pcp] RFC: derived metrics in PCP archives

To: Nathan Scott <nathans@xxxxxxxxxx>, Mark Goodwin <mgoodwin@xxxxxxxxxx>, Marko Myllynen <myllynen@xxxxxxxxxx>
Subject: Re: [pcp] RFC: derived metrics in PCP archives
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Fri, 4 Dec 2015 11:16:27 +1100
Cc: PCP <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <2035219440.34824754.1449184754527.JavaMail.zimbra@xxxxxxxxxx>
References: <5660B237.7000709@xxxxxxxxxxxxxxxx> <5660C64B.3030408@xxxxxxxxxx> <2035219440.34824754.1449184754527.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
On 04/12/15 10:19, Nathan Scott wrote:
...
So we end up with a PMID 511.*.* in the archive's metadata and in the
archive's pmResults ... kaboom!  libpcp gets very confused trying to
handle this because it looks like a derived metric but behaves like a real
metric in the archive.

Ouch.  :)

Not really ... just outside the scope of the original design ... 8^)

...
A couple of alternatives - there are some free ranges earlier in the stdpmid
set, which we've begun reusing (24 would be the next - grep on "FREE SLOTS").
Another option might be to reuse the PMI_DOMAIN (245) for these metrics too?

24 is just as good as 384 ... keeping our footprint compact has some advantages. I'd like to avoid PMI_DOMAIN and indeed any <domain> that could be used by any PMDA (the importers are like a PMDA in this context).

> ...

Thanks Nathan.

I think my suggestion is still in play ... I'll wait a few more days for any other comments, then I'll likely just "do it".

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