Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question
add comment

6 Answers

up vote 4 down vote accepted

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.

share|improve this answer
add comment

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!

share|improve this answer
2  
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. –  Devnull Mar 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" ? –  HannesFostie Mar 26 '10 at 13:44
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

NagiosQL is yet another config tool. Configuration is stored in MySQL.

As Jon says above, using a versioning system to track changes is a good way to go.

\\Greg

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.