Zoning: HowTo with Icinga Director?

This forum was archived to /woltlab and is now in read-only mode.
  • German below // Deutsch siehe unten


    we are currently trying to set up an Icinga2 Environment that is supposed to look like this:


    Ubuntu 16.04: Icinga2 with Icingaweb2, Director and Business Process

    3 Satellite-Servers:

    Ubuntu 16.04: Icinga2, bare minimum

    We want the Master-Server to be the only one we have to configure and then send either the configuration (propably the better option) or the Task that says i.e. "ping that IP" over our WAN lines to the satellites, where the satellite does as it is commanded and sends the information gathered back to our Master-Server. The point is to minimize the load on the WAN.

    The question we ask ourselves is: How do we go about to configure that Setup with the least possible amount of Manual config-writing? There really is no guide on how to do that with the director, at least none that we found. If there is i would be glad to be pointed that way.

    If we currently try to set up the Zoning we usually run into one of the Errors described here: Link

    Thanks in Advance

    A slightly frustrated trainee


    wir versuchen momentan erfolglos, eine Icinga2-Umgebung soweit ans Laufen zu kriegen, dass wir uns mit dem Testen von Konfigurationen usw. beschäftigen können. Die Umgebung soll, wenn sie fertig ist mal so aussehen:


    Ubuntu16.04: Icinga2 mit Icingaweb2, Director und Business Process-Erweiterung

    Drei Satelliten-Server:

    Ubuntu 16.04: Möglichst nacktes Icinga2

    Dabei sollen Konfigurationen, Hosts, Benachrichtigungen usw. komplett auf dem Master verwaltet und dann nur die nötigen Konfigurationen an die Satelliten weitergegeben werden, um die WAN-Strecken zu schonen. Die gesammelten Informationen sollten natürlich auch an den Master zurückgehen, um dann zentral ein Dashboard zu pflegen, dass hier bei uns in der IT hängt.

    Die große Frage ist für uns jetzt: Wie richtet man das mit dem Director ein? Wir haben Anleitungen zur händischen Konfiguration mit Node Wizard und Config-File-Geschreibsel gefunden, nur bietet der Director ja eigentlich die Möglichkeit, das Ganze vollständig einzurichten. Bei dem Versuch sind wir allerdings auf diesen Fehler gestoßen - beide Varianten, entweder macht unsere Config nix und die Checks laufen immer noch vom Master oder der Icinga-Service kann nicht mehr gestartet werden. Das Problem ist allerdings, das ich/wir die Antwort schlicht und ergreifend nicht verstehen.

    Kann vielleicht jemand kurz beschreiben wie und in welcher Reihenfolge man vorgehen muss oder auf einen Link verweisen, der es einsteigerfreundlich erklärt?

    Vielen Dank im Voraus

    Ein leicht gefrusteter Azubi

  • did you study https://docs.icinga.com/icinga2/latest/doc/module/icinga2/toc#!/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-zones ? it explains pretty much what you have to do.

    In director you have to also create this.

    I would also suggest, to go to a Icinga2 training course.

    The mentors there can explain that really good

    EDIT: What kind of node-wizard commands did you try?

    I certainly hope not node update-config this function is deprecated

    Linux is dead, long live Linux

    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them

  • Yes, i read most of it (and have tried to following it, as the director didn't work for me). My problem is: I want to do the configuration mostly with the director and would like to configure the zones with the director, too, as the director seems to support that. But i haven't found a single word on how to do that with the director, the linked thread is the only source i found and, quite frankly, i don't understand what's going on there.

    The node wizard commands i've used are the ones described in the documentation under 6.7 and 6.8.1 (Master Setup and Linux Satellite Setup)

  • ah yeah, those commands you need.

    now I understand what you want, and how to do it.

    It is really easy, once you wrap your head around the director.

    1.Create Zones for each of your Satellites and Clients that they serve.

    eg.: Sat1

    2. Create an Endpoint for each zone, this endpoint is your Satellite.

    • Take care to configure a Api user so they can communicate with the master and vice versa.
    • in Cluster Zone you add the Zone you want it in.

    that's basically it.

    Last thing to do, would be to add the hosts to each respective zone.

    That should be it. If you have any more questionsm feel free to ask.

    Linux is dead, long live Linux

    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them

  • So... my starting Point is: Satellite is set up with Icinga2 (API-Feature enabled), Master is set up with Icinga2 (again, API enabled), Web and Director, the Director is ready to roll out changes. My API user is configured how? Is there a way to do it with the director or do i directly have to write it in the config files as described in the documentation? Each satellite and the master needs that API-user config, right?

    Then i configure my zones in the director (i.e. called "Berlin" and "München") and my endpoints (my satellite servers) which are named like "monitoringBER.mydomain.com" and "monitoringMUN.mydomain.com" (FQDN) where each has the appropriate Zone (monitoringMUN has München, monitoringBER has Berlin as a zone)

    Then i have a Setup that works as described above (Master syncs config to the satellite (at least the config that is related to the Zone of the satellite), like Hosts that have Zone="München" to the satellite in München but not those with Zone="Berlin")?

  • you should be able to configure the api users via the director, as long as they are distributed via the global zone. So all your satellites have to know this zone.

    But the rest is exactly like the docu describes it. you should be set.

    You can check the the Check-Source on the hosts to see if it works the correct way.

    Linux is dead, long live Linux

    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them

  • you should be able to configure the api users via the director, as long as they are distributed via the global zone. So all your satellites have to know this zone.

    But the rest is exactly like the docu describes it. you should be set.

    You can check the the Check-Source on the hosts to see if it works the correct way.

    Sorry, here i am again:

    I don't get this to work. Like, at all.

    You wrote in your first post that i should just do what you wrote, which is: "You start with an completely Zone-less Master and Satellite. Make Zones in the director, then make the endpoints for the Zones, roll out the config and be good"

    Well, I don't get any Errors with this, but if i define a new host and assign a ping ip4 check that is to be executed on the satellite, i doesn't do anything at all, Host stays in Status "Pending"

    The last post says "Do as the Documentation (the Icinga2-Documentation I assume) tells you and you will be fine". If i follow the Setup as described there (node wizard Setup as master and Client and so on) i don't Encounter any Errors either, but i don't have any zones config in the director, even if i execute the kickstart again.

    Could someone explain to me in a way that someone who doesn't understand anything at all about Icinga2, the Director etc. could get his System from no zoneconfig at all to what i described above? Because right now I'm very confused as to what I'm to do, to what guide/documentation/whatever to refer and basically what is not needed because of the director and what i still have to do by Hand.

    Many thanks in advance for your Patience

  • Hey,

    I ran into a similar problem some weeks ago. So, if I got you right, you want to start with a mostly 'blank' Icinga2 setup and deploy configs like zones via Director. I can only recommend you to NOT do this at all, since you run into the problem you've already linked. Furthermore, whatever host you wish to deploy config to (e.g. zone objects) needs to know the zone where the config is coming from. Otherwise, Icinga2 will discard the config; just have a look at the debug log or 'icinga2 daemon --log-level debug'.

    In short, try this:

    • enable API feature
      • set 'accept_config' and 'accept_commands' inside the API user object to 'true'
    • create the zones without Director on the master
    • run the Director kickstart wizard to import these zones and their respective endpoints

    Again, I want to emphasize that (to my knowledge) there is no possibility to deploy config to a host, which doesn't know about the zone (e.g. master, satellite) where the config is coming from. Correct me if I'm wrong, I'm still learning how to Icinga2 ;)

    On the other hand, Kevin describes that zone deployment without knowledge of the parent zones seems to be possible:


  • OK, this was definitely helpful. Thanks for that, now i have something new to try.

    My Problem here is always the missing host - WERE do i have to do all this? Here i think i should do all of this on both master and satellite, (except the kickstart of course) right?

    But i think Kevins solution could also work - enabling the API and configuring the same API user SHOULD enable the Master to connect to the Satellite via the API and send it configuration objects, shouldn't it? If not, I'm kind of at a loss to what the API would achieve...

  • Hi,

    AFAIK the very minimum information your hosts need is the 'director-global' zone. From there on, you should be able to deploy zones and endpoints that were created by the Director GUI.

    You're right, the configuration concerning the zones should be available on master and satellites -> https://docs.icinga.com/icinga…er/distributed-monitoring 6.10.3 where it says:

    'You can safely deploy this configuration onto all master and satellite zone members. You should keep in mind to control the endpoint connection direction using the host attribute.'

    What do you mean by a missing host? Just create a host object for the host you want to monitor: Icingaweb2 -> Director -> Hosts -> +Add

    Director seems to automagically create the respective host's endpoint objects when you create the host object itself.

    If you just meant the 'host = <address>' inside an endpoint object: An endpoint containing this attribute will be actively connected to by any host this object got synced to.

    'If you specify the host attribute in the icinga2-master1.localdomain and icinga2-master2.localdomain endpoint objects, the client will actively try to connect to the master node. Since we've specified the client endpoint's attribute on the master node already, we don't want the clients to connect to the master nodes. Choose one connection direction.'

    Since the top-down method will be the future way to go (bottom-up method won't be supported beyond Icinga v2.6), you should make sure that the endpoints will always be connected to by their parent zone (only).

    I hope this was somehow helpful to you. Otherwise, just let me know if I didn't understand your problem correctly.

  • Hi,

    okay, then I think i understand what my problem was: I have never configured the director-global Zone on my satellites. I suppose if i do that i will be able to deploy the rest of my config, as you have said.

    What i meant with the missing host was that in all the explanations for me as a newb the information on which host I should do what the person told me was missing - i.e. "create you API-User like so" ... do i need to configure my API-User only on my master, or on my satellite, or on both?

    And yes, all of this has helped me, and if it is only because i now understand better how Icinga works. But it is nice that there is always someone responding pretty quickly, within 24h usually. And that the people here are friendly, I've known communities that were just toxic.

  • Sorry for the late response. Start by setting up your master host:

    • provide Endpoint information
    1. object Endpoint "icinga2-master1.localdomain" {
    2. host = ""
    3. }
    • provide Zone information
    1. object Zone "master" {
    2. endpoints = [ "icinga2-master1.localdomain" ]
    3. }
    • don't forget to also add the director-global zone
    1. object Zone "director-global" {
    2. global = true
    3. }
    • enable API feature
    Code: /etc/icinga2/features-available/api.conf
    1. object ApiListener "api" {
    2. cert_path = "/etc/icinga2/pki/<name>.crt"
    3. key_path = "/etc/icinga2/pki/<name>.key"
    4. ca_path = "/etc/icinga2/pki/<name>.crt"
    5. accept_config = true
    6. accept_commands = false // <- you might want to change this if you're going to execute checks
    7. }
    • create an API user object
    1. object ApiUser "director" {
    2. password = "<password>"
    3. permissions = [
    4. "*",
    5. ]
    6. }
    • run the Director kickstart wizard

    Please note that some of these steps are also done by using the 'icinga2 node wizard' command. Depending on your setup, you'll also find further information here: https://docs.icinga.com/icinga…er/distributed-monitoring