Types of connections for distributed monitoring

Hello,

I currently have a master check_mk and two slaves check_MK connected by IPSec. Soon we will increase the number of slaves but we feel the connection by IPSec as a dinosaur. What do you usually use? VPN for all your connections with slaves?

Thanks

up to 1.5.x: ssh tunnel (cobbled together using autossh and systemd service units)
1.6.x: built-in livestatus encryption :slight_smile:

3 Likes

Like @martin.schwarz with actual 1.6 i use the included stunnel connection.

2 Likes

Thank you very much, @martin.schwarz @andreas-doehler, I am going to look for information about livestatus.

Sorry for hijacking, but otherwise I’d have posted the exact same question. Is there any way to use encrypted livestatus without connecting to the remote site via VPN?

(Follow-up question: It seems that Livestatus needs to have access to the UI—is that correct? Or is it possible to not expose the UI to the WWW then?)

1 Like

I’m not sure if I understand the question correctly. In a distributed setup, the master site uses livestatus to connect to the slave site. The default destination port on the slave is 6557/tcp, but can be configured via omd config on the slave. So if the master can connect to the slave directly, then you don’t need a VPN.

Since Version 1.6, this livestatus connection can optionally be encrypted. With new sites, encryption is enabled by default while for existing sites you have to enable it manually.

Yes, besides the livestatus connection, the master also connects to your slave on http(s) port. If this port can’t be reached directly, then you could use some method like VPN, stunnel, ssh tunnel, even reverse ssh tunnel, … to allow that connection.

And of course, you can use firewall, packet filter, ACLs, tcp wrapper, … any method you like … to allow https access to the slave only from the master, not from “the WWW” :wink:

As always, it depends on the network setup and the security requirements. For example, see this discussion for hints on establishing the connection in reverse (from slave to master).

2 Likes

So, basically: The http(s) connection—and thus, the Web UI—is also needed for distributed monitoring to work. Otherwise I’d have to ‘push’ the data from the remote site.
But sure, I wouldn’t need to publish https to “the WWW”, sorry for being unclear.

Thank you very much!

If you only want to see the actual data and don’t want to push config then livestatus connection would be sufficient.
This is for a distributed monitoring without central configuration ok.
There is then only the problem that you also see no graphs on the central system. (this is the case if RAW edition is used)

1 Like

Thank you! :slight_smile:

Short follow-up: Why is there a difference between CRE and CEE regarding the graphs on the central system? Will this possibly change with 1.7 when the graphing system in CRE will be replaced by the one used in CEE?

Could be - but this you need to ask the guys in Munich :slight_smile:
One thing is that with CEE you can query graphing data also over livestatus. CRE needs every time the generated graphs from PNP4Nagios. And then this image transported over HTTP/S to your central system.