Icinga 2.8 CentOS Documentation help

  • Agreed and Point taken. I know there are many things that take priority with project being open source. But just thought of being another soul to vote up on that request to help many like me.


    Anyways, I am doing a write up in what I have done so far and will put that out as blog soon and will share the link here. It would be kind of you to validate if time permits?


    Yes, the hosts.vars.disk had 2 entries and removing that helped. An additional question on this, the default hosts.conf created by the installation has the below:


    /* Define disks and attributes for service apply rules in `services.conf`. */

    vars.disks["disk"] = {

    /* No parameters. */

    }

    vars.disks["disk /"] = {

    disk_partitions = "/"

    }


    However with the above 2 entries being there, the dashboard does not show 2 entries for the default master and shows up only "disk"? Is there a reason for this or is it being controlled by other conf files in master to limit visibility only to /Disk?

  • Since you are using a distributed setup which partially copied things to global-templates, I'd look into the host object definitions. Ideally by running "icinga2 object list --type Host" to see how they're finally compiled. Maybe you've got some wrong host configuration, or including directories you don't need (like "conf.d").

  • Hi dnsmichi ,


    Just re-read your post, you have mentioned I am running distributed setup. Does this mean I am not running on top down config sync mode (as I am not running the global-templates) and the setup is just a Master with multiple clients?


    Thanks for that command, I was able to see duplicate entries which I have now removed and the dashboard looks fine. I am now in the process of sending the same to Grafana via Graphite and see how it works.

  • A "distributed setup" involves to have more than one Icinga 2 instance running, and connected in a parent-child hierarchy to each other. One part of such a distributed environment includes the configuration sync feature, one part of the "top down" terminology. Another one is the "command endpoint execution bridge", which just fires commands on child endpoint.


    You can combine both, as can be seen in the scenario for the "three level cluster with master, satellites and clients" in the documentation. Reading this thread agian, you are already doing so. The master syncs the objects to the satellite, which in turn fires checks against clients.


    Draw an image for your setup and put it at hand when you are adding a new host object for example. Where should it be executed/synced to. Sometimes it also helps to create flow diagrams for a better understanding (Visio, Confluence Gliffy, etc.).


    Keep the distributed monitoring and troubleshooting docs bookmarked and opened while going further. Many best practices and problems others already dug into are collected there.