A very important issue is how to store all our configuration files. We can put every object definition in a single file, but this will not make it easy to manage. As mentioned in Chapter 3, Configuring Nagios, it is recommended to store different types of objects in separate folders.
Assuming your Nagios configuration is in /etc/nagios, it is recommended that you create folders for all types of objects in the following manner:
/etc/nagios/commands /etc/nagios/timeperiods /etc/nagios/contacts /etc/nagios/hosts /etc/nagios/services
Of course, these files will need to be added to the nagios.cfg file. After having followed the instructions in Chapter 3, Configuring Nagios, these directories should already be added to our main Nagios configuration file.
It would also be worthwhile to use a version control mechanism such as Git (http://www.git-scm.com/), Mercurial (Hg, http://mercurial.selenic.com/) or Subversion (SVN, http://subversion.tigris.org/) to store your Nagios configuration. While this will add overhead to the process of applying configuration changes, it will also prevent someone from overwriting a file accidentally. It will also keep track of every change in the configuration files, so you will always know what exact change (and who) has broken the monitoring system.
You might consider writing a simple script that will perform an export from the source code repository into a temporary directory; verify that Nagios works fine by using the nagios -v command. Only if that did not fail will we then copy the new configuration in place of the older one and restart Nagios. This will make the deployment of configuration changes much easier, especially in cases where multiple people are managing it.
As for naming the files themselves—for time periods, contacts, and commands—it is recommended that you keep single definitions per file, as in contacts/nagiosadmin.cfg. This greatly reduces naming collisions and also makes it much easier to find particular object definitions. This does not prevent an object from referencing another object—for instance, it is fine for a time period to use an exclude option referencing a time period from another file.
Storing hosts and services might be done in a slightly different way—host definitions should go to the hosts subdirectory, and the file should be named the same as the hostname, for example, hosts/localhost.cfg. Services can be split into two different types and stored, depending on how they are defined and used.
Services that are associated with more than one host should be stored in the services subdirectory. A good example is the SSH service, which will be available on the majority of hosts. In this case, it should go to services/ssh.cfg, and host groups should be used to associate it with the hosts that actually offer connection over this protocol.
Services that are specific to a single host should be handled differently. It's best to store them in the same file as the host definition. A good example might be checking the disk space on partitions that might be specific to a particular machine, such as checking the /oracle partition on a host that's dedicated to Oracle databases.
For handling groups, it is recommended to create files called groups.cfg and define all groups in it, without any members. Then, whenever you deifne a contact, host, or group, you can define to which groups it belongs by using the contactgroups, hostgroups, or servicegroups directives accordingly. This way, if you disable a particular object by deleting or commenting out its definition, the definition of the group itself will still work.
If you plan on having a large number of both check command and notify command definitions, you may want to split these into two separate directories— checkcommands and notifycommands. You can also use a single commands subdirectory, prefix the file names, and store the files in a single directory, for example, commands/check_ssh.cfg or commands/notify_jabber.cfg.