[dev.icinga.com #10807] Raise a config error for "Checkable" objects in global zones

[icinga-migration]

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

Assignee: mfriedrich
Status: Resolved (closed on 2016-01-14 14:35:03 +00:00)
Target Version: 2.4.2
Last Update: 2016-04-12 06:32:09 +00:00 (in Redmine)

Backport?: Already backported
Include in Changelog: 1

---

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.

Cheers,
Thomas

Attachments

• 10807.conf mfriedrich - 2016-01-14 14:34:19 +00:00

Changesets

2016-01-14 14:34:38 +00:00 by mfriedrich d9fac2b

Raise a config error for "Checkable" objects in global zones

fixes #10807

2016-02-23 08:20:39 +00:00 by mfriedrich f5fda9e

Raise a config error for "Checkable" objects in global zones

fixes #10807

[icinga-migration]

Updated by mfriedrich on 2016-01-14 14:33:23 +00:00

• Status changed from New to Assigned
• Assigned to set to mfriedrich
• Target Version set to 2.5.0

I stumbled over this while preparing a test setup, I've pushed a fix for that.

[icinga-migration]

Updated by mfriedrich on 2016-01-14 14:34:23 +00:00

• File added 10807.conf

[icinga-migration]

Updated by mfriedrich on 2016-01-14 14:35:03 +00:00

• Status changed from Assigned to Resolved
• Done % changed from 0 to 100

Applied in changeset d9fac2b.

[icinga-migration]

Updated by gbeutner on 2016-02-23 09:58:22 +00:00

• Backport? changed from Not yet backported to Already backported

[icinga-migration]

Updated by gbeutner on 2016-02-23 10:24:28 +00:00

• Target Version changed from 2.5.0 to 2.4.2

[icinga-migration]

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)
Or how should I now reconfigure everything in order to make it work?

[icinga-migration]

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.

[icinga-migration]

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:
zones.d/global/www.google.com.conf

object Host "www.google.com" {
  import "generic-host"

  check_command = "dummy"
}

zones.d/node1/http.conf

apply Service "node1-" ... {

import "satellite-service"

zone = "node1"

display_name = "Node1 HTTP Check"
...
}

zones.d/node2/http.conf

apply Service "node2-" ... {

import "satellite-service"

zone = "node2"

display_name = "Node2 HTTP Check"
...
}

And I have in web interface the following:

• Host 'www.google.com'
  -- Service 'Node1 HTTP Check'
  -- Service 'Node2 HTTP Check'

I cannot create two hosts in different zones:

critical/config: Error: Object 'www.google.com' of type 'Host' re-defined: in /etc/icinga2/zones.d/node2/www.google.com.conf: 1:0-1:27; previous definition: in /etc/icinga2/zones.d/node1/www.google.
com.conf: 1:0-1:27
Location: in /etc/icinga2/zones.d/node2/www.google.com.conf: 1:0-1:27
/etc/icinga2/zones.d/node2/www.google.com.conf(1): object Host "www.google.com" {
                                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/etc/icinga2/zones.d/node2/www.google.com.conf(2):   import "generic-host"
/etc/icinga2/zones.d/node2/www.google.com.conf(3): 

Now I can only have something like that:

• Host 'Node1'
  -- Service 'www.google.com HTTP Check'

• Host 'Node2'
  -- Service 'www.google.com HTTP Check'

[icinga-migration]

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.

[icinga-migration]

Updated by akrus on 2016-04-12 06:32:09 +00:00

It works now, thank you!