1

I'm setting up a distributed Icinga setup in the following manner. We have 6 sites so i'm monitoring 3 on each of 2 nodes plus a central server.

Sites a,b,c are actively monitored by node 1

Sites d,e,f are actively monitored by node 2

nodes 1 & 2 submit passive checks to the central server

The problem i'm hitting is that the central server is intended to be the master server here, as one would expect. For this reason it should understand reachability across the entire network. What I can't work out how to do is link the two nodes' hosts together on the status map and thus in reachability. An example below:

enter image description here

Icinga (the central node) is running on an Ubuntu VM on a vSphere server in site (a). To get to site (d) from the central node, the logical path consists of the vSphere server, a switch, another switch and then a router. This router connects to another router in site (d), and then switches and eventually hosts.

My issue is that I can't set a host on node 2 (in this case, the router in site (d)) to have a parent that doesn't exist on node 2 (its "parent" for reachability should be the router in site (a)).

This was... incredibly difficult to explain. Is there a way around this? I have tried declaring the site (a) router again on node 2 hoping that duplicates would be ignored by the central server but used by the node but to no avail. I'd like my central status map to be able to be viewed logically and not with each site just spawning off the Icinga instance illogically.

1 Answer 1

0

I actually just worked out this was mostly an issue with my own methodology. The solution I tried will work, just not the way I was doing it:

Have router defined in node 1 and central, with correct parent

Have router defined in node 2, with no parent

This way no single Icinga instance sees a duplicate, and the central server now treats it correctly.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .