Nagios configuration management

I am going to implement Nagios (most likely anyway, could turn out to be another tool as well) and I was wondering if anyone would like to share their best practices when it comes to creating, managing and maintaining the config files when it comes to scalability and managability as I find that it might quickly become a real big mess.

Any tips, examples or even full configurations would be most welcome and I'd happily look them over.

Tools would be welcome as well. Tried out NConf so far, but the generated config files don't seem to do what was promised (not including the parent information for one, and just a PITA to get them working - they generate a ton of errors when checking the config files with the script supplied by nagios)

Thanks


Solution 1:

As it turns out, I wrote a HOWTO for sane Nagios configurations: http://www.standalone-sysadmin.com/blog/2009/07/nagios-config/

Basically, meesterfox is on the right path. Keep your hosts in discrete files, use inheritance to your advantage, and create a directory hierarchy for your configs that map to the real world.

Solution 2:

I use Fruity. I find it's a huge help, the nagios config files can get very unwieldy!

Fruity is an open-source web-based configuration tool for the Nagios network monitoring system. It is designed to provide a logical process of creating and managing your network. It is written in PHP and uses the AdoDB database abstraction library.

Apparently it's now known as Lilac... hmm, guess I should upgrade!

Solution 3:

In the past, I've used git to manage changes to various configuration files. At each configuration change, the files are checked into the repository. At various times, usually after a major change, we would push the repository to a central location, as a dirty way of doing backups. This worked fairly well, but had it's issues. Mostly with just forgetting to check in files as things changed.

Solution 4:

i have a nagios setup that monitors multiple hosts from multiple agencies. i use folders for hosts and services (as opposed to 1 massive file), then 3 letter prefix for the agency, then a descriptor like "switches", "servers", "printers" or "workstations" separated by underscore. i also find it way easier to have hostgroups declaration inside a host object than to have a members declaration inside a hostgroup object. this way you only edit 1 file when adding new hosts to pre-existing groups.

i make heavy use of templates (on their own file) so the right folks get notified on the right service for the right host.

oh, and of course, i use version control (svn for now, migrating to git).

this works beautifully! i can easily manage it. only 1 problem: pretty much no one else understands nagios config files where i work, so i am moving this to lilac, which works great and leverages the templating system really well.

i my previous job i setup fruity (there was no lilac yet) so others could also feel comfortable adding hosts to nagios.