Reviving this thread as I’m working on the same thing.
The scenario is to replace a setup where we have multiple sites, each locally managed using Juju in the same way folks might do with Puppet or Salt - the hosts to monitor send their config to the config master, which currently sends that to a Nagios host (and uses NRPE). The local Nagios is entirely standalone, and links to pager for notifications, etc. So far, so good, and I can see how we can easily replace that with Icinga2 and Icingaweb2, and have built a demo for that which looks great.
The thing we do next however, is where we struggle. We connect, from our tiny management box, to all the remote Nagios hosts using mklivestatus and Thruk, so that we can issue commands (downtime etc), and view check status, from all the remote sites at once. The connectivity to remote sites is slow, unreliable, and we rely heavily on the presence of Thruk’s local cache of info to make it usable.
Our remote sites are designed to be independent, and able to be disconnected permanently from our central management at short notice, with minimal effort. We would, therefore, install Icingaweb2 on each remote site, to allow this. Hence the need for IDO on the Satellites.
Having attempted to play a little with a master/satellite/agent setup, with master in our central host, satellite on each site, and agents linked to the satellite, I have a few queries:
- All the docs I’ve seen so far suggest that the content of conf.d is no longer the right place for host and service configs, and we would need to put the host/service configs into the zone dir on the master, to be dropped down to the satellites as appropriate. In our setup, the config files are generated by config management not available to the master, only the satellites. Does this mean we generate configs at each site, then transfer them to the master so it can transfer them back to the satellite? Can I add configs for hosts, services, etc all in a specific satellite, and have the master set to “just go grab all the info from this satellite, and issue commands to it”? Unfortunately we’re monitoring a variety of configurations that are all fairly diverse.
- In my test environment, when I put host/service configs in conf.d on the satellite, and enabled reading that dir, I could only see the hosts defined on the satellite. I guess that’s to be expected, but the opposite of what we want the master for. Am I reading this wrong?
- What’s actually stored in the IDO? We’re faced with tight security requirements about shipping data offsite from the remote sites, so we’d need to ensure that we can quantify what we’re replicating and how we secure that.
What we might be wanting to do could be a lot simpler, and I might be overthinking this. The only real reason we even need a central master is so our team have an easy way to view and silence alerts from many remote sites, that might be something we can overcome another way. I’d prefer to avoid having to log into 30 Icinga web interfaces at once