Addition of hosts to master

  • Hi there,


    I have just set up my master node and now want to add hosts such they would be monitored by the master using the hostalive check.


    I have found that if I create a zones.d/master/ folder and add a hosts.conf to this then this appears to work. I don't know if there is a simpler way to implement this where I want endpoints to be checked by the master?

    A couple of other things I don't understand. For the top down config sync approach is it possible to have some checks of a host run by the master and some checks run on the host/client itself? I guess I don't know how this would be achieved since it would seem that duplicate hostnames in separate zones gives a malformed configuration?


    Finally, once hosts are defined then besides the hostalive check, other checks would be service checks that are specific to a host or group of hosts?


    Many thanks

  • I don't know if there is a simpler way to implement this where I want endpoints to be checked by the master

    That is the way you should go.

    You benefit from config sync and would have everything already in place once you add subordinated zones.


    is it possible to have some checks of a host run by the master and some checks run on the host/client itself?

    check the command_endpoint statement.

    Finally, once hosts are defined then besides the hostalive check, other checks would be service checks that are specific to a host or group of hosts?



    Do not confuse endpoint objects with host objects.

    Endpoints run checks against hosts or the hosts services.

    Even if both objects may (or may not) be located at the same physical/virtual machine, you either tell by using the zone attribute or by setting command_endpoint at which endpoint the check finally runs.


    Two examples:


    Endpoint "master" runs 4 different check_http processes against 4 (non-local) webservers.

    The master still has these webservers defined in its master zone.


    Endpoint "WindowsServer" runs a check_load process against the (local) machine the endpoint is running on.

    It can not run that check remotely as it would not get the current cpu load then.

    The post was edited 3 times, last by sru ().

  • Thanks for replying so quickly - it is much appreciated.


    OK I think I understand better now.


    So in the first instance I have a master endpoint and zone, I add hosts to this through the zones.d/master/hosts.conf file. The master endpoint runs checks on its constituent hosts and, once I have them configured, services too.


    To benefit from config sync I thought I had to have a global-templates zone set which currently I do not in my masters zones.conf file. I merely have a master zone and endpoint defined.


    Regarding the top down command endpoint configuration I wasn't sure whether it was possible to run both top down command sync and command endpoint. Is this defined on a per endpoint basis, or even, on a per check command basis?


    Again many thanks for your reply.

  • First Paragraph: correct.


    Global temlpates: 

    Do it right from the start so that you have a setup that scales easily once you introduce satellites and Agents.

    Your setup currently works because the objects in question currently live in .../conf.d, from where they can not replicate.

    Create a directory .../zones.d/global-templates and move everything from .../conf.d to here that is not specific to an individual host or service.


    Examples:

    • notifications
    • check_commands
    • templates
    • time_periods
    • apply rules that create services or notifications (goal: equip every host with a basic set of services / notifications)
    • hostgroups, service groups

    Do Not Move:

    • Objects that should - perhaps for security reasons - only be known by the master, i.e: api_users.conf
    • zones.conf: These can not be replicated and need to be created at every endpoint by hand.


    I wasn't sure whether it was possible to run both top down command sync and command endpoint

    That is complicated indeed - short answer: you might set command_endpoint in a host or service object.


    A few configs and what they do:


    A Host Object is located in .../zones.d/master. A command_endpoint is not given.

    • That host gets it's zone attribute set to "master". However, in the Zone "master", there are two endpoints (HA-setup).
    • It is not defined which endpoint executes the check, the endpoints agree on that by their own.

    Same as the above, but a command_endpoint is given as "master_1".

    • This check will always be executed by endpoint "master_1". Examples would be checks that target individual NIC's at a given host.

    A Host Object has been created via the API at the master, and the zone attribute has been set to "satellites".

    • That host gets it's zone attribute set to "satellites". Every endpoint in zone satellites and every endpoint in "master" will know that object.

    A Host Object has been created via the API at endpoint "master_1", and the zone attribute was *not* given or

    A Host Object has been created in conf.d at endpoint "master_1", and the zone attribute was *not* given.

    • The zone attribute is not set and thus the object will not be replicated: Endpoint "master_1" is the only endpoint that knows that object.

    Conflicting settings: A Host is created in zones.d/master, but its zone attribute is given as "satellites" and command_endpoint is given as "client0815".

    • I can not tell how that works then.
    • And i can not tell if such a scenario is bulletproof between version upgrades.
    • But i can tell that this is used to run checks against objects in other zones, sometimes.
    • As i do not understand that myself, i do not suggest that.
  • sru that's great thanks!!

    I applied what you suggested which all works once I also declare the global zone in zones.conf. Interestingly the only files I could not move into the global-templates were the api-users.conf (for security reasons as you mention) and the hosts.conf which when moved caused an error with the icinga2 daemon stating that the master host could not be put into the global zone.

    Next I want to add a DNS service to be monitored by the master endpoint. I plan to use the "apply" directive and set this in zones.d/master/services.conf. I can see there is a DNS "plugin" for this https://www.icinga.com/docs/ic…nga-template-library/#dns and I guess I have this as something like:

    apply Service "dns" { import "generic-service" check_command = "dns" assign where host.name == NodeName }

    or would I achieve a service check running from the master endpoint via some other configuration?

    The post was edited 1 time, last by tweeks ().