On 28/07/15 10:56, Frank Ch. Eigler wrote:
...
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.
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?
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.
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.
My experience with "immediately deployable" for pmlogger and pmie
suggests this goal is very difficult, or at least beyond the intellect
of someone like me ... the scars from getting this wrong are deep and
long-lasting.
The evil traps of allowing people to not think about what sort of
performance monitoring is needed include:
(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.
Wish we had a suitable forum to hash this out ... email is not ideal
unfortunately.
|