xmlsysd is a daemon that can be run either as a forking daemon from userspace or from inetd. It is based, loosely, on a nearly total rewrite of the old procstatd that used to be available from this site. Controlled by a simple command interface, it parses various files in /proc and executes certain systems calls to provide an informational snapshot of system status. This information is then returned via the connection encapsulated in an application specific xml that is easy to parse and postprocess on the client end.
Powerful features of xmlsysd include: xml encapsulation of all returned information, to facilitate extensibility, ease of parsing, and ultimately display; the daemon is throttleable (can be set to return only particular subsets of the interesting information to support particular monitoring or display purposes, minimizing load on the monitored host and network); ability to be run as a forking daemon from userspace, as a system task, or via xinetd, securable with e.g. tcp wrappers or iptables or ipchains; ability to return key information on running processes to facilitate remote process monitoring on a cluster node or LAN workstation.
The ncurses-based client wulfstat (which can be run in any xterm) is currently provided, although writing more advanced GUI clients, web clients, or scripted monitoring clients should be very simple.
At this time xmlsysd does not support lmsensors or direct monitoring of environmental measures such as temperature, voltage, fans (although procstatd did have limited support). This is because the sensors /proc interface has nothing like an API -- instead of providing a device-independent, or at least scalable view of the sensors data (such as might be possible if they utilized an xml-based encapsulation of the chip-specific data) sensors information is almost invariably different for each chip, so that one has to write parsing code on a per-chip basis to incorporate this functionality. Eventually I'll do this for at least one or two sensors we have locally and this code can then serve as a template for others to use to support their own hardware and contribute back of they wish.
xmlsysd and wulfstat are still under active development and are not warranted to be bug free. However, they are also being actively used here and bug reports will get rapid attention. xmlsysd itself is fairly stable at this point and quite reliable; the wulfstat client is more rapidly changing and has a few small bugs associated with its development (that will gradually be eliminated) that do not generally interfere with its function but can sometimes cause small delays.
I would welcome contributions or suggestions for xmlsysd and/or wulfstat's future evolution. When wulfstat is stable I've already begun work on gwulfstat, a gtk/glade based GUI version of wulfstat that will likely have similar functionality and features. Given the xml format of the output, it should be a very simple matter to create a web-based client (possibly as simple as defining a suitable DTD and embedding calls in a display update loop). Similarly, it should be very easy to write a perl script to loop over nodes, extract their load averages (or any other measure of interest) from a persistent xmlsyd connection, and execute alarms or send mail according to any criterion desired.