In the previous chapter, we walked through the standard Nagios plugins, which can be used to monitor a large variety of hosts and services. We learned how the plugins can be used to perform specific and generic checking of the IT resources. This chapter describes some guidelines that will help you migrate from small (and increasing) Nagios setups to a flexible model by using templates and grouping effectively. Any experienced administrator knows that there is a huge difference between a working system and a properly configured system. Using this advice will help you and your team survive the switch from monitoring only critical services to checking the health of a majority of your IT infrastructure.
This chapter focuses on how to set up templates, groupings, and the naming structure. However, creating a robust monitoring system involves much more; be sure to read the following chapters, which talk about monitoring other servers and setting up multiple hosts that use Nagios to monitor your network and report to a single central machine, as well as how to monitor hosts running the Microsoft Windows operating system.
In this chapter, we will learn the following:
- Creating maintainable configurations
- Configuring the file structure
- Defining the dependencies
- Using the templates
- Using the custom variables
- Understanding flapping
An enormous effort is required to deploy, configure, and maintain a system that monitors your company's IT infrastructure. The configuration for several hundred machines can take months. The effort required will also depend upon the scope of hosts and services that should be tracked; the more precise the checks need to be, the more time is needed to set these up.
If your company plans to monitor a wide range of hosts and services, you should consider setting up a dedicated server solely for running Nagios. Even though a small Nagios installation consumes few resources, as it grows, Nagios will start using more resources. If you set it to run on the same machine as business-critical applications, it can lead to problems. Therefore, it is always best to set up Nagios on a separate machine right from the beginning—even if the machine has fewer resources than a bigger one, shared with other applications.
A good approach is to start with monitoring only critical parts of your network, such as routers and main servers. You can also start off with only making sure that essential services are working—DHCP, DNS, file sharing, and databases are good examples of what is critical. Of course, if your company does not use file servers, or if databases are not critical to the production environment, you can skip these.
The next step would be to set up parenting and start adopting more hosts. At some point, you will also need to start planning how to group hosts and services. In the beginning, the configuration might simply be definitions of people, hosts, and services. After several iterations of setting up more hosts and services to be monitored, you should get to a point where all of the things that are critical to the company's business are monitored. This should be an indication that the initial configuration of Nagios monitoring is complete.
Note
As the number of objects grows, you will need to group them. Contacts need to be defined as groups, because if your team consists of more than one to two people, they will likely rotate over time. This provides a better way to maintain a group than changing the people responsible for each host individually. Hosts and services should be grouped for many reasons. It makes viewing the status and infrastructure topology on the web interface much easier. Also, after you start defining escalations for your objects, it is much easier to manage these using groups.
You should take some time to plan how group hosts and services should be set up. How will you group objects for escalations or for viewing single host groups via the web interface? Learn how you can take advantage of this functionality and then plan how you will approach the setup of your groups.
If your network has common services, it is better to define them for particular groups, and only once— such as the SSH server for all Linux servers and Telnet for all Advanced Interactive eXecutive (AIX) machines, which is an IBM operating system that is mainly used by IBM enterprise-level servers. It is possible to define a service only once and tell Nagios to which hosts or host groups the service should be bound. By specifying that all Linux servers offer SSH, and all AIX servers offer Telnet, it will automatically add such services to all of the machines in these groups. This is often more convenient than specifying services for each of the hosts separately.
In such cases, you should either set up a new host group or use an existing one to keep track of the hosts that offer a particular service. Combined with keeping a list of host groups inside each host definition, this makes things much easier to manage; disabling a particular host also takes care of the corresponding service definitions.