1. Introduction
When setting up a monitoring, certainly the most important task is the administration of the systems to be monitored — the hosts. It’s not just about registering the correct master data (e.g., host name, IP address) — settings for the monitoring (e.g., notifications, thresholds, etc.) also need to be attended to.
Checkmk has been developed from its beginning for environments with a large number of hosts. In order for the configuration to be manageable for the user, Checkmk pursues a different approach to configuration than with other systems that originated from the Nagios ecosystem. The most important principles are:
a folder hierarchy in which the hosts are stored
Host tags, and based on these, a rule-based configuration
Automatic discovery of the services to be monitored
1.1. Folders and their hierarchies
Everyone who works with computers knows the principles of data sets and folders. Checkmk uses a similar principle for administering hosts, which in effect take on the role of data sets. Insofar as folders themselves can be in folders, the result is a ‘tree structure’. There are three widely-used criteria for building the host-tree:
Location (e.g. Munich versus Shanghai)
Host type (e.g. Switch versus Loadbalancer)
Organisation structure (e.g. a Database group versus a Networker)
Naturally you can also mix these criteria in a tree with, for example, subdivision by location in the first level, and by host type in the second.
If you love simplicity you should pack the actual hosts only in the tree’s ‘leaves’ (although Checkmk also allows hosts in intermediate folders). The following example shows a simple tree structured by host type: The hosts A, B and C are in the folder ‘Servers‘ and D, E and F in 'Network' :
1.2. Attribute inheritance
If you build the tree cleverly you can use it to pass on attributes in a systematic way. This is especially useful with attributes that are the same for large groups of hosts, e.g., the SNMP community, or host tags, with which you define whether the host should be monitored via a Checkmk agent or per SNMP.
The following example shows the passing-on of the 'Criticality' attribute (with the prod and test values), likewise the 'Checkmk agent' attribute
with the tcp and no-agent values. The tcp feature is automatically set if the Checkmk agent and/or an API integration is selected, while no-agent is the option of choice if monitoring is to be done via SNMP.
Attributes defined lower in the tree always have precedence.
Values defined directly at the host therefore overwrite everything that comes from the folders.
In the above example, the host A receives the prod and tcp attributes, host D receives prod and no-agent, and host F — because of the explicit attribute test at the host — receives the test and no-agent values.
A big advantage of this procedure over the widely-used 'copy & paste' approach of data base oriented configuration systems is that you can predefine attributes for hosts that will be registered in the future. This makes your (or your colleagues’) work easier — simply throw the new host into the correct folder and all settings will automatically be correct!
1.3. Permissions
A further function of the folder is the assignment of permissions for creating and editing hosts. Here Checkmk differentiates between rights in the configuration environment and the contact allocation in the monitoring environment. It’s not always the case that the persons authorised to create a host are the same people who are responsible for monitoring the hosts in the production operation. Permissions are explained in the article on users, roles and permissions.
You create new folders via 
Add folder.
The options are the same as when creating new hosts, which we will explain in detail below.
2. Creating hosts in Setup
You can manage folders and hosts via Setup > Hosts > Hosts:
The Add host action button, the 
clone button and the 
edit host button take you to the page with the host’s attributes. This consists of several sections (or boxes), of which we will introduce the most important here.
2.1. The host name
Most important is the host name. Everywhere in Checkmk the Hostname field serves to explicitly identify the host. The host name is entered in internal references, used as a component of the URL, serves as a part of file names and directories, and appears in log files, etc. There is in fact a function for changing host names at a later date — this is however a time-consuming and complex procedure that is best avoided. You should therefore select host names carefully. The host’s name does not necessarily need to match the host’s DNS name, but it makes many things easier.
2.2. Alias and IP address
You can give the host an alternative, descriptive name under Alias which will be displayed in many locations in the GUI as well as in reports. If no alias is defined, the host’s name will be used as an alias.
You have four options for configuring the IP address:
| Option | Procedure | DNS happens |
|---|---|---|
1. | You enter no IP address. The host name must be resolvable via DNS. | with activate changes |
2. | You enter an IP address – in the standard dot notation. | never |
3. | Instead of an IP address you can alternatively enter a DNS-resolvable host name. | during check execution |
4. | Via rule set Hosts with dynamic DNS lookup during monitoring you determine hosts for a dynamic DNS. The result is similar to 3., except that the Hostname field is used for DNS query. | during check execution |
With the first option, Checkmk uses cached data in order to minimise repeated DNS requests during the activation of the changes — which is very important for accelerating the activation procedure. Furthermore, the cache ensures that a modified configuration can still be activated if the DNS stops working.
The catch is that Checkmk doesn’t automatically notice the change to an address in DNS.
For this reason, in the Properties of host page there is the menu item Hosts > Update DNS cache which deletes the entire DNS cache and forces a new resolution the next time you activate the changes.
This file is found under ~/var/check_mk/ipaddresses.cache in your site, by the way.
Deleting this file has the same effect as running Update DNS cache.
Checkmk incidentally also supports monitoring via IPv6 — also in dual stack.
2.3. Monitoring agents and custom attributes
The final important setting can be performed in the Monitoring agents and Custom attributes submenus.
The latter custom attributes shown here can be extended as desired, and can be used via rules to configure all host and service parameters very efficiently. Criticality and Networking Segment are only examples.
It is more important to specify an entry under Monitoring agents, since this determines how the host transfers its data to the monitoring.
As monitoring agents you can set:
Checkmk agent / API integrations | The host should be monitored via the Checkmk agent (which must be installed of course). Select this setting also in the case of special agents,, such as e.g., VMware ESXi monitoring. |
SNMP | The host should be monitored via SNMP. This selection allows the SNMP credentials field to appear below SNMP, with which you can define the SNMP community. Since this is generally the same for many hosts, it is in fact recommended that it be defined in a folder. If nothing is specified |
Piggyback | Piggyback data from other hosts will be used. |
No API integrations, no Checkmk agent | Such hosts are without agents and are monitored only with active checks. Rules for these are found under Setup > Hosts > HTTP, TCP, Email, …. If you don’t define at least one active check then Checkmk creates a PING service automatically. You can find this setting as an option in Checkmk agent / API integrations. |
2.4. Labels
A host can have any number of labels. Labels are similar to host tags, but unlike those, they do not have to be predefined — you can assign them freely.
You assign a label to the host by first selecting Labels. Then click in the Add some Label field, enter the label definition in the form key:value and finish it with [Enter]. Use the crosses to remove labels.
If you don’t really need a value for a label, but just want to know whether a certain label is attached to the host or not, you can simply enter yes as the value (vm:yes).
If you follow this scheme consistently, you will find it easier to define conditions for such labels later.
By the way, labels can also be automatically attached to hosts: on the one hand by external connectors that automatically create hosts (e.g. automatically detected hosts in Cloud environments), and on the other hand by rules.
2.5. Saving and continuing
After creating or cloning a host, and after setting the properties, the next logical step is Save & go to service configuration. With this you enter the automatic service discovery, a subject we would like to address in the next chapter.
On the other hand, Save & go to connection tests takes you into the connection test – with which you can test whether the settings being used actually produce any data from the agent. Details on the connection test can be found in the article on monitoring agents.
3. Configuring services
After creating a host the next step is the configuration of its services to be monitored. All details for the automatic discovery and configuration of the services can be found in its own article. We will describe only the most important here.
There are various ways of accessing the list of a host’s configured services in the Setup:
via the host list:
Select Setup > Hosts > Hosts. In the host list, click on
.via the properties of a host:
Select Setup > Hosts > Hosts. In the host list, click the host. On the Properties of hosts page, select from the menu Hosts > Save & go to service configuration. If instead you select Hosts > Service configuration from the menu, you will also get to the service list — but without saving the host’s properties.
You can also access this page in the monitoring from a host’s service list: Select Monitor > All hosts. In the host list, click on the host. On the Services of Host page, for the Check_MK Discovery service, in the 
action menu select Edit services.
Whichever method you choose, the result should look something like this:
The most important actions are provided in the action bar, others can be found in the Actions menu. Some notes on the possible actions:
The Fix all button is usually the best action for a new host or for an existing host where services have been found that are not currently being monitored: Undecided services (currently not monitored). Fix all adds the missing services, removes services that have vanished and takes over host labels that have been found.
The Full service scan button enables fresh, complete data to be obtained from a target device. In order to ensure quick rendering of pages in your browser, Checkmk often works with cached data that is being logged during the regular monitoring. With SNMP devices the button starts an active search for new check plug-ins and can possibly find further services.
Remove all and find new is the same as a clearing and fresh detection of all services. This is useful for services which can recall the state detected by a discovery (e.g., the current state of switch ports).
You can display checkboxes in the list with Display > Show checkboxes and then select or deselect individual services.
This is only a temporary solution, however, as the service discovery always highlights missing services. Permanently ignoring requires clicking
, which permanently disables the service.
With 
you can bring a disabled service back into monitoring.As always after every change an activation of changes is necessary in order for them to take effect.
All further information can be found in the article on service configuration.
4. Bulk actions
You may occasionally wish to perform tasks such as deleting, moving, editing or a service discovery for a whole series of hosts simultaneously. Checkmk provides so-called 'bulk actions' for this purpose.
You can find these actions on the page of an open folder in the Hosts menu in the On selected hosts section:
The actions always apply to hosts that are located directly in a displayed folder — and which have been selected by you. The checkboxes in the first column of the host list serve this purpose. If you click on the cross in the column’s title, all hosts are selected — and deselected by clicking it again.
You can restrict the selection of affected hosts in the list with checkboxes. Some of the actions will thus only be executed on the selected hosts.
Here are a few tips for the available actions:
Delete hosts - Deletes the hosts — after confirming the request.
Edit attributes - Changes one or more attributes of the hosts. The attribute is thereby entered explicitly in the hosts.
Caution: There is a difference between the host inheriting an attribute from a folder, and the attribute being set explicitly. Why? In the latter case a change to the attribute in the folder would have no effect, as the values defined directly in the host always have priority. For this reason, there is also the following action:
Remove explicit attribute settings - With this you can delete explicit attributes from the selected hosts and reinstate inheritance. The same result can be achieved by opening every host individually and deselecting the attributes via the checkboxes.
It is generally a good idea to use as few explicit attributes as possible. When everything is inherited correctly via the folders, errors are reduced and the easy integration of new hosts is made possible.
Discover services - Simultaneous discovery on multiple hosts.
Detect network parent hosts - Creating parents using a scan.
Move to other folder - Move the hosts to another folder. After selecting this entry, the existing folders are offered as possible destinations.
5. Searching hosts in the Setup
Checkmk provides the convenient option of searching in the monitoring environment (with the Monitor menu) and in the configuration environment (with the Setup menu). The results can be different because the hosts in the monitoring environment do not necessarily have to be the same as in the configuration environment: For example, if you have created a host in Setup without activating this change, it will not (yet) exist in the monitoring.
There is another option for host searching in the configuration environment, which has the advantage that you can search for hosts according to diverse criteria, and the hosts found will be listed on a results page from which you can start the bulk actions, as introduced in the previous chapter.
You can also find this search on the page of an open folder in the Display > Search hosts menu. The search always processes from the current folder recursively through all subfolders. To search globally, simply use the search from the Main directory.
In the Hostname field an infix search is valid — the entered text must only be a part of the host name. Furthermore, you can restrict the search using other attributes. All search terms are connected with AND. The example in the above image illustrates a search for all hosts with my in their name that also have the Test system attribute.
With Submit you start the search. The results page behaves almost like a normal folder. This means that you can use the bulk actions here, which are provided in the Hosts menu in the On selected hosts section, e.g. to move all hosts found to a specific folder.
If you don’t like the results, you can adjust and refine the search on the results page with Refine search.
6. Importing hosts from CSV data
If you wish to import a large number of hosts from a previous monitoring system or from an Excel table, you can make the task easier by importing with the help of CSV data. Checkmk is very flexible when reading such CSV data. In the simplest case you just need a file in which every line contains a host name that can be resolved via DNS:
myserver01
myserver02During an import it is also possible to take on additional attributes. If the CSV data has attribute names in the first line, Checkmk can even assign these automatically. To this end Checkmk attempts to use a tolerant rather than an exact syntax. In the following data Checkmk can automatically correlate all columns correctly:
hostname;ip address;alias;agent;snmp_ds
lnx17.example.com;192.168.178.48;Webserver;cmk-agent;
lnx18.exmpl.com;192.168.178.55;Backupserver;cmk-agent;
switch47-11;;Switch47;no-agent;snmp-v2The procedure is as follows:
Select or create a folder into which the import is to take place.
Switch to this folder and in the Hosts menu select 
Import hosts via CSV file.
On the page that follows, either upload the file or select Content of CSV File and copy the file content into the field that appears below the list. You can immediately have an automatic service discovery carried out on the newly imported hosts. This is done with the Perform automatic service discovery option:
By clicking 
Upload you get the next page:
If the automatic recognition of a column doesn’t work you can manually select the attribute to be assigned.
For the host tags (Tag), the CSV data must contain the tag’s internal ID (here e.g. cmk-agent and not the title Checkmk agent / API integrations visible in the GUI).
The internal IDs can be found under Setup > Hosts > Tags, and the IDs of the builtin tags in the article on host tags.
You start the import by clicking on Import.
If you have earlier selected Perform automatic service discovery, the new hosts will land on the Bulk discovery page.
Once the service discovery has been completed, all that then needs to be done is the usual activation of the changes, after which all of the new hosts will be in the monitoring.
7. Creating parents
You have already learned what parents are and how they work. But how does one actually create parents? The answer is typically Checkmk: there are a number of different procedures — manually, per scan, or via the REST API.
7.1. Creating parents manually
A parent for a single host can be specified as follows: Select Setup > Hosts > Hosts and click on the desired host to display its properties. In the Basic settings box, enter the parent using its name or IP address. Once a parent has been specified, a further entry field for an additional parent will be opened:
Important: Only enter direct parent hosts.
Similarly, parents can also be defined in a folder’s attributes, and be inherited by the hosts they contain. How this is achieved has already been seen in the chapter on inheritance of attributes.
7.2. Creating parents using a scan
If the monitoring is a new installation, which from the very beginning has been planned with an orderly folder and parents structure, there should be no real problems with the inheriting of parents via folders. However, parents can also be set up automatically using the Parent scan.
Via the IP protocol the scan searches for the last gateway before a host on the OSI model’s (layer 3) network layer using traceroute.
If such a gateway is found and its address belongs to one of your monitored hosts, this host will then be set as a parent.
If traceroute does not receive any information from the hops before the targeted host, the most recent successful hop will be used.
If however no gateway with a monitored IP address is found, as standard Checkmk generates an artificial 'ping-only-host' by default in the Parent folder which will be simultaneously generated.
This default setting can also produce undesirable results. For example, take a typical, small network with the address range 192.168.178.0/24. If a host with an address in a different address space — which cannot be pinged — is added to the monitoring, the scan will attempt to access it via the router, and there it will find the node of the network provider. Thus, for example, it can happen that a telecom server in the WAN network is set as a parent for this host. This option can of course be deactivated.
If you wish to scan a folder with new hosts for parents, proceed as follows:
First open the desired folder and select Hosts > Detect network parent hosts in the menu to open the scan configuration. By the way, you can also scan a selection of hosts instead of an entire folder by selecting them in the first column of the list.
To fully scan in all hosts in all subfolders, independently of any possible manually-installed parents, choose the Include all subfolders and Scan all hosts options. In the Performance section you can limit the scan duration – which otherwise can take a very long time if there is a large number of hosts.
In Creation of gateway hosts specify if, how, and under which alias new parent hosts should be created. Deactivate this function if it is to be restricted to parents on monitored hosts.
Now click Start at the bottom of the page. The scan’s output can be followed live.
Afterwards you will see the configured parents and, if applicable, a new folder Parents in the Main directory (if you specified this before the scan).
This completes the scan.
After a scan has been performed and the changes have been activated, the parent-child relationships are visualised as a topology map, which you can call up via Monitor > Overview > Network Topology.
Tip: If the result of a scan appears to be implausible at any point, invoking traceroute manually can sometimes help with analysing the individual hops.
7.3. Creating parents with the REST API
For more experienced users there is the additional facility for configuring parents by using the REST API.
8. Renaming hosts
Renaming hosts — on the face of it a simple matter — turns out to be an astoundingly-complex operation on closer inspection. The reason for this is that Checkmk uses the host’s name as the unique key for the host – and this is used in numerous locations. These include file names, log data, configuration rules, BI aggregations, reports, dashboards and much more. The host name also appears in URLs.
Checkmk has a specific action in the Setup for cleanly-renaming a host in all locations. You can rename a single host (in the properties of the host in the menu Hosts > Rename) or a large number of hosts in a folder simultaneously: in the menu Hosts > Rename multiple Hosts.
Important: Since changes in many different places for many hosts can also go wrong once in a while, you should make sure that you have an up-to-date backup of your site before you start any big renaming action.
By utilising intelligent operations, the Bulk renaming of hosts allows systematic name matching to be made:
In the Hostname matching field, first optionally specify a regular expression that matches the beginning of the names of the hosts you want to rename — in this example, all hosts whose names begin with lnx.
Then insert one or more operations to be applied in sequential order to the host names.
In the above example, first Drop Domain Suffix truncates everything from the first . onwards from all host names and then Add Suffix adds the -linuxserver extension.
There are other operations available, some of which are self-explanatory, or for which you can get more information by showing the context-sensitive help (Help > Show inline help).
Once started with Bulk rename, and confirmation of the obligatory 'Are you sure…?' query …
… the renaming process can take a while. During the renaming the monitoring will be completely stopped! This is necessary to keep everything in a consistent state. On completion you will receive on overview listing of which, and where renames have taken place:
9. Host groups
Host groups are a part of the monitoring basics in Checkmk. They enable a second layer of groups of hosts across the folder structure. For example: your locations are displayed based on the folders. Now you would like to be able to view all Linux, Windows and certain application servers together — and create a host group for each of these server types.
In contrast to the situation in host tags, host groups do not appear as selection criteria in rules by default: host groups serve the views, while host tags serve the configuration.
You can find host groups under Setup > Hosts > Host groups.
9.1. Creating a host group
A new host group is created via the Add group action button.
The creation is a trivial action, and is limited to specifying a unique name which cannot be changed later, and likewise an alias:
9.2. Including hosts in a host group
To add hosts to a host group, try the Assignment of hosts to host groups rule set, which can be found in Setup > Hosts > Host monitoring rules. Create a new rule in the desired folder.
First, in the Assignment of hosts to host groups box select the host group to which hosts are to be assigned — in the example below the "My Linux servers" group:
Finally, in the Conditions box, take care of the filter or the filters to restrict the group — because filters can of course also be combined. You can filter hosts by folders, host tags and host labels, or specify particular hosts. Should you wish to add hosts with two tags from the same tag group to the host group, you will need to create two separate rules. In general, the group assignments are cumulative. Hosts can be in multiple groups and groups can be filled with multiple rules.
In the following example, we use the host label cmk/os_family:linux automatically assigned by Checkmk to add the Linux servers to the host group:
As usual, you will still need to activate the changes afterwards.
9.3. Checking host groups
You can conveniently check the result of your assignments in the monitoring. Under Monitor > Overview > Host groups the existing host groups are listed:
Clicking on the name of a host group will take you to the full overview of the hosts in this group.
9.4. Using host groups
You can use host groups in several places: to create table views and NagVis maps and as filters in rules for notifications and alert handlers.
Views
When creating table views (via Customize > Visualization > Views), only the specification of the Datasource that uses host groups is important, e.g. Hostgroups.
In the Monitor menu you will find ready-made views, for example Host groups, which we have already shown in the previous chapter.
NagVis maps
You can access NagVis maps with the NagVis maps snapin of the sidebar. In a NagVis map, for example, as a result you get the summary for a host group via a hover menu over a single icon:
Notifications and alert handlers
In the rule sets for notifications and alert handlers, the host groups are provided as filters in the Conditions submenu:
10. The folder structure in the monitoring
The tree structure derived from the folders is also visible in a monitoring environment.
10.1. Filter bar
Firstly, there is the WATO Folder filter in the filter bar for table views that you can use to restrict the current view to only those hosts below a particular folder:
10.2. Tree of folders
Secondly, in the sidebar, the Tree of folders snapin offers the same selection option as the Monitor menu, but can additionally restrict the display to a single folder:
10.3. Folders
Finally, the Folders snapin shows a similar selection option for folders:
Here, the two snapins, Folders and Views, work together in the display: Once selected, a folder is retained even if you select a different view with Views. This works for dashboards as well. Try it out!