Am 2017-02-06 13:05, schrieb Joosten, Markus:
Dear Markus,
thanks for the heads up, I really appreciate it.
I've just tried to implement my approach, and it turns out I was
almost correct ;)
It is indeed possible to abuse check_dummy to "mirror" hosts and
services from a child zone to the parent zone (because the master
knows about them), but not the other way round.
I went down another road, but inspired by your post. I hope this is not
too much meddling with the internals of I2, but so far it works within
my setup. The solution was to manually set the zone on the service and
be very careful where the service is getting deployed (otherwise the
other zones have a config error). It now looks like this:
apply Service "backup status" {
import "generic-service"
check_command = "backup"
command_endpoint = "backup-server"
zone = "master"
assign where host.vars.backup && ZoneName == "master.example.com"
}
If the Icinga Masters think this is bad advice, because it blows
something for one or the other reason, please say so.
Best regards,
Stephan (who very much likes the flexibility of this thing)
On 2017-02-03 22:01, Joosten, Markus wrote:
Hi Stephan,
I don't think this is possible (yet).
There might be a workaround I just thought of (totally untested, not
sure this will work):
- you have a "backup" service attached to your backup server in your
central zone
- create a dummy service "backup" attached to the switch in your
satellite zone (using check_dummy plugin)
- copy the state and output from the original "backup" service to the
dummy one (vars.dummy_state, vars.dummy_text) using
get_service(host_name, service_name)
- if this works, you can also hide the original backup service from
icingaweb2 and disable any notifications
Though I'm not sure if you can access objects in the parent zone from
an endpoint in a satellite zone.
I'll give this a shot myself on monday :)
Regards,
Markus
On 2017-02-03 21:46, Stephan Tesch wrote:
Hi guys,
I have a problem: I've got a distributed setup with a couple of zones
like emea, apac, nafta, ... which have a parent called master. The
monitored devices with the zones work just fine, mostly using snmp.
Now,
there's a few central services that I'd like to connect to my
monitored
devices. Eg. I have a switch in zone emea called switch-1 that I take
a
backup of. Now I'd like to check (as a service to) switch-1 if that
backup was successful. The backup server is central, thus attached
only
once within the master zone as an I2 client. The service definition
might look like this:
apply Service "backup status" {
import "generic-service"
check_command = "backup"
command_endpoint = "backup-server"
assign where host.vars.backup
}
The error that I get looks more or less like this:
critical/config: Error: Validation failed for object 'switch-1!backup
status' of type 'Service'; Attribute 'command_endpoint': Command
endpoint must be in zone 'emea' or in a direct child zone thereof.
The problem that I see: I could move the backup server to zone emea,
but
all other devices in the other zones won't be able to get that
service.
Any idea how to solve this?
(If it helps, I'm running on 2.6.0)
Thanks,
Stephan
_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
