[pcp] [question] PCP UI FrontEnd

[Frank Ch. Eigler]

Hi, Ken -


> >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.
> 
> It does not have to be hard coded.  pmie knows which host(s) is making a 
> rule true (use %h in the action), you do need to know where the archive 
> is being written (this is known for logger farms managed by pmmgr or 
> pmloger_check et al) ... then the pmcd.pmlogger metrics tell you which 
> port you need.

That's far enough from "just works" automation as to be hard-coded.
:-) And there's the issue of manually ensuring that metrics enabled on
condition are disabled on !condition.  And computing proper algebra
when multiple conditions influence the same metrics.


> >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.)
> 
> I'm afraid I don't know what "the desired automation" would look like 
> ... could you sketch out some meta syntax that you've got in mind?

Sure.  One way is a straight insertion of the pmie expression
language:

when {
 delta = 2 min;
 cpu.context_switch = 
 some_host (
    kernel.all.pswitch 
        > hinv.ncpu  * 4000 count/sec
 )
} do {
   log mandatory on once {
       proc.psinfo.sname    # note running processes & states
   }
   log advisory on 1s {     # suspect swappage
       kernel.pagesout
   }
   # ...
}  


The semantics would be to get pmlogger to evaluate the conditional
expression with the given period; when it transitions to true or
false, activate or deactivate the given block of logging metrics, as
though they were originally part of the configuration (or someone
pmlc'd them on or off).


This assumes that pmie core could be reworked to allow its reuse
pmlogger.  If not, then reinvent the wheel starting simple, and work
up.  For example:

pmlogger.conf:

test clipboard.stress_ctx > 5 every 10s {
   log mandatory on once {
       proc.psinfo.sname    # note running processes & states
   }
   log advisory on 1s {     # suspect swappage
       kernel.pagesout
   }
   # ...
}  

pmie.conf:

delta = 2 min;
cpu.context_switch = 
some_host (
    kernel.all.pswitch 
        > hinv.ncpu  * 4000 count/sec
) -> pmstore clipboard.stress_ctx 1   # with sensible choice of target host

In this model, we'd build out nathans' earlier ideas about a clipboard
pmda, and use that as a communication channel between pmie and
pmlogger.  (Access control issues would have to be surmounted.)
But again no pmlc!


> pmlogger is complicated enough as is, I don't see much chance of
> loading more functionality in there once it is running, other than
> the existing pmlc channel.

I hope the examples above give a reason to gradually reconsider that.


> [...]
> The evil traps of allowing people to not think about what sort of 
> performance monitoring is needed include:

The job of the defaults is exactly to allow people not to think about
it - they trust us to provide a reasonable out-of-the-box
configuration.


> (a) the deployed configs miss critical data for some significant part of 
> the installed base,
> (b) the deployed configs collect more data (coverage, depth, sampling 
> frequency) than is useful for some significant part of the installed base
> (c) the deployed pmie rules trigger false alarms for some significant 
> part of the installed base
>
> Unless we can figure out a way to make progress on how the dynamic
> reconfiguration (post-install and at run-time) should be done to
> minimize the effects of (a) to (c) above, consideration of how to
> plumb this into pmlogger or pmie is probably moot.

A library of default dynamic pmlogger settings would be better than
(3), since they don't constitute alarms, merely more (or less) data
being collected.  If the default dynamics we were to provide only
conditionally-increased data over the present-day defaults, then (1)
is not a problem.  (2) could be, but I'm confident we can come up with
some defaults that are acceptable, and of course they are only
defaults.


> Wish we had a suitable forum to hash this out ... email is not ideal
> unfortunately.

Hey, come on over, we'll talk by the pool. :-)


- FChE