Reusing templates and service names for satellites

Icinga 2
1

I have one master and one satellite, both are at version r2.10.4-1. I just got them talking but now I’m having an understanding problem.

First, to explain our objective: the satellite basically came about because our master server does not have much capacity and does other things, as well. So, it’s not the case that we have network delineated zones rather we want the satellite to run certain service checks while the master runs other service checks.

Here’s where I need help understanding: it seems the objects defined by the master need to be unique yet objects defined in zones.d may depend on objects not in zones.d. For example, let’s say I have a service check that I want to run on the satellite:

apply Service "ping4" {
  import "generic-service"
  check_command = "ping4"
  assign where host.address
}

Once I add that to my zones.d structure then I get this error:

[2020-02-14 07:30:45 -0800] critical/config: Error: An object with type 'Service' and name 'satellitehost.org!ping4' already exists (in /etc/icinga2/zones.d/satelliteZone/services.conf: 12:1-12:21), new declaration: in /etc/icinga2/conf.d/services.conf: 26:1-26:21
Location: in /etc/icinga2/conf.d/services.conf: 26:1-26:21
/etc/icinga2/conf.d/services.conf(24):  * defined.
/etc/icinga2/conf.d/services.conf(25):  */
/etc/icinga2/conf.d/services.conf(26): apply Service "ping4" {
                                       ^^^^^^^^^^^^^^^^^^^^^
/etc/icinga2/conf.d/services.conf(27):   import "generic-service"

This makes sense since now the satellite has a ping4 Service and it knows itself as a Host so it ends up spawning a duplicate check.

My question is: what’s the normal way to approach the satellite configuration to avoid this kind of duplication? I also have templates that define, for example, a linux host or a windows host. Some services will be dependent on these templates. Is the approach to create new templates that are only applicable for the hosts and checks that will be ran on the satellite? In other words, how should the objects be kept unique between satellite and master?

Thanks for any ideas or document references!

Andy

2

Hi,

general advise is to disable the inclusion of conf.d in the icinga2.conf when using a distributed environment, the docs reflect that since a few versions. Instead, manage everything in zones.d/<zonename> and also global zones e.g. for apply rules.

https://icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/#global-zone-for-config-sync

Cheers,
Michael

3

Ah! I kept seeing that in the documentation but I wasn’t adding 2+2. Now it makes sense, thank you! Will work on that.

Andy

4

I assume it’s just a typo in the global commands documentation that there is a global-templates zone or a global-commands zone but not both and they’re not different things? The document refers to both. Will try them out.