We define a contact_groups field in our hosts definition called say “host-admins”. We define a contacts field (and -no- contact_groups field) on a service definition monitoring a service on the host. Because the implied inheritance feature for contact_groups ignores the fact that a contacts field -is- defined on the service definition (and that should be enough IMHO no?), -service- alerts also get sent to the hosts’s contact_groups recipients…which annoys them as they don’t consider the application’s service monitorings “their problem”.
The doc show a nice way to cancel -template- inheritance. Give the field the the keyword value null. I thought it would be nice if I could define the contact_groups field in the service and give it the keyword null as the value to cancel the implied inheritance of contact_groups from the host also. No joy. Perhaps an enhancement? Or perhaps having a contacts field defined be enough to override implied inheritance of contact_groups from the host?
Anyway my hack workaround was to define a contacts_group called “bitBucket_group” with a dummy contact as a member with an email address which mails to a /dev/null mailbox. So now I define contact_groups in my service template and give the field the value of bitBucket_group. Crude, but effective. Of course this lets me override the field in the service definition itself in those cases where I do want the field with real recipients.
First post here and searched first but found no related thread so apologies if I missed it. Otherwise if you’ve thoughts/better idea or need to tell me I’m drowning in a drop of water I would be much obliged.
“standard” (at least from what i’ve seen until now) is to use contact_groups in all host/service definitions, which then expands to contacts when sending the alerts. Nothing prevents from having a contact_group for a single contact, this way you wouldn’t have that problem. There’s one more passage but you automatically overwrite the inherited definition.
Fair enough, but then I would suggest the documentation should inform of “standards” and perhaps share what the downsides of not using the standards are.
More robust would be to disallow the use of contacts field in host/services definitions and simply allow use in the members field of a contact_groups definition.
That is, unless we can agree on a negative to this beyond the added overhead of creating single-member contact_groups.
By my defining the bitBucket_group contact_groups field in my service template in essence I’ve adopted the “standard” to which you refer Luca so I guess this is good enough.
My concern is that I lived with this issue for some time before tracking it down because at least to me, it wasn’t immediately obvious what I’d done incorrectly.
My feeling is that if we discover a use-model which creates undesired behavior, we should preclude the use-model from being defined, again unless we can agree on a compelling reason for keeping it.
The best software programs I think we can agree, aren’t the ones that work well when the users do “what the author assumed” he/she would do, but instead work well when the user tries something unexpected. A tall order of course, but in this case one that could be solved without a lot of heavy lifting.
