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 Check_MK 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
When Check_MK 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.
The following elements in Check_MK can be assigned to a customer:
- 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
Check_MK is not for your own use, but rather is intended for monitoring another
This also applies even if the extended functionality of the
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 Check_MK. Once saved your first customer has been installed in Check_MK.
2.2. Assigning instances
After a customer has been created, next link the appropriate Check_MK 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 Check_MK 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.
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 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 Check_MK 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 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
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 instances can be output, and with a click on a status particular customers can be hidden or shown in the display.
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
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 Check_MK 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 Check_MK'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.