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:
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…
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.
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.
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.
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.