Notifications going to an *unintended* contact?

Support forum for Nagios Core, Nagios Plugins, NCPA, NRPE, NSCA, NDOUtils and more. Engage with the community of users including those using the open source solutions.
HappMacDonald
Posts: 6
Joined: Tue Apr 30, 2019 4:10 pm

Re: Notifications going to an *unintended* contact?

Post by HappMacDonald »

Thank you Tgriep, we have created a "null" contact group and sprinkled that into services not intended to share contact pragma with their hosts and our tests show notifications now going in the intended directions.

So from my perspective as a user — while I can totally appreciate how inheritance from host to service can save time in many people's setups — I liken the entire melange of "almost everything inherits into almost everything else" as saving time in much the same way as global application state saves time.

https://softwareengineering.stackexchan ... te-so-evil
https://dzone.com/articles/what-global-state

It means new users have to type less and enjoy side effects that seem intuitive to them, but it further complicates the work for anybody doing more advanced patterns to trace down where changes to their behaviors are really coming from.

Grepping through nagios config files to see where a property actually got inherited from is quite a lot like grepping through entire C or PHP source code trees to see every place in the code where a certain variable *might* be getting changed.

Most object oriented languages have code anylizers, IDE plugins, or debuggers that will clarify how everything inherits so that you can trace down the true source of any given property or the provenance of an unqualified symbol anywhere in your code. In languages like Elm that haven't made it that far yet, best practice is to qualify all of your symbols.

Because CSS uses a similar mess of inheritance, even every modern web browser's built-in dev tools have inheritence tracking features so that when some particular paragraph unexpectedly presents a purple polka-dot background, you can trace down several levels of CSS selector to see which association leaked that property into that unintended context.

I would recommend something similar for nagios property inheretance.

1> If you feel like recursive grepping and memorizing all the inheritance rules is easy enough, then it should similarly be easy enough to whip up a bash script that does it automatically to benefit whoever else doesn't find it so simple.

2> If the config processor is already building an objects.cache file, then it shouldn't be that much of a stretch for it to (optionally?) tack on comments clarifying file and line number each inherited property originally hailed from.

At least, those are features I feel like would benefit folks and cut down a lot of time debugging problems, especially as config production starts to get automated and seas of configs come from different sources. :J
User avatar
tgriep
Madmin
Posts: 9177
Joined: Thu Oct 30, 2014 9:02 am

Re: Notifications going to an *unintended* contact?

Post by tgriep »

You should take a look at Nagios XI then.
In the Core Config Manager menu, you can click on the relationship icon for an object and it will show you what that object it linked to.

https://www.nagios.com/products/nagios-xi/
Be sure to check out our Knowledgebase for helpful articles and solutions!
Locked