pcp
[Top] [All Lists]

Re: [pcp] signal pmlogger

To: Nathan Scott <nathans@xxxxxxxxxx>, Ken McDonell <kenj@xxxxxxxxxxxxxxxx>, "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Subject: Re: [pcp] signal pmlogger
From: Martins Innus <minnus@xxxxxxxxxxx>
Date: Tue, 15 Apr 2014 09:31:38 -0400
Cc: PCP Mailing List <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <2083518993.5624332.1397541393227.JavaMail.zimbra@xxxxxxxxxx>
References: <53482BC5.6070203@xxxxxxxxxxx> <y0mr453663h.fsf@xxxxxxxx> <01c401cf55c9$d4322fc0$7c968f40$@internode.on.net> <534C3695.4050306@xxxxxxxxxxx> <534C4D07.8020604@xxxxxxxxxxxxxxxx> <2083518993.5624332.1397541393227.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
Nathan,

On 4/15/14 1:56 AM, Nathan Scott wrote:
And in the mean time we should consider the discussion to see if we can
refine 1. into something that is general useful, robust and easy to use.

I like the direction #1 is headed also.

I wonder if a concept of groups of metrics would be useful here (IOW, user
defined, named groups) - so not only the one additional set.  There may be
different problem scenarios that someone is trying to focus on, problem A
might want to catch a set of proc metrics, problem B maybe some mem state,
problem C a third set ... switching on/off these groups via pmlc commands
that pmie could latch onto simply via "enable setB, interval X", "disable
setB" and so on, could be quite neat.


Yeah, multiple named groups would be great.

Martins

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