pcp
[Top] [All Lists]

Re: [question] PCP UI FrontEnd

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: [question] PCP UI FrontEnd
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Mon, 27 Jul 2015 20:56:40 -0400
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <55B6B46E.2050306@xxxxxxxxxxxxxxxx> (Ken McDonell's message of "Tue, 28 Jul 2015 08:45:02 +1000")
References: <f8fde1169e264460bc2e250d2c9d7df0@xxxxxxxxxxxxxxxxxxxxxxxxx> <y0m1tft2sqt.fsf@xxxxxxxx> <55B6B46E.2050306@xxxxxxxxxxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
kenj wrote:

> [...]
> The mechanism exists.
>
>       pmie guard -> launch pmlc -> reconfigure pmlogger on the fly
>
> this has been there since day 1 (almost), and has been used in anger
> in real production environments with good results.

Yes, one can certainly do that if necessary, but the pmie / pmlc /
pmlogger connections are too imperative & manual.  For example, pmie
can't tell a pmlc which pmlogger to control except by hard-coding the
host name / port number at which a pmlogger might be listening at the
time.

I was contemplating more of a declarative & scalable solution, whereby
the pmlogger configuration itself describes the desired automation.
Then no IPC (nor its setup!) and no more daemons would be needed.
(See the other thread on the pmcpp -- where even %shell would not be
quite enough, because it would need to be reevaluated periodically
instead of just once at startup.)


> What is missing, and I believe is not achievable in a general sense,
> is making this automated.  It requires performance analysis and
> local customization to develop the pmie guards (to start and stop
> detailed logging) and to define the appropriate pmlogger config
> changes. [...]

If our pmlogger configury were declaratively automated, we could
include a library of working examples in the default pmlogconf files,
and they would be immediately deployable.  Think sort of like the
pmieconf ones.


- FChE

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