Working with multiple users

Once you have your monitoring in a state where it is beginning to be useful to others, it is time to deal with the user administration function in Checkmk. If you are only operating the system on your own, working as cmkadmin user is quite sufficient, and you can simply continue reading in the next chapter on notifications.

Assuming, then, that you have colleagues who are expected to work with Checkmk alongside you, why don’t you all simply work as cmkadmin users? Well, this is theoretically possible, but it does create a number of difficulties. If, however, you create one account per person, you will have several advantages:

You can find all the details that go beyond the introduction in this Beginner’s guide in the article on user administration.

We would like to take a closer look at the two points on permissions and responsibilities. Let’s start with permissions — that is, with the question of who is allowed to do what. For this purpose, Checkmk uses the concept of roles. A role is nothing more than a collection of permissions. Each of the permissions allows a specific action. For example, there is a permission for changing the global settings.

Checkmk comes with four predefined roles that you assign to a new user:

You can learn how to customize the predefined roles in the article on user administration.

The second important aspect of user administration is the definition of responsibilities. Who is responsible for the host mysrv024, and who for the service Tablespace FOO on the host ora012? Who should see the host and service in monitoring and possibly be notified if there is a problem?

Responsibilities in Checkmk are not defined via roles, but via contact groups. The word 'contact' is meant in the sense of notification: Who should the monitoring contact if there is a problem?

The basic principle is as follows:

Here is an example of such an assignment of users (left) and hosts (right) to contact groups (center):

As you can see, both a user and a host or service can be a member of several contact groups. Membership of a group has the following effects:

To manage the contact groups, follow this way: Setup > Users > Contact groups. A contact group with the name all and the alias Everything is already predefined. All hosts and services will automatically be assigned to this group, which is intended for simple setups in which there is (so far) no division of tasks, and for which you will initially have the sole responsibility.

With Add group you create a new contact group. Here you need, as usual, the internal ID (Name) and the title (Alias), which it is possible to change later:

In the above example you can see a new contact group, which unsurprisingly should be responsible for the Windows and Linux servers.

Once you have created all of your contact groups, you will need to assign hosts and services on the one hand, and users on the other. You do the latter in the properties for the users themselves — we will come to this in a later chapter.

There are two ways of assigning hosts to contact groups, which you can also choose to use in parallel — via rules or via the properties of the hosts or their folders.

You only need to assign services to contact groups if these are to differ from those of their hosts. However, an important basic principle applies in this regard — once a service has been explicitly assigned to at least one contact group, it no longer inherits any contact groups from its host.

An assignment at the service level allows you to, for example, separate server and application operations. For instance, put the host srvwin123 into the contact group Windows & Linux Servers, but put all of its services beginning with the prefix Oracle into the contact group Oracle Administration, which means that the Windows administrators will not see the Oracle services, and the Oracle administrators, conversely, will not get details of the operating system’s services — which is often a practical separation.

If you do not need this separation, simply limit yourself to the assignments for hosts — and you are done.

The Assignment of services to contact groups rule set is responsible for the assignment at service level. When creating the rule, proceed in the same way as described in the previous chapter for the host assignment. In addition, you specify conditions for the service names.

Enter the user administration with Setup > Users > Users:

Don’t be surprised if, in addition to the cmkadmin entry, there are also two other users automation and agent_registration. These automation users are intended for remote access, e.g. via script or REST API.

You create a new user with the Add user button on the page with this same title:

In the Identity box, enter the internal ID (Username) and a title — here the Full name of the user. The Email address and Pager address fields are optional and are used for notifications via email and SMS respectively.

In the Security box, leave the default setting at Normal user login with password and only assign an initial password. By default, a password for a local user account must be at least 12 characters long. This is defined by Global settings > User management > Password policy for local accounts.

At the bottom at Roles you can assign roles to the user. If you assign more than one role, the user simply receives the maximum permissions from these roles — although this would not make much sense for the four predefined roles.

Under Contact Groups you can now select from those previously-created contact groups. If you select the predefined group Everything, the user will be responsible for everything, as all hosts and services are included in this group.

By the way, the last two boxes on this page — Personal settings and Interface settings — contain exactly the same settings that a user can change in their profile via the User > Edit profile menu. Only guest users (with the Guest user role) cannot change these settings in their profiles.

Continue with the Checkmk notifications