Teleport the xymon server to a remote-site
The great Xymon-addon
ssh-tunnel written by Padraig Lennon allows for
managing ssh port-forwardings (aka: ssh tunnels) from the Xymon server in a
pretty flexible way.
The xymon communication with remote sites that are (only) reachable by ssh and cannot themselves contact the Xymon server (remote-datacenter, DMZ, …) then happens through that tunnel.
For that to work the Xymon server port tcp/1984 is forwarded to the client. The client in turn is configured to report to localhost:1984 — sending the data through the ssh-tunnel to the Xymon servers port 1984.
In contrast to using
pulldata on the server and
msgcache on the client (see
msgcache(8)) this has several advantages:
- data is transmitted in encrypted form and not in clear/plaintext
- ssh allows to compress the data (massively reducing the consumed bandwidth)
- no additional open port 1984 of
msgcacheon the clients
- potentially more resource friendly
- no added (well: at least reduced) latency for the client-data to show up
- the Xymon server does not need to become an active player pulling data but can remain passive in the communication
Monitoring many single hosts with this technique may lead to other problems on the Xymon server though: Many ssh processes, consuming a lot of resources (ports, memory, cpu) and a “messy” central monitoring server.
Monitoring a larger remote location, e.g. a complete datacenter, only requires
one ssh-tunnel to be established.
For this to work
have a tunnel to
host.remote.tldopening 1984 on it’s public/private interface
have all clients report to
This requires a bit of extra ssh-cofiguration on the remote server (check
ssh(1) for the
GatewayPorts for more
A follow-up post will describe how to avoid the