In my earlier post about Open Source Customer Service, I mentioned GroundWork Open Source. I found these guys while searching for a Nagios VMWare appliance image. GroundWork has taken Nagios and wrapped it and extended it to add functionality and to make setup and administration a ton easier.
If you’re worried about how to get started with GroundWork, their download area has options to install it yourself, boot an ISO “Live” image, or run it as a VMWare or Virtual PC VM image. You should be able to find at least two good ways to get up and running in a hurry. Documentation is good, and as a bonus, I received a number of emails with sincere offers to help if I needed anything. I didn’t feel like I was being ambushed by used-car salesmen, though (you’ve probably experienced that from some vendors).
Like other mixed-source vendors (ex: SugarCRM), GroundWork has a free Open Source option as well as paid options. I worked with the Open Source product, which has been plenty-powerful for me. Paid products add features and support. GroundWork just announced GroundWork Connect, a support portal for paid customers.
I haven’t been able to spend the time required to really explore all facets of this framework, and despite the excellent documentation and support, it’ll take time to really get the most out of a system like this. Although you can view a network monitoring solution as an application, it really bears a lot of resemblance to a programming environment in the way you organize your work, collect bits of logic into modules, and coordinate the operation of those modules.
At the simplest level, this system will tell you what machines are up and which are down, but there are lots of systems that will tell you that much. Things start getting interesting when you begin to factor in which applications reside on which machines, which machines depend on which other machines, which applications depend on which other applications, and so on. There are some really powerful possibilities here for someone who takes advantage of them.
Personally, I’d like to look at incorporating some response-time / QOS metrics in at least one scenario. I have a feeling that using GroundWork to collect some real information would allow me to produce some pretty compelling pictures about what’s happening to application-level quality under different loads.
The only thing I’ve seen so far that you may want to look into before diving in is hardware requirements. Depending on the size of your organization and the amount of sampling you’re going to do, hardware requirements can start to creep into the range of a “real nice machine” — a powerful CPU and multi-Gig RAM setup is described for large-scale monitoring. I expect that most organizations will get by with lots less horsepower, but check this out when you evaluate.
Hopefully, I’ll be able to share some more input on GroundWork after I put a few more miles behind me. I’ve seen a lot to like so far.