1. Introduction
In a typical distributed monitoring with a centralized Setup, as a rule a user will log in to the central site in order to work with configurations or to access the monitoring data. Users can additionally log in to the remote sites since only they are responsible for the hosts and services monitored beyond that position. The authorization concept in Checkmk which uses roles and contact groups to control the visibility and configurability of hosts and services is quite satisfactory for both of these scenarios. As a general rule users with very restricted authority will receive no direct access to the monitoring server’s command line and thus will only see the data for which they themselves are responsible. If in this process, the possibility that they may become aware of the existence of other hosts and services is not a problem.
With a centralized setup, under the Standard Edition and Cloud Edition Checkmk will therefore distribute all configuration files to all participating sites, since in principle these sites could be located or be required anywhere, as the case may be. Centrally-managed passwords must also be made available for the remote sites since the hosts and services in contact groups can be distributed over multiple sites.
When Checkmk is to be provided as a service to a third party however, specific configuration files are only permitted to be distributed to specified remote sites. This means that sensitive customer data may not be stored on another customer’s server — a simple restriction of its visibility in the web interface is therefore insufficient. In any event it is possible that the local monitoring server is run by the customer themselves, or that the customer otherwise has a direct access to the server’s command line.
In addition it is no longer required that a customer makes configuration changes centrally — after all, the whole point of providing such a service is to save the customer from needing to perform such tasks. The customer also does not need a centralized overview since they only need access to their own data.
With the 
Checkmk Enterprise Managed Services Edition, via the distributed monitoring in their central site, for each customer a provider links only the one or more local sites which belong to that customer.
Individual elements in Setup will then be assigned to these sites.
When distributing configuration data Checkmk will now only send data of a general nature or data that has been approved for the customer’s site.
The service provider can still easily carry out a configuration over the central Setup in their own site.
Likewise a central web interface for all of the provider’s customers is available in which they can work with monitoring data.
This works in exactly the same way as in a normal distributed environment with the only difference being that you must use the Checkmk Enterprise Managed Services Edition on all of the sites involved:
The following elements in Checkmk can be assigned to a customer:
Remote sites
Users
LDAP connections
Rules and rule packs in the Event Console
Centrally-managed passwords
Contact groups
Host and service groups
Global settings for remote sites
Thus only the customer’s own configuration, host and service data is available to the customer over the site assigned to that customer. They need only to log in to their own site to receive their own data. A login to the service provider’s central server is no longer required — and is in fact no longer possible!
Important: The Managed Services option in licensing must be selected if Checkmk is not for your own use, but rather is intended for monitoring another business’s infrastructure.
This also applies even if the extended functionality of the Checkmk Enterprise Managed Services Edition is not being used.
2. Configurations
2.1. Installing customers
Installing one of your customers is performed simply in a single step: in Setup > Users > Customers select the Add Customer button, and assign an explicit ID, as well as the name to be used when displaying it in Checkmk. Once saved, your first customer will have been been installed in Checkmk:
As can be seen the service provider will likewise be treated like a customer and for this reason has already been defined as a Provider. You may not delete this assignment.
2.2. Assigning sites
Once a customer has been created, next link the appropriate Checkmk components to this customer. The central site to which all of the customer’s other sites send their data is also known as the provider site. Currently separation of the data only functions if each customer has their own site assigned to them and this is in turn connected to your provider site. The setup in this case differs at a single point: in the Basic settings, in addition to the ID and the alias, the previously-defined customer is entered:
Thereby, since the provider is also handled like a customer, via the assignments to a site Checkmk always knows which host belongs to which customer.
Note: The customer site’s Global settings can as usual be configured over the site-specific global settings.
2.3. Further assignments
Alongside the site itself — as mentioned in the introduction — you can also assign other elements from the Setup to a customer. In doing so an element will be assigned directly to the customer. Alternatively, you can also make it available to all customers globally. Here is an example for a user:
The assignment is always carried out via the properties of the respective elements using the Customer option. Exceptions to this are the site-specific global settings.
Special features of the Event Console
In the Event Console you can assign individual rules as well as complete rule packs to a customer. In the process be aware that with rule packs the inheritance must always be performed. They thus cannot be — in contrast to folders — overwritten by the individual rules. In this way you can always be confident that every rule will be reliably assigned.
If a rule pack has not been assigned to any customer, its individual rules can be assigned to a customer as applicable.
2.4. Non-customizable components
All components that have not been discussed in the preceding can not be assigned to individual customers. Nevertheless, with a few words we will draw attention to some special features of various components. Failure to follow these instructions may pose a moderate safety risk.
Business Intelligence
BI aggregations cannot be assigned to a specific customer. Therefore all aggregations and their rules will be assigned to all sites. For this reason the naming of rules, packs and aggregations should be as generalized as possible, and accordingly should not contain customer-specific descriptions.
Host tags
Likewise host tags may not contain confidential information since the tags are distributed to all sites.
Notifications
Rules for notifications often contain contact groups and very specific conditions under which the notifications should be triggered and sent. Since these rules are also distributed to all sites, you should especially avoid using explicit host and service names, contact addresses and other sensitive data.
Customization of global users
Note that all customizations of global users will be passed on to all of the customer’s sites. Global users are therefore unsuitable for specialized views, custom graphs or bookmarks since these can contain sensitive, customer-specific data. Utilize the global users for exceptional cases rather than for regular everyday tasks.
2.5. Certificate management
The topics mentioned in the last chapter, such as notifications with contact groups or host tags might only leak information on organizational structures of other customers.
The situation is different with the distribution of CA (Certificate Authority) root certificates: If a CA certificate intended for customer A were distributed to customer B, there would be a risk that a rogue administrator at customer A could carry out a man in the middle attack on the encrypted communication at customer B. For this reason, CA certificates stored with the Trusted certificate authorities for SSL global setting are not synchronized to the remote sites.
The correct way to configure customer-specific CA certificates is to enter them in the site-specific global settings for the customer’s remote sites.
3. Extended GUI
3.1. Dashboard
New on the Main dashboard is the Customers dashlet located to the left of the service problems:
On selecting a customer a view listing all of the customer’s hosts will be opened. This view functions like the All hosts view, with the difference here being that only the specific customer’s elements are shown.
3.2. Sidebar
The Customers snap-in of the sidebar functions in exactly the same way as the similar looking Site status snap-in. Here the status of the individual customer’s sites can be output, and with a click on a status particular customers can be hidden or shown in the display.
In contrast to the Site status snap-in, with this snap-in a single click hides all of a customer’s sites.
3.3. Filtering and building views
Of course you can also use the filters and data sets for your own views in the same way as they are used in the dashlet and the snap-in. On the one hand the Site filter has been extended to modify what is being displayed:
And on the other hand you can build completely new views based on one or all customers. For this purpose select All customers as the data source:
4. Tips for upgrades
4.1. Introduction
When upgrading an existing environment from the Standard Edition to the Managed Services Edition there are a number of particulars to be aware of. If you only want to switch a single site the transition is very easy: perform an update of the site in the usual way, after which all of the important tasks will have been completed. All hosts, users and other settings that were previously configured will be assigned to the Provider customer, so that your monitoring will for the time being function as before. Then in your own good time you can construct an environment for the Managed Services.
If the upgrade is to an existing environment in which remote sites have already been defined for a customer, there are a couple of more points to consider.
4.2. Sequence for updates of individual sites
Following the update all of the functions will be available for defining customers and for assigning sites, users, etc. to them. As already mentioned these will in fact be assigned to the Provider. In an existing distributed monitoring this however also means that all other sites with this data cannot yet use it. The following sequence should therefore be followed to complete a safe update:
First update all remote sites.
Update the central site last.
To be safe, make no changes while the update procedure is processing.
To securely prevent any changes from occurring, these can be disabled for the duration of the update process. This lock is activated in the Setup > General > Read only mode:
By the way, with an update in a distributed monitoring all of the compatible components in Checkmk will be assigned to the Provider.
4.3. Assignment of customers
Following the update the sites can be assigned to the customers. Be aware of possible dependencies that could result from the existing configuration, and assign the correct elements from Checkmk’s other components to the customers as appropriate before activating the assignments to a site.
Important: At least one user must be transferred to a customer’s site. It makes no difference whether it is a global user to be replicated on all sites or if it is a customer-specific user.