de-couple notification settings from a service ?

[stucky]

Guys

Generic question. At this time it appears I have to tie a notification profile to a service it if want it to ever alert.
Problem is that when I define a service I don't necessarily know whether it should alert or not. F.e. a check for /var should show up on the dash but not alert for stg systems.
The same service should alert for prd. According to how I understand it I'd have to create various versions of the same service

1. check /var without alert
2. check /var with alert to a certain group

But what if I need the same check on another set of systems and I want to alert to another contact group ? I'd end up with God knows how many versions of the same /var service.
That cannot be it. However, I have not found a way to de-couple the notification from the service and inherit it from a hostgroup instead. In my opinion this would be the way to do this.
I'd imagine creating the service without a notification profile, then I associate it to a hostgroup, but that implies that I can associate a notification profile with a hostgroup.
That option isn't available as far as I see.
Even if I could overwrite the service notification it still requires the creation of another service that monitors the same thing.

I'm sure I'm looking at this wrong. Any ideas are appreciated.

thx

[Box293]

I think Escalations are going to be your answer. Escalations over-ride standard notification options and allows for different scenarios to apply.

Have a look at this guide:
http://assets.nagios.com/downloads/nagi ... ations.pdf

[stucky]

This doesn't seem right. It feels like a workaround. What if I have various groups of systems and the services on them should alert various different groups ?
This has to be a common scenario. What do other folks do here ? Do you really set up the same service multiple times, each pointing to a different contact group ?

[jdalrymple]

I think the solution is to stack your templates properly.

Create the following templates:

var_service --> disable notifications and use generic_service
var_service_notify --> enable notifications and use var_service_notify

is_important_to_adminsa --> insert contactgroup adminsa and use var_service_notify
is_important_to_adminsb --> insert contactgroup adminsb and use var_service_notify
is_important_to_adminsc --> insert contactgroup adminsc and use var_service_notify

Apply as needed.

Does that sound about right?

[stucky]

jda

I'm not sure I follow exactly. What is "is_important_to_adminsa" ? A template or a service ? What does it describe ? What is "important" ? /var ? It's not clear to me.

Can you break this down for the following scenario:

1. I have "hostgroup a" and "hostgroup b". Both monitor /, /var, /tmp
2. For "hostgroup a" all alerts for those 3 mountpoints should go to "contact group a"
3. For "hostgroup b" all alerts for those 3 mountpoints should go to "contact group b"

Could you show the templates and services you'd create with their relationships ? f.e.

tmpl_service_var_notify
-tmpl_child_etc...

hostgroup a -> srvs_du_var_etc -> from template "tmpl_child_etc"

that would help a lot.

thx

[jdalrymple]

First let me point out the source of all knowledge in this matter:
http://nagios.sourceforge.net/docs/nagi ... tance.html

Now...

Take a look at the 3 files I've created:

1 - framework.cfg: (this is where the magic is made)

Code: Select all

define host {
       name                                     compound-host-template
       max_check_attempts                       1
       register                                 0
}

define service {
       name                                     compound-service-template
       use                                      generic-service
       max_check_attempts                       1
       check_interval                           1
       notifications_enabled                    1
       notification_options                     w,c
       register                                 0
}

define host {
       name                                     template_a
       use                                      compound-host-template
       hostgroups                               hostgroup_a
       register                                 0
}

define host {
       name                                     template_b
       use                                      compound-host-template
       hostgroups                               hostgroup_b
       register                                 0
}

define service {
       name                                     template_contacts_a
       use                                      compound-service-template
       hostgroup_name                           hostgroup_a
       contact_groups                           contactgroup_a
       register                                 0
}

define service {
       name                                     template_contacts_b
       use                                      compound-service-template
       hostgroup_name                           hostgroup_b
       contact_groups                           contactgroup_b
       register                                 0
}

define hostgroup {
       hostgroup_name                           hostgroup_a
       alias                                    A hosts
}

define hostgroup {
       hostgroup_name                           hostgroup_b
       alias                                    B hosts
}

define contactgroup {
       contactgroup_name                        contactgroup_a
       alias                                    A
       members                                  andy
}

define contactgroup {
       contactgroup_name                        contactgroup_b
       alias                                    B
       members                                  bill
}

define contact {
       contact_name                             andy
       host_notifications_enabled               1
       service_notifications_enabled            1
       host_notification_period                 24x7
       service_notification_period              24x7
       host_notification_options                d
       service_notification_options             w,c
       host_notification_commands               notify-host-by-email
       service_notification_commands            notify-service-by-email
       email                                    root@localhost
}

define contact {
       contact_name                             bill
       host_notifications_enabled               1
       service_notifications_enabled            1
       host_notification_period                 24x7
       service_notification_period              24x7
       host_notification_options                d
       service_notification_options             w,c
       host_notification_commands               notify-host-by-email
       service_notification_commands            notify-service-by-email
       email                                    root@localhost
}

2 - services.cfg:

Code: Select all

define service {
       name                                     check_var_contacts_a
       service_description                      Check /var on A hosts
       check_command                            check_dummy!2
       use                                      template_contacts_a
}

define service {
       name                                     check_var_contacts_b
       service_description                      Check /var on B hosts
       check_command                            check_dummy!2
       use                                      template_contacts_b
}

define service {
       name                                     check_/_contacts_a
       service_description                      Check / on A hosts
       check_command                            check_dummy!2
       use                                      template_contacts_a
}

define service {
       name                                     check_/_contacts_b
       service_description                      Check / on B hosts
       check_command                            check_dummy!2
       use                                      template_contacts_b
}

define service {
       name                                     check_tmp_rcontacts_a
       service_description                      Check /tmp on A hosts
       check_command                            check_dummy!2
       use                                      template_contacts_a
}

define service {
       name                                     check_tmp_contacts_b
       service_description                      Check /tmp on B hosts
       check_command                            check_dummy!2
       use                                      template_contacts_b
}

3 - hosts.cfg: (this is where the magic happens)

Code: Select all

define host {
       host_name                                host_a
       use                                      template_a
       address                                  192.168.145.1
}

define host {
       host_name                                host_b
       use                                      template_b
       address                                  192.168.145.1
}

The thing to illistrate is that because of all the work (not really that much) put into laying out the templates properly, I was able to define my hosts and assign 2 things to get the results you specified. I had to assign a template, and an IP address (and I guess a name).

Obviously making all of this happen in XI looks a bit different than what you see here, the idea here is to show you what happens under the hood so that when you're in the CCM creating your configurations you understand how to do it most efficiently to simplify your configuration down the road.

I recommend reviewing the link at the top, understanding my configs and seeing how it works for you. Incidentally if you want to play with it, you could take all of these configs and put them in your static directory then you can visually see how it works on your XI server, although it won't show up in CCM.

Let us know if we can help further.


Just to add further information in case it's not plainly visible what's happening above... the framework at the top has allowed me to greatly shorten the process of creating new hosts AND services. If I wanted to add a service to that "type" of host (perhaps name templates more proper to your environment) I only need to add the 4 things shown in the example, name, description, template and command. To add a host you only need to define 3 parameters, as described above.

What this does is greatly shorten the definitions for hosts and services as they can pick up the necessary bits from templates. Now what this doesn't do is solve the problem of having a zillion different *types* of hosts and services. There is no cure for the problem of every host having different requirements. If in this case (and as described by your requirements) some grouping can be done - this is how you'd do it.
-- edit -- Further clarification

[stucky]

jda

Thank you for this example. However, you ended up creating 2 services for /var as well - each pointing to a different contact group. That was the very thing I was trying to avoid.
I'm pretty sure I do understand the object inheritance. I had asked the question here because I didn't see how inheritance solves my problem. It appears you have confirmed that it doesn't.
I had been thinking along those lines already but I didn't see how it serves me. F.e. you have created 2 templates and 2 services with a 1-1 mapping.

template_contacts_a -> check_var_contacts_a
template_contacts_b -> check_var_contacts_b

why not simply create one service template without contacts and 2 services that both inherit it ? Then set the contact list on each service directly (rather than inheriting it) and, as far as I can tell, I have achieved the same thing you have with one less template.

template_du_var -> check_var_contacts_a (tie "contacts_a" to this service)
template_du_var -> check_var_contacts_b (tie "contacts_b" to this service)

It's entirely possible that I'm wrong here. Am I ? Can you tell me what the extra template achieves for you ?

Thanks for your help. I'll read the object inheritance piece once again

[jdalrymple]

why not simply create one service template without contacts and 2 services that both inherit it ? Then set the contact list on each service directly (rather than inheriting it) and, as far as I can tell, I have achieved the same thing you have with one less template.

Nope, you're right - that's a good way to do it. There is definitely some redundancy in my configuration, it wasn't meant to be ideal so much as it was meant to demonstrate the process.

You have a solid understanding I think, and with that in mind - what would a simpler solution look like to achieve the result you seek:

a check for /var should show up on the dash but not alert for stg systems.
The same service should alert for prd. According to how I understand it I'd have to create various versions of the same service

I'm not sure I can see a way to make it any simpler. Group like stuff together, then create a service dedicated to those like things.

[stucky]

Thx jda

Possibly in the future we could add the ability to tie a hostgroup to a contact group and then have all services running in that host group inherit the contact template from the hostgroup.
For now I guess I know what I have to do.

Thank you for your time. This forum is great !

[jdalrymple]

Thx jda

Possibly in the future we could add the ability to tie a hostgroup to a contact group and then have all services running in that host group inherit the contact template from the hostgroup.
For now I guess I know what I have to do.

It's not so bad - I promise

It really helps if you're coming from the Nagios Core world into the Nagios XI world. When you used to spend hours writing config files instead of clicky clicky and having php do preliminary data validation for you it was easier to appreciate what the forefathers of Nagios had in mind. Truly, assigning contact groups to host groups (and "groups of service") is what we're doing by way of the templates, there is just an extra step involved.

We're absolutely happy to help, and happy to try to make your environment work better for you. Feel free to reach out.