configuration changes best practice

[naginewbie]

Hi There,

I have just installed a Nagios Core server to test out its monitoring capabilities. The install instructions that I found made that pretty easy. Adding a windows host to monitor was quite a bit more difficult for me. I imagine that adding a second host would be a bit easier, now that I've learned a little about how to use Check_NRPE. Also I realize that it may even make sense for me to create a template file and a config directory with a config file for each host in it. Although I have yet to discover how to use host groups, service groups and templates etc so perhaps not. But I was wondering how people generally deal with adding/removing/updating hosts, service configs, thresholds etc. And maybe it's just me but it seems odd to have to completely restart the services every time we want to add or remove or a host or even a single service to monitor, is that what people do? They aren't tweaking their config that much?

So, yeah, let me know if there's a typical way this is handled? A URL that talks about managing the configuration/administration of nagios core or a high level trick or technique would be helpful.

Thanks!

[eloyd]

Come to the 2016 Nagios World Conference and ask!

Actually, people do a lot of things: Subversion, Puppet, Chef, lots of other automated tools. In the end though, you have to manage Nagios Core by tweaking config files. There are some utilities that tweak them for you (pyNag for instance) and you can get a lot of mileage out of check_mk and LiveStatus, but in the end, someone has to edit configuration files.

How you manage those configuration files is up to you and how you manage any other configuration file.

[naginewbie]

Come to the 2016 Nagios World Conference and ask!

Actually, people do a lot of things: Subversion, Puppet, Chef, lots of other automated tools. In the end though, you have to manage Nagios Core by tweaking config files. There are some utilities that tweak them for you (pyNag for instance) and you can get a lot of mileage out of check_mk and LiveStatus, but in the end, someone has to edit configuration files.

How you manage those configuration files is up to you and how you manage any other configuration file.

Haha, well, if i'm in Minnesota, I'll stop by ... Anyway, thanks for the software suggestions-- I'll check them out!

[rkennedy]

To add to this, a setup that I use with core is one file per hosts / services for that host. I then just reference that whole directory in the nagios.cfg. It works -- but, there are plenty of different ways to do it. The standard way that XI (our enterprise product) works, is to use one file per host, and one file per services.

Each environment is different, and sometimes you may be able to include a template to reduce your work load (https://assets.nagios.com/downloads/nag ... ricks.html). The product is very powerful, and gives you the freedom to make a structure that works 'for you'.

Let us know if you have any further questions!

[eloyd]

If you include a directory in the nagios.cfg file, then you will also include all sub-directories. This makes it very easy to manage your files however you want. But you still need to manage them.

[naginewbie]

Aha! Very helpful guys, thanks . Quick followup question, I know I mentioned this in my original post so sorry if I'm harping. Do people generally restart nagios with every config change (or group of changes)?

Or alternate thought, does it ever refresh it's configuration on its own and I've just never waited long enough to find out? I guess my instinct is to setup a cron job or something to restart or reload the config once a day or something. That way if I'm making a minor change i don't have to remember to restart it...

[rkennedy]

Nagios will need to be restarted in order to 'reload' the configuration.

You could do this on a CRON, but, if there is an issue with your configuration then it will cause Nagios to fail. Just food for your thoughts!

[eloyd]

As a followup, here's something we do on Nagios Core servers. We use Chef for some of this, but we also use rsync to move things around.

We have a development Nagios instance that has notifications and active service checks disabled. We drop new host and service definitions onto this server, reload the configs manually, check for errors, and then once it's good to go, we commit those to our file management system in an "approved configurations" file repository. The file management software (Chef/rsync) running on the actual production Nagios Core box(es) automatically syncs the repository every 15 minutes and if it finds changes, restarts the nagios process.

This way, we minimize configuration errors and never have to remember to restart the Nagios processes. Nagios itself monitors the file mgmt software so we know if it's not working.

[tmcdonald]

One other thing I will say, having been asked the "Best Practices" question dozens of times, is that the way you manage your configs is not nearly as important as being consistent and documenting your method. You could have the most logical setup in the world, but if someone else ever has to touch the system, or if you go a few months without making edits and forget your scheme, you will be kicking yourself for not having documented the system.

[naginewbie]

Thanks very much! Very helpful.

OK so Documenting-- really important of course!

I think the idea of one file per host and one file per service in config directories is great. I'm trying to implement and read up on doing that.
I had an idea for restarting nagios periodically after reading Eloyd's comment. So I wrote a script that takes the output from the nagios -v config verification and then if there are errors we Don't restart nagios. Otherwise it's okay to restart it. Also if there's errors it creates a file that says errors .
Then in nagios, I downloaded a plugin that's called check_file_exists and it'll look for that errors file and throw a critical status if the config is bad.

We'll see how that goes. This is still just a test at this point so I'm not intending to get too elaborate...

Best Regards, n-newb