Icinga2/IcingaWeb2 - config sync

This forum was archived to /woltlab and is now in read-only mode.
  • Hello All,

    I'm a newbie when it comes to Icinga (never used Nagios) so please excuse my lack of experience.

    I'd like to use Icinga to monitor various local networks and in the very near future, some networks that are off-site, connected via l2l vpn.

    Ideally, I'd like to have the clients send their check data to the master (I believe it's referred to as "Bottom up") as various firewall rules disallow the master access to the clients. Additionally, I'd like to centralize the configuration check on the master so as a client connects, it pulls down whatever configurations we deem necessary (for a start, they will all be the same for each machine).

    I'm a little confused in how to achieve this (hopefully it's possible) and after reading the documentation, I'm a bit more confused. Mainly, I'm not sure if I'm looking at a 'cluster-config sync' scenario or a local sync scenario.

    At the moment, I've successfully installed Icinga2/IcingaWeb2 and I've connected a few clients. Things appear to be working as expected and notifications even work!

    But, my problem is that after I connect a client to the master, I get checks like 'http'/'apt' and I don't want those. I'm currently deleting the apt/http.conf files out of /etc/icinga2/repository.d/hosts/hostname (on the master) but I don't think that's the right way and in terms of automation, it's a few more steps than I'd like.

    Can anybody recommend how I might achieve this?

    Thank you for your time in advance.



  • The connection part (client to master, or vice versa) is independent from the cluster messages themselves. Those can be for example

    • config sync from the master to the client
    • check result messages from the client to the master
    • commands sent via icingaweb2 or api, forwarded to the client (e.g. force check execution)
    • ...

    Once a connection is established, the nodes in that cluster (that can be the master and a client) will exchange those messages. You should keep in mind that all nodes require the Endpoint (for connection information) and Zones (for trust relationship).

    If you prefer to sync the client configuration files from the master, you'll need to put them into /etc/icinga2/zones.d/<client-zonename>/ and Icinga 2 handles the rest with syncing them accordingly.
    One thing which is also cool is to have a global zone for templates, check commands, time periods, etc.

    The documentation is not perfect, but we're gonna work on that in the next months.

  • My apologies for the late reply on this one.

    Thank you for the explanation and information. That makes sense and it looks like I'll be doing some form of sync in order to achieve what I need.

    Thanks again.