Introduction

In the first article in this series, I introduced the concept of hostgroup inheritance and (hopefully) laid it out in a way that it can be well understood. In this article, I’m going to start walking you through setting up a solid hostgroup inheritance foundation.

By the end of this article, you should have a functional hostgroup inheritance setup; however, I do not recommend running through these steps in your production environment. There will be future articles where we will expand on the functionality laid out here.

With that said, if you are running Nagios XI, you are allowed three instances of Nagios XI: Production, Test, and Disaster Recovery. This would be a good opportunity to fire up that “Test” instance of Nagios XI.

Begin by Beginning

For this first example, we’re going to setup hostgroup inheritance with a fresh install of Nagios XI. Once we’re done with this, you should have a good idea of how to retro fit an existing XI instance.

We’ll start this off by running a Configuration Wizard against a host that you want to monitor. The host that you want to monitor will, presumably, be one of a large number of similar hosts. In our example, we’ll use a basic Windows host being monitored using NCPA.

Now I don’t want to walk you through running the NCPA Wizard to monitor your Windows host. I’ll leave that as an exercise to you. The end result is that in the Core Configuration Manager (CCM), you now have a host with multiple services being monitored. If you go to the Services section of the CCM and display the config for the Windows machine you are monitoring, you should see something similar to this:

Changing a Single Service Check

You can see we’ve got CPU, disk, bandwidth, memory, and a service that we’re monitoring on this Windows box. Now we know that for all of our servers, whether Windows or Linux (or AIX, or Solaris, or FreeBSD, etc.), we want to monitor CPU and memory usage. Why create that over and over again? Why not just have that in some kind of template that can be applied to each server as you add it?

That’s what we’re going to do here. Before we modify that service, let’s create a hostgroup that will hold service checks for any OS. Click on Monitoring -> Host Groups -> Add New. Now for the Host Group Name and Alias fields, I like to keep this brief, yet descriptive. For this one I’m going to call it ncpa-anyos. Meaning the system is monitored using NCPA, and the service checks apply to any operating system. Click save.

Now go back to Monitoring -> Services and open up the CPU Usage service check definition (or whatever service you want to make available via hostgroup inheritance) and let’s convert it.

The first field we want to change is the Config Name field. In Nagios XI, this field typically lines up with the name or IP of the host it is tied to. But it doesn’t have to be that way. Let’s create a new config name by changing this to AnyOS. Meaning the service checks in this config will apply to any operating system.

Next, click the Manage Hosts button and remove the assigned host. And finally, click the Manage Host Groups button, and add the service check to the ncpa-anyos hostgroup. Realistically, that’s it. Now any host that you put in the ncpa-anyos hostgroup will have that CPU Usage service check. Go ahead and add a host to the ncpa-anyos hostgroup, apply the configuration, and check your host status screen.

Limitations

There are some immediate limitations with this setup as it is right now. We’ll dive into the fixes for them in my next article for this series. For now, I just want to call out one in particular.

Not all of your hosts will have the same CPU warning and/or critical thresholds. Or maybe they have different NCPA tokens. For those of you who don’t want to wait for the next article, I’ll point you in the right direction. In the next article, we’ll touch on using custom host variables and host templates to deal with the limitation of needing to customize different pieces of a service check. We’ll also be touching on creating a new command.

Additional Reading for Overachievers

Nagios Custom Macros.

Managing Plugins in Nagios XI 2024. Specifically, we will be looking at the Define A Command section of this document.

And since we’ll be talking about host and service templates, it might be good to brush up on Object Inheritance.

This article kicks off our Nagios Hostgroup Inheritance Series, where you will learn helpful tips and best practices for Hostgroup Inheritance.

Hostgroup Inheritance: What Is It?

Having worked in support and technical sales here at Nagios Enterprises, one of the requests I’ve regularly seen is the ability to have a “template of services” that can be assigned to a host. I put “template of services” in quotes because I don’t want you to confuse them with Service Templates, which are already a thing in Nagios, but they are distinctly not what people are looking for.

Currently, we don’t have an Easy Button for this, but there is a process called Hostgroup Inheritance that effectively gives people that “template of services” option. Upfront, there is a good chunk of work to be done. But in large environments, it will save you a ton of time.

It should also be noted that for smaller environments, Nagios XI has the Bulk Host Cloning & Import Wizard. This wizard can serve as a happy medium between running wizards against all of your hosts individually and implementing Hostgroup Inheritance.

The goal of this article series is to lay out the best features to use with Hostgroup Inheritance and how to set it up. I’ll be taking you through step by step, introducing each feature and the issue that it solves as we go.

In this article, I’m going to talk about configuration management and growing that configuration management, then I’ll be listing off all of the features we’ll be going over in the coming articles. In addition to all of that, I’ll lay out how to build a service check to use Hostgroup Inheritance from the ground up, followed by a shortcut that is specific to Nagios XI users.

There is a lot to cover, so let’s get started.

Out-Of-The-Box Nagios XI Config Management

The way that a person defines objects like hosts and services within Nagios Core (and by extension, Nagios XI) is through the use of plain text configuration files. There is no specific directory structure that you must use, which is somewhat of a double-edged sword. On the one hand, it offers maximum flexibility. On the other hand, I’ve seen countless systems where all hosts were defined in host.cfg, and all services were defined in services.cfg. Certainly, a valid way to do it. But that can get tricky when you try to implement it in larger environments.

The way Nagios XI manages configuration files is by using hosts and services directories. Each host has its host definition in the hosts directory. All of its services are defined in the services directory, in a file named after the hostname in the host definition.

So, in Nagios XI, when you look at a service definition in the Core Config Manager, you’ll see Config Name as the first setting. On the surface, this is a very safe and clean way to manage host and service configuration files. But there may be some issues of scaling when we look at larger environments.

Making Config Management Scale

The standard Nagios XI configuration management scheme does have plenty of upsides. However, I don’t feel like it scales very well. If you think about it, if you’re monitoring 100 servers, you’ve got 100 CPU service check definitions hanging out. Now, if you need to change the baseline for all 100 CPU service checks, you have to change 100 configuration entries.

Now that’s something that could be mitigated by the Bulk Modification Tools, Bulk Host Cloning & Import, or even some handy scripting with the Nagios XI API. But what if we also added configuration standardization into the mix?

Let’s say you’ve got a thousand or more servers you need to monitor properly. And let’s also say that a good chunk of them run Microsoft SQL Server. Like a good SQL Server admin, you configured those systems to have a drive for the OS, a drive for the data, and a drive for the transaction logs. Your other Windows servers only have a single drive. But these have three.

Do you want to remember to add monitoring for the two additional drives? Or do you want to assign a handy template to the host, a template with the name of the software the host is running, and have all of the appropriate service checks just show up? One of these sounds a heck of a lot better to me.

Why Doesn’t Nagios XI Just Do This?

Hostgroup Inheritance takes more than a little bit of setup. I’ve got dreams and aspirations of making a configuration wizard to help streamline the setup of Hostgroup Inheritance, but for right now, it does require a certain amount of thought, planning, and execution. More so than just standing up Nagios XI and running wizards against everything you need to monitor.

Thus, for many of our smaller customers, Hostgroup Inheritance isn’t worth the price of entry. Now, Nagios has always been about customization and fitting into as many environments as possible. To that end, I do want to see Hostgroup Inheritance made easier, making that price of entry come down, and making it available to more of our customers who fall somewhere between small and large environments.

Features You Need To Know

This article is already getting long. So, I’m going to lay out some additional reading that will help you in your Hostgroup Inheritance journey. I’ll cover the need-to-know in future articles related to Hostgroup Inheritance. But if you’re interested in the nitty-gritty, you might get a kick out of the features below.

Hostgroups

Well, we’re working with Hostgroup Inheritance. So, it’s best to know about hostgroups.
https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/objectdefinitions.html#hostgroup

Inheritance

The second word in Hostgroup Inheritance, is worth knowing about.
https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/objectinheritance.html

Host Templates

Host Templates will be key in our configuration of Hostgroup Inheritance.
https://support.nagios.com/kb/article/managing-host-templates-906.html

Custom Variables

Custom Variables will also be extremely important later in this series.
https://library.nagios.com/techtips/custom-variables-in-nagios-xi/

Stay tuned for Part 2 in the next article of the Nagios Hostgroup Inheritance Series!

Monitoring a complex IT infrastructure can be challenging, especially when managing multiple servers, network devices, and services. Host groups in Nagios XI offer a powerful way to simplify monitoring by organizing hosts into logical units. This article explores how host groups enhance efficiency, streamline alerting, and improve overall infrastructure management.

What Are Host Groups in Nagios XI?

A host group is a collection of hosts that share similar characteristics, such as location, function, or department. Instead of managing each host individually, administrators can assign settings, services, and notifications to an entire host group, reducing manual effort and improving consistency.

Benefits of Using Host Groups

• Simplified Configuration: Apply monitoring settings to multiple hosts at once
• Improved Organization: Group hosts based on roles, locations, or other criteria
• Efficient Alerting: Set up notifications for an entire group instead of configuring each host separately
• Better Visibility: Easily monitor host groups using dashboards and reports
• Faster Issue Resolution: By grouping similar hosts, administrators can quickly diagnose and address problems within specific areas of the infrastructure
• Reduced Administrative Overhead: Automation of settings and alerts across multiple hosts reduces the burden on IT staff

How Host Groups Simplify IT Infrastructure Monitoring

1. Centralized Configuration Management

Instead of applying monitoring settings to individual hosts, administrators can assign services, templates, and notification preferences at the host group level. This approach ensures uniformity and reduces configuration errors. Additionally, when new hosts are added to an existing group, they automatically inherit the monitoring rules, saving time and effort.

2. Efficient Service Assignments

With host groups, a single service check (e.g., CPU usage monitoring) can be applied to multiple hosts within a group, eliminating the need to configure the service separately for each host. This not only saves time but also ensures that all hosts within a category receive the same level of monitoring.

3. Streamlined Alerting and Notifications

Host groups allow IT teams to configure notifications for an entire group, ensuring that relevant alerts reach the right personnel without duplicating settings for each individual host. This approach prevents notification overload, where too many redundant alerts flood inboxes, and allows administrators to tailor alerting based on group priorities.

4. Enhanced Monitoring Visibility

Dashboards and reports in Nagios XI can display host group-based views, making it easier to assess infrastructure health at a glance. Administrators can quickly identify and address issues within specific groups of hosts. By filtering reports based on host groups, IT teams can gain more focused insights into the performance and uptime of critical systems.

5. Scalability for Large Environments

As IT infrastructures grow, managing hosts individually becomes impractical. Host groups provide a scalable solution by enabling administrators to manage large numbers of hosts with minimal effort. This is particularly beneficial for enterprises and data centers that manage hundreds or thousands of hosts. By structuring host groups properly, IT teams can maintain high levels of monitoring efficiency even as the infrastructure expands.

6. Improved Troubleshooting and Root Cause Analysis

When a problem arises, host groups enable administrators to quickly narrow down affected systems. For example, if all hosts in a “Database Servers” group report high CPU usage, administrators can immediately investigate database-related issues instead of checking each server individually. This speeds up troubleshooting and minimizes downtime.

7. Integration with Service Groups and Dependencies

Nagios XI allows administrators to integrate host groups with service groups and dependencies to further enhance monitoring efficiency. By creating logical dependencies between host groups and service groups, IT teams can reduce false alarms and better understand the impact of system failures. For instance, if a core router in the “Network Devices” group goes offline, alerts for all downstream hosts can be suppressed to prevent unnecessary notifications.

Best Practices for Using Host Groups

• Use Meaningful Group Names: Clearly define host group names based on function (e.g., “Web_Servers” or “Database_Cluster”)
• Avoid Overlapping Group Assignments: Ensure host groups are logically structured to prevent redundancy
• Regularly Review Host Group Memberships: Update groups as infrastructure changes to maintain efficiency
• Leverage Service Templates: Use service templates to apply consistent monitoring settings across host groups
• Monitor Host Group Health Trends: Use historical data to analyze group performance over time and make proactive infrastructure improvements
• Utilize Dependencies to Reduce Alert Noise: Properly configure host group dependencies to ensure only critical alerts are escalated, preventing alert fatigue
• Automate Host Group Assignments: Use automation scripts or configuration management tools to dynamically assign hosts to groups based on predefined criteria

Conclusion

Host groups in Nagios XI simplify IT infrastructure monitoring by reducing manual configuration, improving alerting efficiency, and enhancing visibility. By leveraging host groups effectively, organizations can optimize their monitoring workflows, ensuring a more streamlined and scalable approach to infrastructure management. Implementing best practices, such as using service templates and dependencies, further enhances the effectiveness of host groups, making them an indispensable tool for IT teams managing large-scale environments. By adopting a structured and automated approach to host grouping, organizations can maintain robust and reliable monitoring with minimal effort.