Automatically deploy monitoring services using NagiosXI, NCPA and Hostgroups.

Did you know that with the use of NagiosXI templates and hostgroup features you can auto-magically deploy and remove monitoring service object associations (services) to your host?

Did you know that you can do this solely based on hostgroup membership?

This one-to-many method of service object deployment lowers the toil associated to management by dramatically reducing the total number of individual services that must be curated within your NagiosXI instance.

CPU, Memory & Disk Oh My...

One of the best examples is taking the lowest common denominator (LCD) CPU, Memory & Disk services that are deployed to every host, configure them once and then deploy them to an entire group of like hosts.

Lets just say, hypothetically, you have a thousand homogeneous infrastructure servers that have the same build and thus the same CPU, Memory and Storage utilization expectancy during normal operations and, you're responsible for monitoring them.

Do you want to manage three thousand individual service configurations with the same settings or would you rather manage three or four configurations applied across all thousand hosts?

I mean is that really a choice?

Getting NagiosXI ready for one-to-many service deployment.

Everything we need is already available as a feature in the Core Config Manager (CCM) for NagiosXI.

In the example I'll use a CPU Utilization check can be used as a guide for other monitoring services based on NCPA.

The example requires that you have admin privileges in NagiosXI and a minimum of NCPA version 2.4.1 or greater installed on the target endpoint in order to follow along.

Start by creating a user macro to store the NCPA Token used for active service checks.

You're going to use a token for every active service check that you deploy.

Managing that token in 10 or 10,000 individual service configurations is a nightmare. With the token stored in a macro, your response time to update all services using that token is now tracked in minutes at the most.

If you're using NCPA, use the macro...

Create the Nagios command for use with the NCPA token macro.

With the token stored in XI, create a modified copy of the check_xi_ncpa command named check_xi_ncpa_new.

With the new command the macro for the token, port, timeout variables for check_ncpa are set on the command line while the remainder of the required check_ncpa variables will be passed as $ARG1$ in the service config.

Create a service template for check_ncpa that utilizes the new Nagios command named ncpa_service_token.

This template will inherit the settings from the xi_generic_service. If you do not wish to maintain this hierarchy, edit your template appropriately before you continue.

Create hostgroups used for monitoring service deployment.

In this example I'll set extremely low CPU utilization thresholds for a group hypothetical dev web servers named dev-linux-web.

In this group are only single user dev servers and due to resource constraints none of these should have a greater than 40% CPU utilization under normal circumstances.

The group will contain only these dev servers.

Create the services linked to the NCPA token template and associate them to the hostgroups.

When deploying services in NagiosXI I find it very helpful to employ naming conventions for my services especially if I'm going to be integrating into upstream applications like ServiceNow.

Config Name:

This is a unique field for XI, I name the config to help identify where it is applied.

Description:

class.category.metric.measurement

Display Name:

metric.measurement

Check Command:

check_xi_ncpa_new

$ARG1$

This contains the module definition (-M ), warning threshold (-w ), critical threshold ( -c ) and query string (-q ) to pass to NCPA.

For more information on NCPA check the Nagios documentation.

The rest of the settings will be inherited from the template.

Assigning the service to the dev-linux-web hostgroup ensures that all of our servers will now have the CPU utilization services with the required thresholds deployed automatically when assigned membership to the XI hostgroup.

With the bulk of the settings in already set in the template there is not much to do in the rest of the service configuration barring the need to change a default setting or add a contact group.

Last step, assign host to the NagiosXI hostgroup

There are two methods to accomplish this task.

1. Grant membership at the host configuration level.
2. Grant membership at the hostgroup level.

You can use either of these methods although when using the NagiosXI API I have found it much easier to manage hostgroup membership at the host level vs the hostgroup.

Once a host has been added to the hostgroup and changes are applied, NagiosXI will pickup the new services for the hostgroup members.

The services function as would any other active service check in NagiosXI without having the individual reference in CCM.

Wrapping up the example and taking it forward.

Although the example is only for CPU utilization with some simple copy and paste actions you can continue to create any check_ncpa powered service having them deployed in the same manner or create your own services with the macro enabled token.

1. Create or use an existing hostgroup
2. Create a check_ncpa based service
3. Assign the macro enable template to the service
4. Assign the service to the target hostgroup
5. Assign hostgroup membership to the host

When assigning group membership at the host level the removal of assigned services is automatic if the host is deleted from NagiosXI.

Using NagiosXI to your advantage.

Incorporating this one-to-many method of service deployment strategy with other time saving features such as the host management options available in the NagiosXI API greatly reduces the toil involved in the deployment of your monitoring services.