A very basic low level understanding question

This forum was archived to /woltlab and is now in read-only mode. Please register a new account on our new community platform.

You can create a thread on the new site and link to an archived thread. This archive is available as knowledge base, safe and secured.

More details here.
  • Hi all,

    I am new to Icinga2 and am LOVING it. I am planning on setting up multiple servers to monitor multiple devices with multiple services.

    And I've got the basics down: I can install Icinga2, Icinga2 web (wrote installers which runs through the install from a basic CentOS image). In my current lab setup I have some hosts (W7, 2012R2, Ubuntu, CentOS) monitored which I 'tied' into the master using the 'icinga2 client' package installed on the clients. When setting up these new hosts you run it on the client and create a certificate on the master and then the two talk and I see the hosts and services come up

    I noticed that these hosts are setup under repository.d/ and the services look like this:

    object Service "ping4" {
    import "satellite-service"
    check_command = "dummy"
    host_name = "ubuntu1"
    zone = "ubuntu1"

    And have a check_command of 'cluster-zone' assigned to them.

    I guess what I am trying to get my head around is whether the installation of the client piece is needed (and necessary?). E.g I can create a host and just do:

    • check_command='hostalive' or
    • check_command='ping4' on it.

    Perhaps even ssh and mysql? But what about load, disk,procs,users? Do I need the client software for that?

    I guess what I am asking is whether the client software piece is really there to making it easy to setup a new host, but that you could do without it and all set it up manually?


  • At first glance those cli tools help you with SSL certificate generation ("CSR autosigning") as well as simple configuration (endpoints and zone relation ship). The default "node update-config" cli command will use the "bottom up" way of setting up those clients. Using this method you're up to 1) install plugins on the clients 2) locally configure the checks on the client 3) import them on the master.

    A common different approach is to follow the top-down approach - you'll still need endpoint/zone configuration hierachy, you'll also need 1) install plugins on the remote end (if not already provided by Windows plugins/Nsclient or Linux - monitoring-plugins). The way the checks are configured is different - command execution bridge will invoke the check by the parent's master node scheduler and force client execution via command_endpoint definition. Or you'll just sync all checkable objects using the cluster config sync. The latter involves understanding that all nodes in an Icinga 2 distributed systems are just icinga2 installations with a trust relationship validated against the Zone parent/child model as well as Endpoint names validated against the SSL certificate common names. It doesn't matter whether you call it a satellite or a client, technically they are the same. Logically they fit better in your brain :-)

  • Thank you very much! That clarifies things. I prefer the top down method myself. I've learned a lot and hope to share some of my findings on this great forum!