pcp
[Top] [All Lists]

Re: [pcp] PCP Network Latency PMDA

To: "Frank Ch. Eigler" <fche@xxxxxxxxxx>, Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: [pcp] PCP Network Latency PMDA
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sun, 22 Jun 2014 21:35:02 -0400 (EDT)
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <y0m7g4c9wcp.fsf@xxxxxxxx>
References: <53A34A47.3060008@xxxxxxxxxx> <53A352FF.9090906@xxxxxxxxxxxxxxxx> <y0m7g4c9wcp.fsf@xxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: C8yGt/dDMFW5yPw79mkuNROwXo+oDg==
Thread-topic: PCP Network Latency PMDA

----- Original Message -----
> 
> kenj wrote:
> 
> > [...]  Depending on the overhead of this instrumentation, you may
> > wish to consider using an additional control variable and pmStore(1)
> > to allow a user to enable or disable the collection [...]
> 
> FWIW, I wish we leaned less on this particular technique.

The missing piece is better (client) tool support - its needed for not
just enabling expensive metrics, but also server-side filtering.  It'd
be neat for pmchart to offer this kind of capability, as well as the
many console tools.

>  The pmda
> infrastructure has the ability to track individual pcp clients coming
> and going.
>  So, a pmda can/should activate collection on demand,

A client simply showing interest in the metrics from a PMDA is not enough
information to know whether expensive collection should be enabled or not
though.  A PMDA can export both expensive and inexpensive metrics too, or
the enabled state may be system wide (like hardware counters, or gluster
volume stats, or any of a number of other things that the underlying data
domain creators have chosen not to enable by default).

cheers.

--
Nathan

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