[pcp] Introducing pmrep - Performance Metrics Reporter

[Marko Myllynen]

Hi,

On 2015-10-06 03:33, Nathan Scott wrote:
> 
>>> 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.

I've now implemented also the syntax you suggested and in some cases
it's certainly an improvement but after a while I came to notice that
many times the hardest part is to figure out what is the exact metric
set you want to follow, at least for me it's easier to quickly see all
the selected metrics in condensed format, their presentation is
secondary. I converted all the examples except the vmstat one to the
suggested syntax, it illustrates that with the original format the list
vmstat of metrics will fit in a standard 24 line terminal/editor window.

>>> 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.

This was as easy as expected, see:

http://oss.sgi.com/pipermail/pcp/2015-October/008550.html

>>> 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.

Here are the changes I've now done for pmrep:

- fix the pmDebug case
- pylint cleanups
- Python 3 / Fedora 23 support
- PCP 3.9.10 / RHEL 7 support
- Python 2.6 / RHEL 6 support
- support for the new metric spec syntax
- adjust for recent recording changes
- Zabbix support

I also investigated pmcc a bit more. There's certainly some appeal in it
already but I'm not convinced to change pmrep quite yet; I think it
would be a good idea to wait for the pmFetchGroup API to land and it to
propagate to the Python PMAPI, it might be an interesting alternative as
well (pmFetchGroup API has seen some activity since my previous pmrep
email, see
https://sourceware.org/git/gitweb.cgi?p=pcpfans.git;a=commitdiff;h=f4258e64926ad8b1752f84fad84f83196c43ffa8).

Also, before starting possible internal surgery which should not affect
current user experience, I think it'd be beneficial to have some QA
tests in place to make sure we don't break anything while using the scalpel.

Which brings us to the interesting question of merging pmrep. Now I have
it only on my local repo which is of course a quite silly, writing the
man page and QA would certainly be easier if part of pcp.git. Or did you
have some hard requirements in mind before merging?

https://myllynen.fedorapeople.org/pmrep.py
https://myllynen.fedorapeople.org/pmrep.conf

Thanks,

-- 
Marko Myllynen