Page 1 of 1
Null contact prevents inheritance of contact groups
Posted: Fri Aug 14, 2020 1:02 pm
by onetruebob74
Hello all,
A quick desciption of my setup:
1. All hosts get a standard set of service checks
2. These service checks are setup as generic services and are assigned to a hostgroup (i.e service_hg)
3. The hosts get these service checks by having the service_hg assigned to it in it's host definition
4. All hosts have a common contact group assigned via template (i.e. systems_cg)
5. There are some hosts that have an additional contact defined (i.e. snow_contact), but not all hosts.
6. I do not want the generic services in service_hg to ever send notification to snow_contact.
Given the above scenario, I set the contact to null in the generic service definitions, expecting it to never send to SNow but keep sending to cht contact groups that are defined. However this is not the case as setting the contact to null in the servi
ce definition seems to have disabled sending notifications to the contact group as well, but this is counter to how I read the docs. So, is this the expected behavior?
Running Nagios XI 5.7.2
CentOS Linux release 7.8.2003 (Core)
Thanks,
Bob
Re: Null contact prevents inheritance of contact groups
Posted: Mon Aug 17, 2020 2:25 pm
by jbrunkow
I may have to see your entire configuration to know exactly what is going on here.
It's possible that there is another
local object overwriting what you have done with the template.
One important thing to understand with inheritance is that "local" object variables always take precedence over variables defined in the template object.
Object Inheritance
It sounds like expected behavior to me. Did you see something in the docs that led you to believe the null service definition would take a higher precedence than the contact group? If so, please reference it here so that we can discuss.
Please send (
PM ) me a profile so that I can take a more detailed look at your configuration. You can download the profile by navigating to
System Profile under
System Config on the left pane > and clicking the
Download Profile button on that page.
Re: Null contact prevents inheritance of contact groups
Posted: Mon Aug 31, 2020 8:56 am
by onetruebob74
Hello. I sent you the information you requested over PM but have not heard back. Just making sure you saw those messages.
Re: Null contact prevents inheritance of contact groups
Posted: Tue Sep 01, 2020 9:32 am
by jbrunkow
Yes, I did see it. I will analyze that file and get back to you as soon as I have found something.
Re: Null contact prevents inheritance of contact groups
Posted: Tue Sep 01, 2020 4:26 pm
by benjaminsmith
Hi Bob,
Thanks for sending the before and after profile. If you can pick out and specific host and service and I can trace it back in the configurations, that would be very helpful.
I do not want the generic services in service_hg to ever send notification to snow_contact.
There are number service templates in the configs. Is the following template, the one you have set to null from your description?
Code: Select all
define service {
name Email_Support
service_description Support Level Email: 24x7 Email Support
display_name Support Level Email: 24x7 Email Support
use xiwizard_generic_service
notification_period 24x7
contacts null
register 0
}
For example, looking over the configs the YUM Update Status service is not sending to either the snow contact or the contact groups, is this intended? If not, which contact groups are you expecting a service like this to send to? The null setting shouldn't override the contact group, but how are you assigning the contact group to the services? Thanks, Benjamin
Code: Select all
define service {
host_name !pkiprod01.pki.virginia.edu,!pkiprod02.pki.virginia.edu,!pkitest01.pki.virginia.edu,!pkitest02.pki.virginia.edu,!pkiws01.pki.virginia.edu,!pkiws02.pki.virginia.edu
service_description YUM Update Status
use Email_Support
hostgroup_name standard_build_servers
display_name YUM Update Status
check_command check_nrpe_variable_timeout!180!check_yum!!!!!!
is_volatile 0
initial_state o
max_check_attempts 1
check_interval 720
active_checks_enabled 1
passive_checks_enabled 0
check_period 24x7
obsess_over_service 0
check_freshness 0
event_handler_enabled 0
flap_detection_enabled 0
flap_detection_options w,
notification_interval 0
notification_period none
notification_options w,c,r,
notifications_enabled 0
register 1
}
Re: Null contact prevents inheritance of contact groups
Posted: Wed Sep 02, 2020 9:35 am
by onetruebob74
The only change I made between the two profiles was to the cpu_stats.cfg service definition. They yum check service is actually meant not to send notifications so thats not a good example. One to compare the cpu stats against would be the check_mem. The mem check does not contain the null in the contacts field and it sends email to all contacts and contact groups defined for any host it is assigned to. The cpu_stats.cfg when it has the contact set to null does not send any notifications to the contacts (which is to be expected) nor the contact_groups (which I wouldn't expect) that are defined in the host.
Two example hosts you could look at are ws01.its.virginia.edu.cfg, which uses the Email_Support template where contact_groups has ecp-sss defined in it, and download01.its.virginia.edu.cfg which uses the A_24x7x365_CI template where contact_groups has ecp-sss defined as well as contacts has servicenow defined. The check_mem service when assigned against ws01.its will contact ecp-sss and when assigned against download01.its will notify both contact_group ecp-sss and contact servicenow. The cpu_stats service, with the contact defined as null, will not notify either the contact_group ecp-sss nor the contact servicenow. The behavior I would expect based on my reading of the documentation would be for cpu_stats to still notify the ecp-sss contact_group but not the servicenow contact as that will have been overridden by the null contact in cpu_stats.
Does that clarify anything or is it still clear as mud?
Re: Null contact prevents inheritance of contact groups
Posted: Thu Sep 03, 2020 10:32 am
by benjaminsmith
Hello
@onetruebob74,
Does that clarify anything or is it still clear as mud?
Well, it's getting a little less muddy, thanks for pointing out the hosts and services to trace back. I would agree with your assessment, it does seem like the cpu stats service would inherit the contact group from the hosts.
However, it looks like some of the other rules regarding object inheritance are kicking to give precedence to the local values in the service object over implied inheritance. From the documentation,
When you use multiple inheritance sources, it is important to know how Nagios handles variables that are defined in multiple sources. In these cases Nagios will use the variable/value from the first source that is specified in the use directive. Since inheritance sources can themselves inherit variables/values from one or more other sources, it can get tricky to figure out what variable/value pairs take precedence.
I'd have to reach out to a developer to get some more clarification on the inner workings, but for now, if you set the contact group at the service level, that might be a good workaround. Otherwise, you could use the bulk mod tool to add the contact group to the service to get it working as required.