We use cookies to ensure that we give you the best experience on our website.  Visit our Privacy Policy to learn more. If you continue to use this site, we will assume that you are okay with it.

Your choices regarding cookies on this site.
Your preferences have been updated.
In order for the changes to take effect completely please clear your browser cookies and cache. Then reload the page.

The Managed Services Edition

Checkmk Manual
Last updated: August 24 2018

Search in the manual

1. Introduction

In a regular distributed monitoring with a centralised WATO, as a rule a user will log in to the central Master Instance in order to work with configurations or to access the monitoring data. Users can additionally log in to the Slave-Instances since only they are responsible for the hosts and services monitored beyond that position. The authorisation 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 centralised WATO, in the Free Edition and Standard Edition Checkmk will therefore distribute all configuration files to all participating instances since in principle they could be located or be required anywhere, as the case may be. Centrally-managed passwords must also be made available for the Slave-Instances as the hosts and services in contact groups can be distributed over multiple instances.

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 Slave-Instances. This means that sensitive customer data may not be stored on another customers 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 – the point of providing such a service is to save the customer from needing to perform such work. The customer also does not need a centralised overview since they only need access to their own data.

With the  Checkmk Enterprise Managed Services Edition, via the distributed monitoring in their central instance, for each customer a provider links only the one or more local instances which belong to that customer. Individual elements in WATO will then be assigned to these instances. When distributing configuration data Checkmk will now only send data of a general nature or data that has been approved for the instance to a customer's instance. The service provider can still easily carry out a configuration over the central WATO in their own instance. 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, that you must use the  Checkmk Enterprise Managed Services Edition on all involved instances:

The following elements in Checkmk can be assigned to a customer:

  • Slave-instances
  • Users
  • LDAP connections
  • Rules and rule packets in the Event Console
  • Centrally-managed passwords
  • Contact groups
  • Host and service groups
  • Global settings for slave-instances

Thus only the customer's own configuration, host and service data is available to the customer over the instance assigned to that customer. They need only to log in to their own instance to receive their own data. A log in to the service provider's central server is no longer required – and also no longer possible!

Important: The Managed Services option in Licensing must be selected if the 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 only a single step: in WATO ➳ Customers select the New 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 has 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 instances

After a customer has been created, next link the appropriate Checkmk components to this customer. The master instance to which all of the customer's other instances send their data is also known as the Provider-Instance. Currently separation of the data only functions if each customer has their own instance assigned to them and this is in turn connected to your Provider-Instance. 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 an instance Checkmk always knows which host belongs to which customer.

Note: The customer instance's Global Settings can as usual be configured over the site specific global settings.

2.3. Further assignments

Alongside the instance itself – as mentioned in the introduction – you can also assign other elements from the WATO 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 instance-specific global settings.

Special features of the Event Console

In the Event Console you can assign individual rules as well as complete rule packets to a customer. In the process be aware that with rule packets the inheritance must always be performed. They thus cannot be – in contrast to host directories – overwritten by the individual rules. In this way you can always be confident that every rule will be reliably assigned.

If a rule packet has not been assigned to any customer, the individual rules can be assigned to a customer as applicable.

2.4. Non-customisable components

All components that have not been discussed in the preceeding can not be assigned to individual customers. Nevertheless, with a few words we will draw attention to some special features of various components.

Business Intelligence

BI-Aggregations cannot be assigned to a specific cusomer. Therefore all aggregations and their rules will be assigned to all instances. For this reason the naming of rules, packets and aggregations should be as generalised as possible, and accordingly should not contain customer-specific descriptions.

In a future version of Checkmk it may become possible to also assign BI-Aggregations to an individual customer. Should this become the situation then the documentation will be updated appropriately.

Host tags

Likewise Host Tags may not contain confidential information since the tags are distributed to all instances.


Rules for alarms often contain contact groups and very specific conditions under which the alarms should be triggered and sent. Since these rules are also distributed to all instances, you should especially avoid using explicit host and service names, contact addresses and other sensitive data.

Customisation of global users

Note that all customisations of global users will be passed on to all of the customer's instances. Global users are therefore unsuitable for specialised views, custom graphs or bookmarks since these can contain sensitive, customer-specific data. Utilise the global users for exceptional cases rather than for regular everyday tasks.

3. Extended views

3.1. Dashboard

New on the Dashboard Main Overview is the Customers column in which links to service problems are located:

On selecting a customer a view listing all of the customer's hosts is 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. Snapin

The new Customers Snapin functions in exactly the same way as the similar looking Site Status Snapin. Here the status of an individual customer's instances 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 Snapin, with this Snapin a single click hides all of a customer's instances.

3.3. Constructing your own views

Of course you can also use the new filters and data sets for your own views in the same way as they are used in the Snapin and the Dashboard.

On the one hand the Site filter has been extended to edit a view:

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

When upgrading an existing environment from the Free Edition or 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 instance the transition is very easy: simply perform a update of the instance in the usual way, after which all of the important tasks will have been completed. All hosts, users and other settings that have been performed previously 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 a Managed-Services-Environment.

If the upgrade is to an existing environment in which already deleted instances have been defined for a customer, there are a couple of more details to consider:

Sequence for updates of individual instances

Following the update all of the functions are available for defining customers and for assigning instances, 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 instances with this data can not yet use it. Therefore there is the following sequence for a safe update:

  • First update all Slave-Instances.
  • Update the Master-Instances last.
  • To be safe make no changes while the update procedure is processing.

To securely prevent any changes from occurring, these can be disabled in WATO for the duration of the update process. This lock is activated in the WATO ➳ Global Settings with the button:

By the way, with an update in a distributed monitoring all of the compatible components in Checkmk will be assigned to the Provider.

Assignment of customers

Following the update the instances 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 an instance.

Important: At least one user must be transferred to a customer's instance. It makes no difference whether it is a global user to be replicated on all instances or if it is a customer-specific user.