Although this is a HOWTO, ironically, it doesn’t cover the actual configuration of Nagios. It covers the part of the configuration that might actually be harder than creating hosts, groups, and services. It covers how to organize your configuration directory in a way that makes it easiest to add new hosts, groups, services and commands in a logical manner. Organization is the key to a successful Nagios configuration…

Ah, Nagios configuration. It’s a topic that’s near to my heart. I was actually whining about it the other day, if you read my review on Learning Nagios 3.0.

Anyway, as a matter of serendipity, a day or so after I posted that review, Ray Holtz posted a question on the sysadmin network about nagios configurations. Ray currently has all of his services and hosts configured in one file, and has his dependencies in another file. That’s not really that far off from the default install, but it’s painful to update and administer. He wanted to know if there was a better way.

Scrolling through a giant file like that takes a lot of time, and trying to keep track of changes is the pits. After working out the configuration in my head for a while, I think I’ve got a pretty decent system, and I’m working on making it better. Here goes.

To give you an idea of scale, I’m monitoring somewhere around 100 hosts between two nagios servers. I’ve got two physical sites (well, technically four, but two critical sites), and each site has its own Nagios install. Each nagios install monitors all of the local servers plus the remote nagios server, plus all of the network connections. This way I’ll be alerted if either of the nagios machines go down, any of the network connections go down, or (obviously) any of the “normal” servers have issues.

As for individual server configuration management, I’d recommend you put your entire /usr/local/nagios/etc directory into a subversion repository (along with libexec, too). I have to admit that I haven’t done this yet, but it’s in the works. I want to be able to track changes to my config over time, and subversion is a great way to do that.

I create a hierarchy of subdirectories under etc/objects. Here’s how mine looks: