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.

We currently have Nagios 2.9 installed and has been running nicely for a few years. I want to migrate it off that old Linux server onto a new one. I've gotten Nagios 3.1.2 installed and running fine. Before I migrate all 240+ of our devices over to the new install, I'm curious as to how other SysAdmins are configuring it.

I've heard of: - Each host in its own config file with it's corresponding services, and you can copy then edit the file to easily add a new device, and all like devices in separate folders. - All alike hosts in a single config file. With or Without all services in that same config file. - All Hosts and services in one file. Then dependencies laid out in a separate file (our current config)

How are the Nagios config files arraigned in your system? I'd like to get differing ideas to make ours the most efficient it can be.

share|improve this question

6 Answers 6

I recently divided files by business area, then into staging/production, but that required too much prior knowledge from other colleagues to just find something and change it. Also we moved some servers around and I realised it would be useful to have config-per-host files that could be moved as well. Also, having config-per-host allows you to neatly encapsulate all the monitoring for a particular host (or hostgroup) in one file, and see easily what you are doing for that host. On top of that we have a central commands.cfg file, divided up by each business area which can be easily searched.

However none of this is truly satisfactory - using flat-file storage for configuration commits you to favouring one particular ordering method over another. This sort of configuration really benefits from the relational model. Most new monitoring products have implemented configuration from a database for this reason, I guess.

Currently NDOUtils (warning: pdf) gets your config and event data into a database, but as far as I know there's no way to tell Nagios to use that database as config source. It does give you the opportunity to create tables aside from those required by NDOUtils, perhaps creating a separate nagios_config database where you can map things out and then script up a solution that pulls this information out of the database and creates your config.

I'm going to try and use Puppet to generate my Nagios configs in the near future, hopefully it will let me resolve these sorts of issues.

share|improve this answer

Our setup for is one config file per host, but they are all contained in one "hosts" directory. Then we specify this directory with "cfg_dir=" in the nagios config and any hosts added to that directory are automatically picked up on the next reload.

share|improve this answer

I have several groups of identical hosts. So I have a config file for each "type" of host and use a host group definition at the top of the file so that I only have to have 1 set of service definitions per "type". I also have some hosts that are unique which get their own config file and I keep escalations in a separate file per host/type so that I can turn them off simply by commenting out the line that imports that particular file.

share|improve this answer
    
+1 we did a similar thing, grouping services by type (ie - email.conf, ntp.conf), and found it very easy to manage this way. Just recently converted to OpsView, and it's nice to have a GUI for the configs, so management isn't entirely dependent on me (the only linux guy) anymore :) –  Brent Jul 17 '09 at 19:29

In our case, the Nagios configuration files are created by using m4 and make to generate the configuration files from m4 macro files. This increases the ability to easily replicate even complex configurations across multiple hosts, and to change configurations and have it take place across all configurations.

The utility make is also used to restart or reconfigure Nagios as necessary, and to check the configurations after generating them.

In this case, all hosts of a particular operating system are in one file, and the "passive" configurations are all in another file - all in a single directory. Another directory contains services and groups (again, using m4 macros).

share|improve this answer
1  
We use a perl script to take a text file like "host:ping,ssh,http" and turn that into a config file. –  David Pashley Jul 17 '09 at 19:05

This question really depends upon the individuality of your hosts. If you can get all of our hosts to a nice little standard, you can really work some magic with templates. Personally I find that it works for only the very basics (for example, Mem/Proc/Services on windows) Then it starts getting harder (one server has a File system that needs to have alerts sent to a production support group for space size violations, but it also has other File Systems that need to go to the development support group. And oh by the way, this server has unique drives because it was bought on a golf and shop trip by your boss)

Personally I used a combination of Nagios 2.0 and 3.0, with a mix of Host groups. I separate hosts out into OS grouped configs (windows with windows, Solaris with Solaris, Linux with Linux). Then I break out the core checks into a core_checks.cfg (Memory, Processor, essential process checks) then I break the services that I monitor down into different config files (Oracle Database checks, My Sql Datbase checks, Very Specific File system checks, Website checks). This lets me have my config files organized logically for myself and anyone who comes after me. Note I do have 4400 checks these days so this might be overkill for other people.

In the long run, I have a structure something like this nagios\etc\core_checks.cfg nagios\etc\hosts\windows_servers.cfg,solaris_servers.cfg nagios\etc\services\oracle_databases.cfg,MSSQL_databases.cfg

share|improve this answer

The approach of using one config file by server monitored is simple and flexible to handle.

In my point of view the biggest difference are found in how you implement your nagios templates. It could be easy to change one option that affects all servers in only one file (template) that all servers still using or you need to change in a lot o configuration files.

In a large setup you will see the difference in file size using or not templates, without templates you could keep from Kb with templates to Mb easily that affect the startup time of nagios.

share|improve this answer

Your Answer

 
discard

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