You will need to have a server running Nagios Core 4.0 or later, have access to the command line to change its directories, and understand the basics of how hostgroups and servicegroups work. These are covered in the recipes Creating a new hostgroup and Creating a new servicegroup in Chapter 1, Understanding Hosts, Services, and Contacts.

In this example, we'll create two simple hostgroups; one will be called servers, for which a PING check should be made for its member hosts, and another will be called webservers, which should include HTTP checks for its member hosts. Once this is set up, we'll add an example host sparta.example.net to both groups, thereby easily assigning all the appropriate services to the host in one definition, which we can cleanly remove simply by deleting the host.

We can create our group-based roles for hosts like so:

With this done, you should now find that all of the services you defined for the hostgroups you created are attached to the appropriate hosts:

The configuration added in the preceding section avoids assigning services directly to hosts; instead, it assigns them to hostgroups, thereby creating roles for services that hosts can adopt or discard simply by becoming part of or leaving the group.

Apart from making the configuration shorter, another advantage to this approach is that if services are added this way, adding or deleting a host from the Nagios Core configuration requires nothing but adding or removing the host definition. Similarly, if a host takes on another role (for example, that of a web server adding a database functionality), we can modify the services being checked on it simply by modifying its hostgroups. This ends up being much easier than adding dependencies in other files each time we make a change to the functions of hosts.

Another advantage is that having hostgroups organized by a host function is helpful to apply batch operations such as scheduled downtime in one easy action or to check all the services for one particular type of host. Once a hostgroup is defined, we can run operations on all the hosts within it by clicking on its name in brackets in any of the hostgroup views.

For example, if we had twenty web servers that we knew we were going to be down, this would be much easier than scheduling the downtime for each of them individually!

It's worth noting that hostgroups can have subgroups, meaning that all of the hosts added to any of their subgroups are implicitly added to the parent group.

For example, we can define the webservers hostgroup as a subgroup of the servers hostgroup using the hostgroup_members directive, as follows:

define hostgroup {
    hostgroup_name     servers
    alias              Servers
    hostgroup_members  web-servers
}

This would allow us to add hosts to both groups implicitly without needing to refer to the parent group and with all the services assigned to both the groups assigned to the host. Take a look at the following code:

define host {
    use         linux-server
    host_name   athens.example.net
    alias       athens
    address     192.0.2.22
    hostgroups  web-servers
}

This can be very useful to sort "subcategories" of services. Other examples might include a dns-servers group with the dns-authoritative-servers and dns-recursive-servers subgroups or a database-servers group with the oracle-servers and mysql-servers subgroups.