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)

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.

Lilac is excellent, includes rudimentary auto-discovery, and supports nagios3. Ive been using it since 2008 and cant imagine how much effort its saved vs editing config files by hand.
–
DevnullMar 26 '10 at 13:40

Lilac looks extremely promising. Wouldnt happen to know if it works with Icinga as well? Or if Icinga is compatible with "nagios configurations" ?
–
HannesFostieMar 26 '10 at 13:44

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.

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.

Maybe I'm just stubborn, but i like my config files. It's easy to work with them and back up. But, there are good reasons to using something like lilac. But, I like to KISS.

anyway, the way I have it: config dir is set to objects. All hosts get their own file, within which is anything having to do with it. that way, if i have to remove a host, i can move the file, and the config won't complain. this also works out well for adding hosts; just dupe a file, change the name and address, sed the hostnames, and bobs your uncle.