Extend option for hosts which instance should monitor them

Feedback
I don’t know if more people have the same problem on the forum, but I’m lacking the option for “Monitor on Site”.
I’m referring to “Specifying to the hosts and folders which instance should monitor them”.

Problem
In example if you have multiple site (DMZ, Intern, Customer etc) then you can create multiple site. For every ‘area’ a slave-site, where based on folder the host is monitored on a site.

Idea
Can we not have rules for this, so that you don’t need to have separated administration on witch Site the host need to be monitored. In a time where you buy ‘a service’ and your (the user) dont care on witch Site the host in monitored on. But for the admin it does, due performance/custom things/network rule set.

I don’t know if I understood you 100% right, but in a distributed setup you can choose the site which should monitor the host by editing the host and selecting the checkbox to choose from a dropdown menu:

1 Like

Your completely correct.

For some background we got two teams, one managing the platform/datacenter and other team manage everything for customer applications. So in the eye of the application team they don’t care if the machine is running in DC1 or DC3, they want to monitor customer host/applications.

The platform/datacenter care more because they have to allocate resource, make network changes, security change and for example limit cross-datacenter communication.

So when application-team add more host, they add the host to the folder (with ansbile/API/etc) customerA or customerB. Then the platform/datacenter need to run recurring automation script to say:
Machine1-customerA;DC1;site1-intern
Machine2-customerA;DC1;site1-dmz
Machine1-customerB;DC2;site2-intern
Machine2-customerB;DC2;site2-dmz
If they use other name or administration is not up to date. There are unnecessary error’s.
Automation like https://github.com/wrossmann/add-to-check_mk or https://github.com/tribe29/ansible-checkmk

It would really help if we can make rule in CheckMK to say: CustomerA (regulair expression) run in DC1 site1-intern and CustomerA-DMZ (regulair expression) run in DC1 site1-DMZ and so on. So that no matter what host are added. With will run on the correct site. Not forgetting the production-env/testing-env/develement-env etc.

Maybe you can get a hold of your problem by using the inheritance feature of checkmk folder? For every folder you create in WATO you can set properties which will be applied to all hosts inside it. For example at my former employer I used to create the following structure and apply settings to those folders:

Main Directory (/)
|_ Internal
|_ Customers
    |_ Customer A (monitored at site customer_a)
       |_ Network Devices
       |_ Virtual Machines
       |_ ...
    |_ Customer B (monitored at site customer_b)
       |_ Servers
       |_ Remoteboards
       |_ ....
    |_ Customer C (bigger one, don't set the site (yet))
      |_ Site 1 (monitored at customer_c_site_1)
        |_ Servers
      |_ Site 2 (...)
        |_ Servers
    |_ ...

Thus, you only have to set the directory when using automation which you could eg. name after some internal CustomerIds or other codenames which all teams understand altogether…

Another advantage of this is that when you create rulesets for eg. customer B and you apply the rules to the folder of customer B, you only need to restart the site of customer B and not all sites at the same time. There are checkmk users which needed even more separation. That’s when the CME was introduced.

The problem is that the property “monitored on site” is a host tag.
You can also not assign host tags with rules.

If you manage the host creating with the WATO API then you can make the decision at creation time with your rules. Is there a problem against this way?