Okay, here is some more info from the author...

http://madstop.com/svn/libmetrics/

At this point it's just about pulled directly out of ganglia, although I've added a bit so it actually acts like a library interface -- your code doesn't need to know as much about the internals.

It should be straightforward to build a client around this code.

This post just came up on the hobbitmon mailing list:

<snip> So my idea currently is to design a new type of client. It won't generate "status" messages, it will just collect data. Imagine a client that just sends Hobbit a "client data" package, like

[...]

This shouldn't be difficult to do, but it's just about exactly what ganglia already does. Unfortunately, ganglia is relatively special-purpose and thus won't scale to doing other tasks like sending alerts, but it already sends all of its data to a central node, and you can easily configure aggregation nodes that then send the rest of the data further upstream. It's a pretty slick system for getting graphs of data, and because it's all XML you can easily parse the data and do whatever else you want with it.

I think it is the same concept at the metric thing I am thinking about. It may be a development shortcut...

I highly recommend spending an hour or so getting ganglia working, just so you understand it and know how much it can already do. I don't know how much you're hoping to accomplish on the client, but ganglia might suffice.

In general, I agree that for many cases it makes sense for clients to push performance data to the server, especially for info that can only be collected locally like disks, as long as you have some process on the server that causes an alert if it hasn't heard from the client recently.

The reason I split the libmetrics stuff out (and no one else is actually using it at this point, although the ganglia people have expressed interest in coding to the library instead of what they have) is because I'm planning on using it eventually in puppet, so that puppet could actually collect these stats as one of its tasks and then make them available via SOAP or something. At some point your config mgmt tools will have to integrate with your monitoring tools, so that you can do things like respond to high or low loads, so I'm just thinking a bit ahead on that.

Craig Cook

Systems Monitoring Consulting and Support Services http://www.cookitservices.com