Hello,
we are monitoring our internal servers and network components within one global zone (around 50 hosts). Most of the checks are organized via Service-Sets and apply rules.
E.g. if operating system is Linux, apply these service checks, if this program is installed (via host variable), then execute these checks etc.
When starting the icinga client, we get several pages of warnings within the logfiles of the form: warning/ApplyRule: Apply rule 'xxx' (in /var/lib/icinga2/api/zones/director-global/director/servicesets.conf: 123:1-123:58) for type 'Service' does not match anywhere!
The warnings are shown because e.g. all the windows or network-components checks won’t apply to a linux host.
I digged into the source code and looked up some discussion about this warning and it seems that this warning is intended.
If it would be a debug message I would not care but as it is a warning, I have the feeling that I do something wrong.
So my questions are:
Do I violate some best practises by using many service-sets and apply-rules within the global zone?
Are these warnings normal / ok and can be ignored?
Any help is appreciated.
Many thanks in advance!
Thomas
As far as I understand these are more of a informational log message - I also have all of our service sets and service templates in the director global zone, and they get deployed to all satellites regardless of their purpose.
As far as I understand it, they are informational here.
They are helpful if you misconfigure something and the rule really applies nowhere (lets say a typo in a variable), so, if you see this message on the master instance it might point you to a problem. On a specific agent, it’s just informational.
same here - we have the same service.conf files in all satellite zones. maybe have some kind of argument when checking the config to only show criticals
Hi - I’ve read your initial post & the replies, and have a slightly differing view IF THEY ALSO APPEAR ON THE MASTER. In that case I think you need to go through each of those warnings and check that the apply rules they refer to - often notification rules in our firm’s case, BTW - are cleanly defined, and do not actually “set” something (which you then have checked off in your head as being handled) that no longer can be set. (E.g. a notif. rule for a set of hosts defined by 1 or more host groups, which have over time become empty.)
If your global rules are addressing objects they cannot see, you may have a service (template) definition problem.
Basically, it’s good practise to test every apply rule you set up at least once with a positive case (apply rule finds an applicable object & is triggered). Better: Twice or thrice, so you have better statistical odds of having found a bug, if the apply rule in fact does not function as you expected when setting it up. (Which the warnings guide you towards…)
Final advice from experience: If you have several apply rules addressing the exact same sub-set of objects/contacts/time-zones they apply to, the “last one to be applied will win”!! (Overwriting any others to the same sub-set.)
I.e. using a lot of apply rules is okay, as long as you have good oversight of what they actually - uniquely! - apply to. (One more reason to reduce those warnings.)