Monitoring a non reachable host

Icinga 2
1

Hi all, consider this scenario:
a master and a client host.
The client host is behind a firewall that we can’t manage so it can’t expose port 5665 but it’s able to open outgoing connections.

Which configuration do you suggest to monitor the client host?

2

Just configure the client host as client which connects to the master and does not accept connections itself.

1 Like
3

Fine, it works.

On client /etc/icinga2/zones.conf

object Endpoint "master.domain.com" {
        host = "192.168.56.101"
        port = "5665"
}

On master /etc/icinga2/zones.d/master/clinet1.domain.com.conf

object Endpoint "client1.domain.com" {
    // no host declaration
}

Just to clarify some concepts: in this case the client opens the tcp connection but it’s still the master that schedule the checks, is that right?
In other words, can I force a check from master even if the connection has been initiated by the client?

Thank you.

4

That depends on the configuration mode you are using. Please be aware top down config sync is not supported for Windows clients.

Yes

1 Like
5

Very good answer, just to add - the client will reconnect every 10 seconds (with 2.10+), if the connection has been dropped. For the higher layers with sending an execute command cluster message, this doesn’t matter which side initiated the connection and started the TLS handshake/read/write.

Cheers,
Michael

6

Thank you Michael, this is true in both configuration modes (Top Down Command Endpoint and Top Down config sync), right?

Connection direction (I’m speaking about tcp) shall not be confused with the configuration mode.
I tested this scenario to make that clear to my self.
My configuration is Top Down Command Endpoint and it works even if the client is blocking any incoming connection.

The main thing that change between the two different configuration modes is “who” triggers the checks: master scheduler in the first case, satellite/client in the second case.

Please, correct me if I’m wrong.

PS: I don’t whish to go further about Top Down config sync in this post, I’ll open another one later on).

7

@sirio81, exactly, the TCP connection direction is independent from the configuration mode. I.e. the unit which performs check scheduling is independent from the TCP connection direction.

1 Like
8

BTW, service checks are working with this configuration but the hostalive check will fail because it can’t reach the host by icmp.
Documentation suggest to use dummy as check command.
This way the host is always up.

Is there a way to check if the connection is up as method to check the host state?

9

See my reply in this topic: Windows Agent Monitoring