I’m using Icinga 2.13.6 in a distributed environment (currently Master, two Satellites, and four Agents per Satellite). The Master is in a data centre (public IP address) but the Satellites and Agents are behind two different NAT routers, therefore the Agents can connect to their local Satellite on the local network, and both Agents and Satellites can route out to the Master, but the Master cannot connect in to the Satellites.
I’m setting up a “Network Connectivity” service check, which verifies connectivity from the Agents to the Satellites and from the Satellites to the Master. I’m using a ping4 Service Check for this, which runs on every Agent and Satellite, with the parameter “ping_address” set to the Satellite’s resolvable name in the case of an Agent, and the Master’s resolvable name in the case of a Satellite.
So far, so good, however for scalability I would like the Service Check definition to be able to work out the parent’s resolvable name automatically. The parent is a property of a Zone, and I can get the name of the Zone in which a machine lives using "get_object(“Zone”,zone), but I’m stuck on trying to get the resolvable name of the Host in that Zone.
So far, I’ve tried:
get_object(“Zone”,zone).address
get_host(get_object(“Zone”,zone)).address
get_host(string(get_object(“Zone”,zone))).address
All of these end up with ‘null’ as the ping_address when I do “icinga2 object list --name MyNewService”.
If I just use get_object(“Zone”,zone) then the Service Check in IcingaWeb2 tells me that my ping_address is an Object of type ‘Zone’, which is fair enough.
Anyone got any suggestions on how to find the address of the Host in the Parent Zone?
produces the hostname I actually want, however it doesn’t work - the Service
Check output simply says:
check_ping: Invalid hostname/address -
The Custom Variables section of the Service Check screen in IcingaWeb2 shows
the correct DNS resolvable name for ping_address.
If instead I set the ping address to “host.address” (ie: the address of this
machine itself, but the same object type as the parent’s address above) then
everything works. In both cases the result is a DNS-resolvable host name for
the machine performing the Service Check.
So, are you suggesting that I should be defining a host= value for all of my
endpoints?
Distributed Monitoring - Icinga 2 says in
several places “Choose one connection direction” and my understanding is that
this is achieved by ensuring that between the child and the parent, only one
of those Endpoints contains a Host definition.
If I use “icinga2 object list --type Endpoint”, nearly all entries come back
with host=“”
Okay, so that tells me the Endpoints of the Zone of this Node - that comes
back as an array, the single element of which is the name of this Node. I
don’t really see how that helps?
get_object(“Zone”,zone).parent
tells me the parent of the Zone of this Node, which is closer to what I want.
get_object(“Zone”,zone).parent.endpoints
Fails with the error “Invalid field access (for value of type ‘String’):
‘endpoints’” which means to me that get_object(“Zone”,zone is being returned
as a String?
So, if you say I should be working with Endpoints, how do I get the Endpoints
of the parent Zone of the Zone in which this Node is?
It shows exactly what I want in the output of “icinga2 object list --name
MyNewService”, and it also shows exactly the right hostname for “ping_address”
in the IcingaWeb2 Custom Variables section.
But… the service check fails with:
check_ping: Invalid hostname/address -
which I’ve seen before, when both the object description and the ping_address
look completely correct to me.
Maybe I need to re-phrase my question, now that I have at least two different
ways of getting the hostname I want, but neither of them work with the ping
check:
“What type of object do I need to specify for ping_address in order for it to
accept what reads to me as the completely correct hostname, and how would I
convert what reads as the right name into such an object?”
have you checked the data type of those three?
I could imagine, that host.address resolves “magically” to something directly usable.
maybe somthing like this comes into play here
have you checked the data type of those three?
I could imagine, that host.address resolves "magically" to something
directly usable. maybe somthing like this comes into play here
a = "test"
typeof(a) == String
true
typeof(a) == "String"
false
typeof(a).name == "String"
true
No; I’ve not tried that. Where would I run such a test from? Can I use for
example icingacli to get into a command line where I can get the output of
this sort of thing?
So, I’ve worked out that “icinga2 console” doesn’t actually let you interact
with anything to do with the machine’s Icinga2 configuration
You need to find out what password got assigned and stored in
/etc/icinga2/conf.d/api-users.conf and then use this, along with --connect, in
order to get a console which knows about the configuration on the machine.
Now I get:
Icinga 2 (version: r2.13.6-1)
Type $help to view available commands.
<1> => var x=get_host(“Agent3”)
null
<2> => x.address
“Agent3.domain.local”
Much more encouraging.
Therefore, coming back to log1c’s question “have you checked the data type of
those three?”
