pcp
[Top] [All Lists]

Next release update and pmdalogger merge

To: David Smith <dsmith@xxxxxxxxxx>, "Frank Ch. Eigler" <fche@xxxxxxxxxx>, Ken McDonell <kenj@xxxxxxxxxxxxxxxx>, Max Matveev <makc@xxxxxxxxx>
Subject: Next release update and pmdalogger merge
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Fri, 13 May 2011 21:37:27 +1000 (EST)
Cc: pcp <pcp@xxxxxxxxxxx>
In-reply-to: <1586456728.55457.1305285330525.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxx>
Hi guys,

Following up from some IRC discussion in the last couple of days,
we're not too far off a pcp-3.5.1 release ... early next week I'm
expecting we'll have something releasable.

Ken, Max, & Mark I believe all your recent changes are merged.  I
spent some time merging in the logger PMDA after talking to Frank,
thats in my own dev tree on oss only at the moment.  I want to get
that merged for 3.5.1 so that we can try it and pmevent out in a
more realistic setting, for monitoring our rsyslog hierarchy (I'll
write that up as a case study I think, it might make for some good
entertaining reading, esp. if it comes in useful!).

The one major thing I'm thinking of doing still, which warrants a
bit of discussion, is adding a storable setting to switch off/on
the event record metrics.  My thinking there is that some of the
logged event data is potentially sensitive, and certainly for this
case we have at the moment, these events should not be generally
available.

So, what I'm planning is:
- make logger.perfile.xxx.records "off" by default, and require a
pmstore to enable them.  This means only those (hosts) with metric
store capability can enable and "see" these values.  We could then
have a "localhost"-only pmstore policy in our prod environment,
which would give us an appropriate level of control in our (web
application logs) setting.
- extend pmevent with an option to be able to store a "1" to any
event type metric before attempting to read records ... to enable
the usual mode of operation.
- all of the other metrics, in particular the throughput metrics I
added recently (which count the amount of log traffic), would be
enabled & visible remotely by default, as normal.

Any thoughts or ideas for alternatives there?  (this seems a light-
weight way to get initial security, without going for a full blown
protocol extension, per-user/group access control, etc).

Finally, I had some issues with the command-pipe mode of operation
in pmdalogger ... have you seen those David/Frank?  Don't think I
broke that with my changes, but could be wrong there - we seem to
get EBADF always on a pipe fd read.  PCP QA test 457 shows off the
issue, but a conf line like "pipe yes|" is enough to reproduce it.

We'll need to switch from pipe2 to something portable in that code
(that __pmProcessCreate we discussed earlier), but be good to have
an understanding of this issue first if possible.

cheers.

-- 
Nathan

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