Back in "the day," it was sufficient to know that if your IBM midrange computer was running, your users would be able to access the programs required to do their jobs. Today, things are much different. With the advent of distributed network computing, it is much more difficult to know whether or not your users are or will be having trouble. If just one of the interconnected servers, switches, or other devices has a failure (and no redundancy has been implemented), then it's possible for a cascade failure to occur, bringing your users' productivity to zero.

Clearly, some kind of automated monitoring system is required to maintain maximum availability of your systems. While many such products are available, their cost can be prohibitive for smaller shops, thus relegating these shops to using the tried-and-true Organic Monitoring And Alerting System (OMAAS). Although OMAAS is an effective, no-cost feature of all network installations, I have always found the sound of the alarms produced by OMAAS to be overly strident and demanding, not to mention that OMAAS is wildly inaccurate as to urgency. What I wanted was a replacement for OMAAS that was highly configurable, so I could decide what truly constitutes a problem worthy of paging me in the middle of the night. What I found during my research for such a product is this month's jewel: Nagios.

Simple Monitoring Complicated

If you are like me, at some point in your career you have written a program to monitor a machine, a device, or the status of another program. While the concept can be quite simple ("Bones?" "It's dead, Jim."), the actual implementation of even the simplest monitor can get very complex.

Let's assume that you have been tasked with writing a program to monitor a critical server's availability. For a TCP/IP network, the first software tool that everyone "reaches for" to ensure the availability of a machine is ping, so you decide to use it as the basis for your program. A few lines of scripting later, you have a workable program that pings the target host and, depending upon the success or failure of the ping, either sends an email notification to you or sleeps for some time before testing again. Simple, right? Not so fast.... What percentage of the pings need to be answered for you to be satisfied that things are OK? 100%? 50%? 25%? Obviously, something is wrong if the majority of your packets are getting lost in the ether somewhere. And what happens if an intervening device, such as a router, fails? Your critical server isn't down, just unreachable, so what exactly are you going to report as failed? What if the machine status oscillates between available and unreachable? Are you going to send a notification each time it fails? And of course, a successful ping only denotes that the machine's TCP/IP stack is alive. It doesn't tell you that the Web, database, and SMTP server are alive.

I'm sure you get the point: Even simple monitoring can be complicated, which is why there has been a healthy market for commercial solutions. The open-source solutions aren't left wanting when compared with the commercial ones, however.

It Will Undoubtedly Work for You, Too

While surfing the 'net in my quest to automate my network monitoring, I found myself at the home of Nagios. The description I found there seemed to cover all of the bases:

Nagios is a host and service monitor designed to inform you of network problems before your clients, end-users or managers do. It has been designed to run under the Linux operating system, but works fine under most *NIX variants as well. The monitoring daemon runs intermittent checks on hosts and services you specify using external "plugins" which return status information to Nagios. When problems are encountered, the daemon can send notifications out to administrative contacts in a variety of different ways (email, instant message, SMS, etc.). Current status information, historical logs, and reports can all be accessed via a web browser.

This paragraph pretty well describes the majority of the monitoring software available, either commercial or open source.

Most of us tend to buy things that are popular. We ask around and find out what make and model of vehicles our friends are neighbors are purchasing before buying one ourselves. We also tend to do the same with software purchases, soliciting opinions from our peers before making an acquisition. It's no secret that products with the most marketing clout tend to be acquired more often than lesser-known products, regardless of their quality. (This seems to be particularly true in the software world.) Knowing that I'm as guilty as the next person in this regard, I consciously try to do better research before committing to a product. Thus, when I was turned on to Nagios by the buzz I found in various mailing lists about the product, I thoroughly scanned the Nagios Web site. The information I found there gave me that warm, fuzzy feeling that I was on to something good.

To start with, Nagios has a " link that shows a summary of the places that Nagios is discussed, including conferences, books, and Linux distributions. The list of conference presentations was particularly impressive, as it shows the scope of Nagios' worldwide distribution.

Of greater interest to me was the user profile statistics link, which gives a summary of the users who have taken the time to register their implementations with the Nagios project. At the time of this writing, 954 registered users are running Nagios on 11,580 monitoring hosts. These monitoring hosts are standing watch over 190,761 hosts and the 697,408 services running on them. Those are pretty impressive numbers! The top registered user appears to be an ISP, which claims to be monitoring 60,000 hosts and 130,000 services with Nagios. What types of things does the ISP monitor? According to its detailed profile, "We monitor Cisco network equipment, and Linux, Solaris, FreeBSD, NetBSD, and Windows 2003 servers."

It's readily apparent that Nagios scales very well. If it can handle the load this ISP is giving it, then it will undoubtedly work for you, too.

Modest Requirements

Creating an instance of Nagios is only slightly more difficult than creating an instance of most of the better-known open source software products. You have two options: use the standard tar file installation (which will work on any Linux distribution or UNIX-like operating system) or, if you use an RPM-based installation such as SuSE or Red Hat, use the RPMs thoughtfully created by Dag Wieers (the links are on the Nagios site). The hardware requirements are modest and can easily be met by one of those old Pentium III machines you have stored in the closet. Our instance is a Pentium III 500 with 384 MB of memory and a 20 G IDE drive. We use CentOS 4 on the box (a derivation from Red Hat Enterprise Linux). You need Perl loaded on the machine as well as the Apache Web server, since Nagios has a Web-based front-end that you'll use to control it or to retrieve status reports.

Once the software is installed, you need to create the configuration files. This is easily the most time-consuming part of the installation because, as with all things Linux, there are multiple ways to do the same thing. Nagios currently has two different config file formats: an "all-in-one file with contents that look like transmission line noise" version and a nicely formatted version that splits the file into related content. Both are text files and can be generated by your own scripts, if you like. For example, I did the base population of my hosts file by massaging the output of the "dig" utility (which dumps information from my DNS server) with a home brew script. Other config files include ones for contacts and contact groups, host groups, services, and the commands that Nagios needs to use for each check. It's the interrelation between these files that can make things quite complicated. Fortunately, Nagios does approach these in an object-oriented fashion, so you can create generic objects of each type and then have specific instances inherit properties from the them.

Some of you may shy away from Nagios because of the configuration, but I guarantee that it isn't as bad as you might think. The key to successful deployment of Nagios is to read the documentation provided with the software and then, before you start configuring, have a clear idea of the hosts and services you want to monitor, the metrics by which you decide that there's a problem, and the people you want to notify in each case. If you have this information, then the configuration isn't all that bad. If you want to get a jump start on the process, you can always hire someone to do the initial installation and configuration for you. Commercial support is available, as is the standard free support offered by mailing lists and Web sites. Just check the Nagios site and click on the link for more information.

Get Control of Your Network

Once you get your Nagios system up and running, you'll wonder how you ever got along without it. I don't mean to sound trite, but I can attest that it's a wonderful thing to get a jump on problems and know about them before your users do. Somehow, bad news seems less stressful when it comes from an emotionless machine rather than an irritated human.

Our Nagios box monitors 91 hosts for us, including all of our services, switches, UPSs, and environmental monitoring equipment. It keeps tabs on 131 services and lets us know if any of them are getting sluggish or are failing. It even warns when disk space is getting tight on our machines. We have Nagios sending notifications to our RT instance (see: " Do You Have Issues?"), so I can track trends, failure rates, and problem resolutions very easily.

Extending Nagios is simplicity itself. If you can't find a plug-in to suit your requirements (which is somewhat doubtful, since there are plug-ins to monitor virtually every network service out there, including SNMP-enabled devices), you can write your own. Once configured, Nagios will call your script, and if the script exits with a 0 status code, all is well. An exit code of 1 results in a warning, and an exit code of 2 tells Nagios that there is an error condition. You can extend Nagios to keep tabs on literally anything that it can reach through the network.

Isn't about time to retire your OMAAS and really get control of your network? Be sure to visit the Nagios site. Read some of the docs and presentations, and I know that you, too, will be intrigued by the product. The price is certainly right, and the flexibility is unbeatable. As soon as I submit this article, I'm off to bed, secure in the knowledge that Nagios will let me know if there's a problem. Good night, all!

Barry L. Kline is a consultant and has been developing software on various DEC and IBM midrange platforms for over 23 years. Barry discovered Linux back in the days when it was necessary to download diskette images and source code from the Internet. Since then, he has installed Linux on hundreds of machines, where it functions as servers and workstations in iSeries and Windows networks. He co-authored the book Understanding Linux Web Hosting with Don Denoncourt. Barry can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..