8

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

6 Answers 6

4

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.

6

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!

3
  • 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, 2010 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" ? Mar 26, 2010 at 13:44
  • Lilac seems to be discontinued but continued as lilac–reloaded.
    – hlovdal
    Apr 24, 2016 at 9:01
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.

1

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.

0

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

0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .