Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #10807] Raise a config error for "Checkable" objects in global zones #3760
This issue has been migrated from Redmine: https://dev.icinga.com/issues/10807
Created by tgelf on 2015-12-09 15:13:46 +00:00
Checkable objects (Host, Service) in a global zone make no sense in a distributed environment. While they could perfectly work in single-node instances, Icinga2 seems to completely ignore them - no checks are scheduled. To ease troubleshooting I'd therefore suggest to raise a config error at startup time in case someone defined a Host or a Service in a global zone.
2016-01-14 14:34:38 +00:00 by mfriedrich d9fac2b
2016-02-23 08:20:39 +00:00 by mfriedrich f5fda9e
Updated by akrus on 2016-02-25 10:34:59 +00:00
Well, I'm not sure if I have everything configured correctly, but this change broke all our configuration.
What we have now - global has various hostnames (e.g. www.google.com) which is only used as a root category for all the checks - actual check definitions are in zones.d//.conf (e.g. zones.d/node1/http.conf). I cannot add a host definition into each node configuration - this breaks master node, I cannot add it to master node configuration also as this breaks all the nodes.
Is it possible to revert this change for Hosts and keep it only for Services? (and this actually makes sense)
Updated by mfriedrich on 2016-02-25 10:42:02 +00:00
Checkable objects (that is host and service objects) must not be put into a global zone. This results in indeterministic behaviour with multiple satellites being in the same zone, and each node is then executing the check, sending back multiple check results to the master node. This causes problems in your state (change) history, notifications and further, sla reporting. Host and service objects are therefore required to be put into specific zones. If you are putting apply rules into a global zone, this is no problem - they are evaluated on the node and will inherit the zone attribute from the linked host name then.
I'd suggest to fix your configuration. It has been wrong for the time being but Icinga 2 did not let you know until now.
Updated by akrus on 2016-02-25 11:03:27 +00:00
Well, actually it worked fine for a long time :)
The problem is that I need to have one host (www.google.com) with checks from various locations (using apply rules), here's how it's done now:
And I have in web interface the following:
I cannot create two hosts in different zones:
Now I can only have something like that:
Updated by mfriedrich on 2016-04-11 14:16:46 +00:00
Ok I see. Though Icinga 2 considers all Checkable objects being checked by their respective zone. For example, the satellite in zone node1 must be aware of the fact that it should not run the check for this host. Given you example executing a dummy check would always generate two check results - one from node1 and one from node2. The master node will receive 2 check results then. You will not recognize them as they are always the same, but in the end it is wrong. That's how the fix works. The previous behaviour "worked" but was never supported that way.
A possible workaround would be to set a specific zone for this host. E.g. leaving it inside the global zone, but specifying the zone attribute as "master", similar to what you already do with your apply rules. That way the satellites will know about the zone attribute and won't trigger a local check, only the master zone will do.