Three level configuration not working

Hi all! I’m configuring a three level icinga2 configuration = master → satellite → client.
I followed the instructions in the “Three Levels with Master, Satellites, and Clients”. I added the client host and it appears in Icinga Web but the hostalive status is pending and the “Check Source” are empty. This is my config files:
Master zones.conf:

object Endpoint “master1.localdomain” {
}

object Endpoint “satellite.localdomain” {
host = “192.168.1.42”
}

object Zone “master” {
endpoints = [ “master1.localdomain” ]
}

object Zone “satellite.localdomain” {
endpoints = [ “satellite.localdomain” ]
parent = “master”
}

object Zone “global-templates” {
global = true
}

Satellite zones.conf

object Endpoint “master.localdomain” {
}

object Zone “master” {
endpoints = [ “master.localdomain” ]
}

object Endpoint “satellite.localdomain” {
}

object Zone “satellite.localdomain” {
endpoints = [ “satellite.localdomain” ]
parent = “master”
}

object Zone “global-templates” {
global = true
}

object Zone “director-global” {
global = true
}

Client zones.conf:

object Endpoint “client.localdomain” {
}
object Endpoint “satellite.localdomain” {
}
object Zone “satellite.localdomain” {
endpoints = [ “satellite.localdomain” ]
}
object Zone “client.localdomain” {
endpoints = [“client.localdomain”]
parent = “satellite.localdomain”
}

Then, in master /etc/icinga2/zones.d/satellite.localdomain dir I create the file client.localdomain.conf:

object Endpoint “client.localdomain” {
host = “192.168.1.44”
}
object Zone “client.localdomain” {
endpoints = [“client.localdomain”]
parent = “satellite.localdomain”
}

object Host “client.localdomain” {
check_command = “hostalive”
address = “192.168.1.44”
vars.client_endpoint = name
}

What I’m missing in the configuration?
image
image

Thanks you!

Hi,

did you restart the master after adding the configuration? Is the satellite connected to the master zone (hint: add health checks)?

Cheers,
Michael

Thanks you @dnsmichi, after some tests now it runs ok. But now I see another problem. My configurations is:

/etc/icinga2/zones.d/master/HOSTS/hosts.conf
/etc/icinga2/zones.d/master/SERIVCES/services.conf
/etc/icinga2/zones.d/icinga_satelite/HOSTS/hosts.conf
/etc/icinga2/zones.d/icinga_satelite/SERIVCES/services.conf

I want to configure services in each zone, for example:

apply Service for (http_vhost => config in host.vars.http_vhosts) {
import “generic-service”

check_command = “http”

vars += config
}

In order to monitor the Icinga web on Master zone and on Satellite zone, I configure this service object in both services.conf inside each SERVICES zone folder. When I run icinga2 daemon -C, it returns me the error:

Error: An object with type ‘Service’ and name ‘icinga_satellite!http’ already exists (in /etc/icinga2/zones.d/master/SERVICES/services.conf: 1:0-1:64), new declaration: in /etc/icinga2/zones.d/icinga_satelite/SERVICES/services.conf: 29:1-29:65

Another think I see. If I configure the next service inside the /etc/icinga2/zones.d/icinga_satelite/SERVICES/services.conf:

apply Service “load” {
import “generic-service”

check_command = “load”

/* Used by the ScheduledDowntime apply rule in downtimes.conf. */
vars.backup_downtime = “02:00-03:00”

assign where host.name == NodeName
}

The new service “load” is created for icinga_satelite node, but for master node too…

Thanks you!

Better put generic apply rules into a global zone, and have them evaluated on each endpoint then. The master generates objects for both zones, master and satellite. The satellite below receives that via config sync and only generated objects for the satellite zone.

Cheers,
Michael

1 Like

Thanks you @dnsmichi, I will put better the command.conf file in global-zone but not services or apply rules because I need to create same services but with different attributes for each customer.
Regards.

Hi,

then I’d advise to create a set of apply rules with different assign where expressions, each for e.g. a custom variable identifying a specific customer.

apply Service "foo" {
  check_command = "bar"
  vars.bar_warn = 50

  assign where host.vars.customer == "c1"
}

apply Service "foo" {
  check_command = "bar"
  vars.bar_warn = 100

  assign where host.vars.customer == "c2"
}

Things like the check_command attribute can be hidden in a generic service template too.

Cheers,
Michael

2 Likes

I’ve been looking for an answer to my question and found your reply in this thread.

If I understand it correctly the services in the master zones will also apply for the satellite zones.
But in my case placing a service in the satellite zone executes this also against the hosts that are in the master zone?!

/etc/icinga2/zones.d/satelliteA/services.conf

apply Service “ping4” {
check_command = “ping4”
assign where host.zone == “satelliteA” && host.address
}

Without the host.zone == “satelliteA” it will also target the hosts on the master.

Hope you can make me smarter :wink: