Hi Martin,
You are sure right about the cpu metric label. I've been looking
at that for a week and never noticed. That's usually where I can't
find things, right in front of my head.
The memory metric error is interesting. "Unknown or illegal instance
domain identifier". A better exception message is needed too. I'll
look into it all.
- mtw
On May 14, 2009, at 2:02 PM, Martin Hicks wrote:
Hi all,
Michael has sent me the tarball of his python PMAPI wrapper. I
created
a git tree which can be cloned with:
git clone git://oss.sgi.com/mort/python-pcp.git
I haven't reviewed the code, but I thought it would be good to get it
out ASAP. I did create a specfile for it, but initially I thought
this
was a PMDA wrapper library so the specfile probably says the wrong
thing. I'll fix that shortly.
Michael: I did compile and install this on a sles11 machine and the
"mem" metrics don't seem to work for me:
cleopatra1:~/mort # /usr/share/doc/python-pcp/examples/dofetch.py
Traceback (most recent call last):
File "/usr/share/doc/python-pcp/examples/dofetch.py", line 191,
in <module>
mgmD[ mgm ][ "mem" ] = memList
File "/usr/lib64/python2.6/site-packages/pcpi.py", line 427, in
__setitem__
dict.__setitem__( self, attr, MetricGroup( self, inL=value ) )
File "/usr/lib64/python2.6/site-packages/pcpi.py", line 381, in
__init__
self.mgAdd( inL )
File "/usr/lib64/python2.6/site-packages/pcpi.py", line 387, in
mgAdd
coreL, errL = self._ctx.mcGetCoresByName( nameL )
File "/usr/lib64/python2.6/site-packages/pcpi.py", line 264, in
mcGetCoresByName
newcore = self._mcCreateCore( name, pmid )
File "/usr/lib64/python2.6/site-packages/pcpi.py", line 274, in
_mcCreateCore
self._mcAdd( newcore )
File "/usr/lib64/python2.6/site-packages/pcpi.py", line 232, in
_mcAdd
instL, nameL = self.pmGetInDom( i )
File "/usr/lib64/python2.6/site-packages/pcp.py", line 838, in
pmGetInDom
raise pmErr, status
pmapi.pmErr: -12359
If I comment out the mem metrics, I do get:
cleopatra1:~/mort # ./dofetch.py
127.0.0.1
kernel.percpu.cpu.sys 0.0 %
kernel.percpu.cpu.user 0.0 %
kernel.percpu.cpu.nice 0.0 %
kernel.percpu.cpu.idle 100.0 %
network.interface.in.bytes ib0 0.0 Kbyte/sec
network.interface.in.bytes lo 1.0 Kbyte/sec
network.interface.in.bytes eth1 0.0 Kbyte/sec
network.interface.in.bytes eth0 1.0 Kbyte/sec
network.interface.out.bytes ib0 0.0 Kbyte/sec
network.interface.out.bytes lo 1.0 Kbyte/sec
network.interface.out.bytes eth1 0.0 Kbyte/sec
network.interface.out.bytes eth0 0.0 Kbyte/sec
I think this example is as little confusing, since it still
displays the
kernel.percpu.cpu.* metric name, but it is actually an average of all
of the cpu instances.
mh
On Wed, May 13, 2009 at 11:57:44AM -0500, Martin Hicks wrote:
CCing the PCP list...
On Wed, May 13, 2009 at 12:21:49PM -0400, Michael Werner wrote:
It's way over 40k. Can you put the review copy up on the
oss ftp drop?
Yeah, send me a copy and I'll stick it on oss.
Currently, this is structured as a typical standalone python
extension, built and installed via distutils. It is not dovetailed
into the sgi sources or the build, install, or pkg process.
Should it be dovetailled in? And, how and where?
I suppose it could do either...we could have it as a separate
package to
build and install. Maybe that is the best way, as it would avoid
having
to install python bits to compile PCP.
A couple dependancy issues come immediately to mind.
*) my extension uses the ctypes facilities, meaning python 2.5
is required - or a lesser version plus a separate ctypes extension
Okay. The .deb or .rpm and build system can test for this, I'm sure.
*) many appliances or embedded systems, which one might
want to monitor, are likely to not have python at all.
A lot of embedded systems don't have perl either, so it's up to the
writer of the PMDA to decide which wrapper set to write their PMDA
in...
mh
- mtw
On May 13, 2009, at 8:07 AM, Martin Hicks wrote:
On Tue, May 12, 2009 at 06:41:36PM -0400, Michael Werner wrote:
Hi Martin,
I've made some python wrappers for PCP. Who should I talk
with about getting them posted on oss?
Hi,
You should definitely post them to the mailing list. This will
get the
experts involved and will allow us to review the code.
If they're really big (the mailing list may have a 40kB limit) then
split the patch up or post it to a website.
...don't compress (zip, gzip) the patches you mail out. That
makes it
easier to review in-line in a response.
Sounds excellent Michael. I'm a fan of python, so I'd like to
see your
wrappers in the tree.
mh
_______________________________________________
pcp mailing list
pcp@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/pcp
|