In this article, the screenshots and the GUI navigation described have not yet been updated to Checkmk version 2.0.0. However, nothing fundamental has changed in the described functions themselves and most of the functions can be found quickly with the Monitor or Setup menu search of the Checkmk 2.0.0 user interface. We will update this article as soon as possible.
In a regular distributed monitoring with a centralised WATO, 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 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 sites 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 remote sites as 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 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 site, for each customer a provider links only the one or more local sites which belong to that customer. Individual elements in WATO 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 site to a customer’s site. The service provider can still easily carry out a configuration over the central WATO 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, that you must use the Checkmk Enterprise Managed Services Edition on all involved sites:
The following elements in Checkmk can be assigned to a customer:
Rules and rule packets in the Event Console
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 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.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 sites
After 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 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 site-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.
BI-Aggregations cannot be assigned to a specific cusomer. Therefore all aggregations and their rules will be assigned to all sites. 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.
Likewise Host Tags may not contain confidential information since the tags are distributed to all sites.
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 sites, 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 sites. 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
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.
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 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 Snapin, with this Snapin a single click hides all of a customer’s sites.
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 site the transition is very easy: simply perform a 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 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 sites have been defined for a customer, there are a couple of more details to consider:
4.2. Sequence for updates of individual sites
Following the update all of the functions are 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 can not yet use it. Therefore there is the following sequence for 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 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.
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.