Nagios Support Forum

I am trying to get my head around how best to configure our system with regard to the various service->host mappings.

Obviously it'd be crazy not to take advantage of Nagios object inheritance, but I'm having a hard time figuring out the sanest way to organize all the stuff we have. In fact, I'm really struggling to even explain what I mean, just with words, so I've drawn a visio diagram of a simplified portion of our infrastructure, in the hope that it is understandable.

The diagram shows kind of how I have it in my head as to the various relationships between hosts and services, but my issue is that I don't really understand how to convert that into the exact way to configure Nagios to match our requirements.

In the example below, I have 2 platforms, with basically the same infrastructure components, so it stands to reason that we should be able to configure things so that "ABC MTA" can be placed into a (host-group/host-template/service-group/service-template the trouble is, I don't know which), which causes the host to inherit all the service checks which are appropriate.
In this example: -

"ABC MTA" should get: -

Linux OS Services
* Disk Usage /, /var
* Load Average

MTA Services
* SMTP 25
* MTA SNMP checks

"XYZ MTA" should get: -

Linux OS Services
* Disk Usage /, /var
* Load Average

MTA Services
* SMTP 25
* MTA SNMP checks

XYZ Customer Specific Host/Service Details
* Bespoke check intervals

Global Admins will see: -

* Everything

Customer Contacts will see: -

* Only their own platform

Generic services such as "SMTP 25" will be valid for any MTA, so can be shared by any appropriate <this-is-the-bit-that-eludes-me>...

My goal is to make it so that when we add new platforms, the basic monitoring structure is already in place & we just need to add some customer-specific host-groups(?), contact-groups(?) and hosts into the correct <this-is-the-bit-that-eludes-me>...

I need to be able to document it so that any of my colleagues (or in fact me) adding a new "MTA", have some really simple instructions to follow.

OMG, I almost don't understand what I've written here. Bonus points for reading my mind.

Yeah, this is an interesting scenario to set up config management for. From my initial look at this, I would suggest using overlapping hostgroups, and then apply your services to the appropriate hostgroups. So Webserver Services and LInux OS Services are each hostgroups, with services applied to the group. In doing this, I would also use host->hostgroup assignments. That way you can easily add or remove from those groups by simply adding or remove the host config, and that will be the only thing you'd have to touch.

If that sounds like a lousy way to set it up, let me know and we can look at some other ideas

This type of setup also lends itself well to automation.
http://assets.nagios.com/downloads/nagi ... gement.pdf

mguthrie wrote:Yeah, this is an interesting scenario to set up config management for. From my initial look at this, I would suggest using overlapping hostgroups, and then apply your services to the appropriate hostgroups. So Webserver Services and LInux OS Services are each hostgroups, with services applied to the group. In doing this, I would also use host->hostgroup assignments. That way you can easily add or remove from those groups by simply adding or remove the host config, and that will be the only thing you'd have to touch.

If that sounds like a lousy way to set it up, let me know and we can look at some other ideas

This type of setup also lends itself well to automation.
http://assets.nagios.com/downloads/nagi ... gement.pdf

That's how I would do it as well.

This is as close to "canon" as it gets. It is the primary intention of the implementation of hostgroups, one could even call it the framers' intent.

Thanks for the replies. It does sound like it's the sanest way to go

OK, so for the sake of clarity (my feeble mind likes the power of pictures), does the following diagram fall in line with the we you've just described?
I think that one of the reasons I have struggled to get my head around this scheme, is that the Nagios object documentation I've been reading says: -

Host Group Definition

Description:

A host group definition is used to group one or more hosts together for display purposes in the CGIs.

But I've literally just now found another copy that says: -

Host Group Definition

Description:

A host group definition is used to group one or more hosts together for simplifying configuration with object tricks or display purposes in the CGIs.

That'll teach me to be more careful when googling...

That setup looks great, the groupings make sense and should streamline service check configuration on the hostgroups. The object tricks link contains a wealth of knowledge for leveraging the most out of hostgroups. Definitely worth a read.

The one thing to keep in mind, if you use hostgroups for defining all services on hosts, you can't customize on a per host instance.

For example, if you want to make sure a process/service is running on all hosts in a group, that is a good time to assign the service to a hostgroup. However, something that may need changed on a per host instance, like memory usage, you would want to have that service setup on each host as different hosts may need different thresholds for warning and critical levels. Another example would be load average on linux servers. Whatif you have some servers that run at a high load average, if the service is set at the hostgroup level, you wouldn't be able to customize the service for that host and it may always be in a warning state.

Hope I explained that well enough for you and didn't confuse you more.

BanditBBS, heads and nails. Some admins make a few different checks with different thresholds, others use nrpe and locally define the machine specific settings (but makes reconfiguring checks a pain). Certain storage volume checks have the same, host-specific configuration issues. Deploy once, deploy right. A full reconfiguration of a large installation due to oversights in deployment should be avoided if possible. XI is great and really streamlines the process, but nothing will solve bad planning. I hope we have been of help, you seem to have a good idea of how hostgroups work and have a good idea of how to group them. Best of luck!

Most of our checks are on SNMP OIDs and we get around the issue of differing thresholds for the same service checks, using a map file which contains the generic thresholds and any additional lines for abnormal hosts. We have a generic SNMP check command which handles SNMP checks by grabbing the config from a map file (which is located on the RAMdisk).
It'll be a while before we can migrate from this bespoke system onto a more standard and Nagios-integrated system, as it's working pretty well right now. We'd be more likely to go down the "passive" checks road, rather than duplicate the current setup

Thanks everybody for confirming our design plan.

Cheers!

Sounds great Chris, let us know how the migration goes.. we can leave this thread open but marked as resolved if you have future posts you'd like to add.