Puppet, Monitis and Open-Source Configuration Management

Here at Monitis, it’s our ultimate goal to make the life of sysadmins, webmasters and other IT pros easier – especially when it comes to monitoring networks, servers, apps, cloud platforms and other key IT processes.

That’s why, in this post, we’re offering guidance on how you can deploy the Monitis monitoring agent and configure it using Puppet, the open source configuration management system. If you already use Puppet, go straight to the section below called “Distributing the Monitis Agent Using Puppet.” If you are not using any system configuration management yet, then we invite you to read this entire post for a brief introduction.

Open Source Configuration Management Software

For many companies, sysadmins spend an extraordinarily large amount of time manually configuring the management of servers and services. If not properly automated, you wind up with too much dependency on human intervention. Paul Anderson in his article “Why Configuration Management is Crucial,” illustrates this problem with few simple questions on the following aspects of config management:

  • “Reliability—If we decommission a server, can we be certain that nothing else depends on this server in any way? Perhaps it might have been the only DHCP server on some little-used subnet, and problems will only become apparent when some host on that subnet fails to boot.
  • Security—Can we be certain that the configuration files on a group of machines are set up so that there are no unexpected trust relationships between the machines? What if a supposedly secure machine installs new versions of an application from a remote file system on a less secure server?
  • Correctness—Can we be certain that every compute node in a cluster is running the required (new) version of a particular library before starting a critical job?”

As we see it, it’s clear that answers to those questions will never be complete in a environment without automated configuration management. Further, without automated configuration management, it is difficult to establish a working change management process, and without stable change management process, it is extremely difficult, if possible at all, to establish sound incident management and problem management processes. As a result, the entire Operations begin to slowly slip, efficiency of work and quality of supported services starts to decline, and pressure on staff and customers’ irritation grows.

Fortunately, you can turn to mature and stable solutions to automate these tasks: configuration management systems. You’ve probably heard about them. What you may not know, however, that some of these solutions are open source, and they carry a cost. For example on Wikipedia’s page that’s dedicated to open source configuration management software, one can find a brief comparative analysis of 23 of such open source configuration management systems!

One of the most popular systems is Puppet. Among companies using this system, you can find such names as SUN, Citrix and Zynga.

All about Puppet

Puppet is an enterprise systems management platform that standardizes the way IT staff deploys and manages infrastructure in the enterprise and the cloud, according to the company’s website.

“By automating the provisioning, patching, and configuration of operating system and application components across infrastructure, Puppet enables IT staff to master their infrastructure even as complexity grows,” the site continues.

Puppet is written in Ruby, an open source programming language with a focus on simplicity and productivity, and released under the GPL (GNU general public license) version 2. It is intended mostly for managing the configuration of Unix-like systems. Windows support is not expected to be available beyond 2011.

Puppet features a declarative language (According to Wikipedia, declarative programming is a programming paradigm that expresses the logic of a computation without describing its control flow. Declarative language allows for creation of a graph of resources for easy reproduction of configurations, even in heterogeneous environments.) The user provides Puppet templates for describing parts of the system, and, when these templates are deployed, the runtime puts the managed systems into the declared state.

To briefly explain Puppet topology The Puppet Introduction uses the following diagram.

Puppet Master is a central management daemon. It serves compiled configurations, files, templates, and custom plug-ins to managed nodes. Puppet Agent runs on each managed node. By default, it will wake up every 30 minutes to check in with Puppet Master, send it new information about the system, and receive a ‘compiled catalog’ describing the desired system configuration. Puppet Agent then takes on the job of making the system match the compiled catalog.

There are many ready-to-use patterns for configuring Puppet. You may think of them as recipes in Puppet language. Some can found here. For others, you have to search. There is also active community support and a commercial entity, Puppet Labs (formerly Reductive Labs), which provides a commercially available extension via Puppet Enterprise.

There are also two books on Puppet published by Apress: “Pulling Strings with Puppet: Configuration Management Made Easy” by James Turnbul, and “Pro Puppet” by James Turnbull and Jeffrey McCune.  “Pulling Strings with Puppet…” is designed for novice users, while “Pro Puppet” is comprehensive follow-up for more advanced users.

Now, let’s move on to the guide for automated distribution of the Monitis’s Agents using Puppet.

Distributing the Monitis Agent Using Puppet
In order to enable Monitis monitoring on a Unix or Linux node, an agent should be deployed and run there. In the case of large number of nodes, this task can be delegated to Puppet. To do this, put the Monitis agent files on the Puppet Master server. Next, add Monitis Agent class description to the configuration. Please find a class start-up example below; you can certainly change it at your discretion.

Class monitis {

file { “/usr/local/monitis”:
owner => root,
group => root,
recurse => true,
source => “puppet:///monitis/monitis”,

exec {“monitis-echo”:
command => “bash /usr/local/monitis/etc/monitisconf.sh”,

Simply download the Monitis Agent and put it on Puppet Master. Then ‘untar’ it and change in the “/etc/monitis.conf” file e-mail entry from the default “example@mail.com” to your Monitis account e-mail. Next, distribute the Monitis Agent to client nodes. The Puppet clients will copy the agent content from the Puppet server and run a script that will name an agent as hostName_hostIP, and then run it. That’s all that’s to it!

Now, go to the Monitis Console to manage checks from your agents.

We hope that this post will somehow encourage those of you who never used configuration management tools to give them a try. I’m convinced that using such tools shows the level of discipline of a sysadmin.

In the near future, look for another post on how you can integrate Monitis with other popular open source configuration management platforms.