Free Monitoring Solutions: Hard to Deploy and Manage

Free IT monitoring software is a fixture in the computing landscape. And, depending on where it fits into your IT stack, it can have a ton of benefits for the enterprise. Linux, though not without its own issues and (both kernel- and distro-related) politics, is an established and economical datacenter platform technology with literally billions of users. Apache and NGINX are bedrock web platforms, together supporting 80+% of all websites. With those kinds of numbers, it’s easy to find enthusiastic community support, skilled employees and consultants, authoritative best-practice documentation, tools and adjuncts -- everything you need to make this software work for your business. There are whole IT economies built around -- not just enterprise users of these bedrock products -- but enterprise users who are just like you, in terms of scale, use-cases, and requirements.

That can be less true for free software that’s more complicated, less popular, less actively or formally developed, and whose evolution has historically been driven by the needs of smaller organizations -- or simply by organizations with different goals and economics from yours. Free- and open source IT monitoring software often falls into this “more debatable” category. There are apparent upsides, sure -- starting with the fact that “it’s free!” And in the case of a few venerable products, like Nagios, it’s popular: if only in the sense that many orgs have used it, many are still using it in various forms, and it’s routinely shortlisted by ad-hoc advisors.

But -- free though it might appear -- this kind of software can be a bad deal for organizations hoping to use monitoring at scale, in sophisticated ways, as an enabler for making IT more agile, while controlling associated costs. We recently asked sysadmins and CIOs to share some of the challenges they encounter with free IT monitoring solutions, and summarized those results in a solution brief.

Free Monitoring: Hard to Deploy and Manage in Production

Now we’re digging deeper into those themes, the first being that free solutions can be hard to deploy, configure, and lifecycle-manage in production. What does this mean, exactly?

Manual deployment and integration is often required

The latest versions of popular free monitoring solutions may take a while (on the order of years) to become available in official software repositories for quick, one-step installation. This can leave users stuck with earlier versions, compel them to build latest versions from source (somewhat more arduous, error-prone, and much harder to maintain), or oblige them to seek in unofficial repositories, in which packages may be of uncertain origin or quality. Other free monitoring solutions may have similarly-daunting basic deployment recipes.

It’s not yet a complete solution, usable by mortals

In the case of Nagios (mileage may vary with other free offerings) that’s just to set up the engine and its plugins -- the very barest bones of a solution. There’s no web front-end yet: just a set of Common Gateway Interface (CGI) routines you can call from a browser (or using curl or various SDKs) to summon crude web displays and forms. There’s no configuration capability for monitoring beyond a set of files you’ll need to generate, by hand or with additional tools. To create a solution that can be used, day to day, by non-experts, you need to go quite a bit further: selecting and integrating one of many community-provided front-ends, optional web graphics enhancements for prettier charts and histograms, and other components. You’ll need to create users in Linux, perhaps distribute more fine-grained permissions by modifying the CGI files themselves, and configure basic (or, preferably, more sophisticated) means of authentication. And you’ll need to configure monitoring itself, which can be complicated. We’ll comment more on all these topics, in later blogs in this series.

It’s still not a solution that’s ready to scale

After all this work, you’ll have a basic monitoring solution in a configuration appropriate for a small company. How small? That’s actually hard to say -- see below. The big take-away, here, is that you’re not yet enterprise-ready in terms of scale. To become so, you might need to deploy and integrate workers -- each requiring roughly the same level of effort to create and configure as the master. You may also need to consider extending and clustering the shared storage and implementing redundant failover for workers and master, using Linux heartbeat, Merlin (a Nagios-specific failover system), or recommended third-party open source tools. Creating clusters and failover groups is typically not simple. And the resulting complex systems can be hard to test and make truly reliable.

Now you have a “special snowflake”

At dint of long effort, you now have a highly-customized implementation of your solution, scaled to monitor a sizeable IT estate. The skills to recreate and run it are yours alone. Some call this “job security.” Cost-conscious CIOs, however, recognize it as a critical dependency that tends to limit growth, hamstring agility and beneficial change, and steal focus from critical-path work that’s important to your business’ bottom line. We’ll discuss this more in our next blog.