pcp
[Top] [All Lists]

Re: [pcp] pmie support for string-typed metrics

To: Mark Goodwin <mgoodwin@xxxxxxxxxx>, Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: [pcp] pmie support for string-typed metrics
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Tue, 3 May 2016 16:50:06 +1000
Cc: pcp <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5726AF1D.2090405@xxxxxxxxxx>
References: <220069218.39805602.1460521052029.JavaMail.zimbra@xxxxxxxxxx> <733731954.39808417.1460522806449.JavaMail.zimbra@xxxxxxxxxx> <a54a13c7-4824-499c-8fa6-232cbd33ffaf.maildroid@localhost> <1337028064.40108627.1460601063575.JavaMail.zimbra@xxxxxxxxxx> <5726A8FC.7070303@xxxxxxxxxx> <1425795935.44525257.1462152712852.JavaMail.zimbra@xxxxxxxxxx> <5726AF1D.2090405@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
On 02/05/16 11:36, Mark Goodwin wrote:
...
How about "async" logging frequency

e.g. :

log advisory on async {
         hinv
         kernel.uname
         filesys.mountdir
         filesys.blocksize
         filesys.capacity
}

If I am understanding the discussion so far, the request is for
(a) don't log unless changed, and
(b) log no more frequently than some delta

The (b) part provides the "rate limitation" and tells pmlogger how frequently to check for a change (this will be much simpler to explain and implement than checking on every single pmFetch for any metric).

So I think it needs to be something like ...

log [advisory|mandatory] on [default|every N timeunits] [if changed] {
        metric ...
}

And this can only apply to discrete or instanteous metrics (it would change the semantics for counters during replay).

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