I have finally decided to release PyKstat, a Python interface
to the Solaris kstat(3k) API. The package can be found at
http://www.biostat.wisc.edu/~annis/creations/pykstat.html
Here is the README file which comes with the package...
This is the initial release of a Python interface to the Solaris kstat
API. I recommend checking out the man pages for information on the C
API. This will only work for Solaris, and has been tested on Solaris
2.5, 2.5.1, and 2.6 for SPARC Solaris, and 2.6 for the Intel version
of Solaris, using Python 1.5.1 and 1.5.2.
* Why did I do this?
I am currently re-implementing a machine monitoring system. The
original version, written in Perl, has to fork off and parse the
output from various system data tools, such as iostat, vmstat, uptime,
etc. As it turns out, the vast majority of this data -- and a whole
lot more -- is available via the kstat(3k) interface. I wanted to be
able to get all this data without forking.
* How did I do this?
The PyKstat package has several parts, starting with a helper
library in C wrapping kstat into something more friendly. The next
layer is the lowest Python layer, and is generated by SWIG. I
distribute the SWIG generated wrappers, so you do not need SWIG
installed to use this package... unless you want to. The SWIG layer
is little more than a Python version of my wrappers.
The next layer is in kstat.py. This provides an object oriented
interface, and nicely hides the chain-following you have to do if you
use the simplest interface. kstat.py provides a single class, Kstat,
which does all the interesting work. This interface does however
assume some familiarity with the kstat(3k) API.
The final layer of PyKstat, and the interface I suspect most
people will want to use, is in kstats.py. This interface is *not*
OOPy, but it does use the Kstat class as its engine. I strongly
recommend looking at the doc strings in kstats.py and playing with the
many functions provided to get a feel for the API.
For the perversely curious, the dependencies are: kstat API <-
wkstat.c (my helpers) <- wkstatmodule.so (SWIG generated interface to
wkstat.c) <- kstat.py (OOPy interface to wkstatmodule.so) <- kstats.py
(the most friendly interface).
* What about bugs?
There are doubtless some bugs. However, I don't believe there are
any major ones. I have been using this software to check machine
statistics for a few months now, and in fact some single Python
programs have been running *continuously* for a month and reporting on
machine statistics.
If you discover any bugs, certainly let me know, but try to
include as much information as possible, and a snippet of code which
causes the problem.
The install process could be more elegant.
* Cool! How do I install this.
Take a look at the Makefile. It's pretty simple. You should only
need to change your CC, though I recommend using gcc, and the two
lines saying where your Python is installed. Then run 'make', then
'make install'. The install process is crude in the extreme, and
simply copies a few files into your Python library area.
Check out the few examples in the examples directory to get an
idea of how this package can be used. I've included the program netd
as an example. It will *not* work for you, since it requires
libraries I've not made public yet. It does, however, provide an
interesting example.
William S. Annis
99jun09
--
William Annis - System Administrator - Biomedical Computing Group
annis@biostat.wisc.edu PGP ID:1024/FBF64031
Mi parolas Esperanton - La Internacia Lingvo www.esperanto.org
to the Solaris kstat(3k) API. The package can be found at
http://www.biostat.wisc.edu/~annis/creations/pykstat.html
Here is the README file which comes with the package...
This is the initial release of a Python interface to the Solaris kstat
API. I recommend checking out the man pages for information on the C
API. This will only work for Solaris, and has been tested on Solaris
2.5, 2.5.1, and 2.6 for SPARC Solaris, and 2.6 for the Intel version
of Solaris, using Python 1.5.1 and 1.5.2.
* Why did I do this?
I am currently re-implementing a machine monitoring system. The
original version, written in Perl, has to fork off and parse the
output from various system data tools, such as iostat, vmstat, uptime,
etc. As it turns out, the vast majority of this data -- and a whole
lot more -- is available via the kstat(3k) interface. I wanted to be
able to get all this data without forking.
* How did I do this?
The PyKstat package has several parts, starting with a helper
library in C wrapping kstat into something more friendly. The next
layer is the lowest Python layer, and is generated by SWIG. I
distribute the SWIG generated wrappers, so you do not need SWIG
installed to use this package... unless you want to. The SWIG layer
is little more than a Python version of my wrappers.
The next layer is in kstat.py. This provides an object oriented
interface, and nicely hides the chain-following you have to do if you
use the simplest interface. kstat.py provides a single class, Kstat,
which does all the interesting work. This interface does however
assume some familiarity with the kstat(3k) API.
The final layer of PyKstat, and the interface I suspect most
people will want to use, is in kstats.py. This interface is *not*
OOPy, but it does use the Kstat class as its engine. I strongly
recommend looking at the doc strings in kstats.py and playing with the
many functions provided to get a feel for the API.
For the perversely curious, the dependencies are: kstat API <-
wkstat.c (my helpers) <- wkstatmodule.so (SWIG generated interface to
wkstat.c) <- kstat.py (OOPy interface to wkstatmodule.so) <- kstats.py
(the most friendly interface).
* What about bugs?
There are doubtless some bugs. However, I don't believe there are
any major ones. I have been using this software to check machine
statistics for a few months now, and in fact some single Python
programs have been running *continuously* for a month and reporting on
machine statistics.
If you discover any bugs, certainly let me know, but try to
include as much information as possible, and a snippet of code which
causes the problem.
The install process could be more elegant.
* Cool! How do I install this.
Take a look at the Makefile. It's pretty simple. You should only
need to change your CC, though I recommend using gcc, and the two
lines saying where your Python is installed. Then run 'make', then
'make install'. The install process is crude in the extreme, and
simply copies a few files into your Python library area.
Check out the few examples in the examples directory to get an
idea of how this package can be used. I've included the program netd
as an example. It will *not* work for you, since it requires
libraries I've not made public yet. It does, however, provide an
interesting example.
William S. Annis
99jun09
--
William Annis - System Administrator - Biomedical Computing Group
annis@biostat.wisc.edu PGP ID:1024/FBF64031
Mi parolas Esperanton - La Internacia Lingvo www.esperanto.org