pcp
[Top] [All Lists]

Re: [pcp] python bindings

To: Stan Cox <scox@xxxxxxxxxx>
Subject: Re: [pcp] python bindings
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Mon, 25 Jun 2012 10:25:03 +1000 (EST)
Cc: pcp@xxxxxxxxxxx, Michael Werner <mtw@xxxxxxxxxxxxxx>
In-reply-to: <1859167160.955443.1339634764360.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxx>
Hi Stan,


pcpfans(1) in src/src/python now has the beginnings of a system
statistics collector called pm-collectl.py (appended).   The python

Looked at this a little bit more on the weekend - there were a few places where
the default output didn't quite match up with collectl output for me, so pushed a
change to change that behaviour a little.  There was a few fields that looked like
they needed to be converted to KB, and inspection of the collectl source shows
they're using 1024 bytes-per-KB - so I've changed over a few places.

I noticed a couple of things I didn't tackle that might be good to do too, but are
a bit beyond my dodgey python skills.  There's a "metric-type" data structure,
with hard-coded metric-to-type mappings.  Instead of hard-coding names of
metrics known to not need rate conversion, we could use the metric desc struct -
pmLookupDesc(3).  This structure has a 'semantics' field (pmDesc.sem) and we
can test for PM_SEM_COUNTER.  That would work for any metric (existing /
newly added) and the metric-type structure would be unnecessary.

We should be able to implement collectl playback mode fairly easily (using PCP
archives).  My python-fu is not up to the task yet though - I see the pmContext()
call but not clear how to give it a filename to put it into archive mode.  Any clues?
I'd like to add pmlogger and pmlogconf configuration files which will let someone
easily get recording of the necessary metrics setup.

cheers.

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