A major downside of Nagios Core's configuration being so flexible is that without proper management, the configuration can easily balloon into hundreds of files with thousands of objects, all having unclear dependencies. This can be frustrating when you attempt to make significant changes to a configuration or even for something as simple as removing a host or sifting through dependencies to find what's causing errors in the configuration that prevents you from restarting.

It's therefore important to build your configuration carefully using as much abstraction as possible to allow adding, changing, and removing hosts and service definitions from the configuration painlessly and to avoid a duplication of configuration. Nagios Core provides a few ways of dealing with this, most notably in the judicious use of groups and templates for fundamental objects. Duplication of network-specific and volatile data, such as passwords, is also to be avoided and this is best done with the use of custom macros defined in a resource file.

This chapter's recipes will run through some examples of good practice for the configuration of a large network. The most important recipes are the first two: Grouping configuration files in directories and Configuring host roles using groups. If you're looking to untangle and revamp a messy configuration, these two recipes would be the best place to start.

At the end of the chapter, the final recipe, Dynamically building host definitions, will show one of the primary advantages of a tidy configuration in being able to easily generate configuration according to a list of hosts and services kept in some other external information source, such as a configuration management database (CMDB).