[hobbit] Current development plans

[Craig Cook]

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