Hi Marko,
----- Original Message -----
> >
> > +1 - this is looking like a nice step forward Marko, very very promising!
>
> thanks for the encouraging feedback.
>
No problem at all, thanks for taking on the more difficult task of doing the
actual work! ;)
> > Few suggestions on first reading, mainly related to the config file...
> >
> > 1. This syntax (from sample rep.conf) I'm finding a bit cryptic:
> > mem.vmstat.pswpin=pswpin/s,,,10
> > mem.vmstat.pswpout=pswpout/s,,,10
> >
> > I wonder if turning this inside-out might make it easier and more readable,
> > keeping the ini-style format but using labels for metrics, as in
> >
> > pswpin = mem.vmstat.pswpin
> > pswpin.width = 10
> > pswpin.label = "pswpin/s"
>
> Great idea! The syntax was something I came up with very early on and
> stick with it while concentrating on everything else. I think the
> comma-separated syntax would still be useful to be supported to allow
> adding customized metrics more quickly on the command line.
*nod*
> I'm a bit busy with something else at the moment but I'll try to look at
> this in a week or two.
Cool - I'll set aside some time to help out too.
>
> > and this one interests me greatly... :)
> > # XXX modularize code to allow custom output plugins
> >
> > I think what you will want to end up with here is an API
>
> Yeah. I'd like to see something that's easy for casual administrators
> and other non-programmers to use but also something slightly more
> sophisticated than the current code.
*nod*
> > it would be great if most of the code in the script was abstracted
> > out into a module, and pmrep(1) uses that API - custom plugins would
> > just be scripts like pmrep, but a bit more specialised.
>
> Perhaps we could have a couple of real modules written to validate the
> interface, for example the already provided CSV and stdout and the
> perhaps pcp2graphite or pcp2zabbix (which would now be near-trivial with
> pmrep + zbxsend, see https://pypi.python.org/pypi/zbxsend).
Oh cool - yes, we're getting lots of requests for that kind of integration.
> > You'll find pcp.pmcc provides good convenience classes that you could
> > use in building such an API (it has a grouping concept too & there's a
> > bunch of tests already, so you might find it easier to extend both the
> > code & tests :) - so, I really encourage you to look closely there and
> > see if it can be used, early on, rather than implementing a separate
> > API/module down the track for this - lets design it in from day one.
>
> I looked at this a bit more, basics look good but some parts don't have
> any in-tree users at all, so perhaps we'd need a bit of hands-on
> experience to see how well these fit together.
Sounds good - pcp-iostat is a moderate-sized in-tree user if that helps (it
uses most/all pmcc classes), and converting the pcp2graphite script so that
it gets configuration file support "for free" would be a win. pcp-collectl
is crying out for pmcc use too, its alot more complex than it needs to be.
>
> The pmDebug snippet was actually just a copypaste from pcp2graphite, I
> checked that -D9 worked and didn't pay any attention to it later on. So
> if you could adjust pcp2graphite as needed, I'll then copypaste from it
> again :-)
Yep, that code can be improved - will do.
cheers.
--
Nathan
|