Dashboards

Dashboards are the central displays for your monitoring in Checkmk. They provide you with both overviews and detailed insights into specific areas. For example, you can visualise the general status of entire network segments, but also simply list which services are generating a load or overload of certain system resources. Checkmk comes with some standard dashboards, such as for problems, Checkmk server statistics and of course a general overview. However, you can also create your own completely individual dashboards from scratch.

In this article you will learn which tools are available for this and how exactly you can use them to create your own overviews. First, we will show you how dashboards work and how to work with them. Afterwards, we will shed light on the basics of layout and configuration, in order to build on this and step by step create a complete, simple example dashboard. Then follows a short summary on the topic of filters, as these can be set in a number of different locations. It continues with a presentation of all of those already built-in dashboards and dashlets — the individual building blocks for overviews. Finally, there are tips on how to deal with errors and problems.

By the way, you can see the most striking dashboard directly on the Checkmk start page, but dashboards can be treated like other views and easily accessed via the navigation bar and the sidebar. Dashboards are, of course, ideally suited to be placed separately on individual monitors, be it for a large control room, as an information display for server rooms or as a simple kiosk display for the conference room.

A special feature of Checkmk dashboards is that they can automatically adapt to the dimensions of the display or browser window using an intelligent algorithm. For each individual element of the dashboard — the dashlets — you can define exactly how they behave and in which directions they can expand if necessary.

Dashlets of various categories are available for the content: Regular views, graphs, metrics, prefabricated elements for various statistics and timelines as well as boxes for static texts and any URLs. An overview of all dashlets can be found below. Some of the dashlets are available exclusively in the Enterprise Editions.

An important feature of dashboard use: Using filters, even dashboards that show values for all hosts or services in the network can be broken down into specific areas. Dashboards are therefore not simply rigid displays, rather they are real tools for finding and analysing problems and statuses.

The special feature of the dashboard layout is its dynamism: although dashlets can be created with a fixed height and width, they can also grow automatically in both dimensions in order to make optimal use of the available space with each scaling — similar to responsive web design, but they can be configured in more detail.

The principle is simple: any corner of a dashlet is set as an anchor. From this fixed point, the dashlet can then grow in height and/or width as soon as more space is available, for example, simply on a larger screen, but also when the position or size of other dashlets changes.

You will see the dashboard configuration automatically when you create a new dashboard, later you can access it via the icons in the dashboard list (Customize > Dashboards) or the Dashboard>Properties menu item in an open dashboard.

The properties of the dashboard itself are trivial; only metadata such as name, menu item or visibility are defined here, as well as context filters if required. Context filters simply restrict dashboards and dashlets to certain hosts and/or services.

You will see the configuration of individual dashlets automatically when you add them to a dashboard; later you can call them up directly via a dashlet’s 'cogwheel' icon in the layout mode.

The configuration of most dashlets is quite simple, as the dashlet with the host matrix from the screenshots above shows. This is actually a dashlet of the Sidebar element type, and its entire configuration is limited to the selection of this sidebar element. For all dashlets that refer to several or individual hosts and services, you will also find corresponding filter options. And finally, some dashlets offer options for the precise design of the visualisation, for example via limit values. As an example, here is the Properties box of the Gauge dashlet:

Even away from the dashboard and dashlet configuration, there are important settings in Checkmk, namely permissions. Under Setup > Users > Roles & permissions > Edit role user you can simply filter for dashboard to list all options. Here for a role you can specify in detail which standard dashboards its assigned users can see and what exactly they are allowed to do with other dashboards.

A list of all individually-created and built-in dashboards can be found via Customize > Dashboards. For your own variants, you can call up the properties via and the layout mode via . You cannot edit the factory-set dashboards directly from the list, but you can clone them via and then customise the clone.

Here you will first see an overview of all 23 dashlets, then we will show you a few special features that were not covered in the example dashboard above.

Perhaps the most important question raised by most dashlets: Is the information displayed limited to single hosts or services? The answer can be found in all dashlet settings in the General Settings box next to Show information of single. If it says host, service, you need to set a context filter. If instead you see Not restricted to showing a specific object, you don’t need to set a filter — but you can in some cases. For dashlets such as Custom URL or Sidebar element there are, of course, no filter options.

How exactly you design the graphs in the graphing dashlets is a bit more complex and is explained in detail in the related graphing article.

A special role is played by the Custom URL dashlet. In theory, you can integrate external websites or resources by simply specifying an address - in practice, this often fails due to the security measures used by the operators and browsers. However, this does work with Checkmk’s own resources, for example other dashboards. You could, for instance, link several host-specific dashboards to one big overview. What you can also integrate — with a little experimentation — are internal resources from the Checkmk server; for example, any kind of web application, be it a wiki, a small chat programme or even a shell implemented via PHP.

The Site overview dashlet has two functions: In the layout explanations above, you see it as an overview of hosts — by default on a normal, single Checkmk site. In distributed monitoring, on the other hand, this dashlet shows an overview of the namesake sites.

The dashlet Static text can do a little more than you might expect: it is suitable for notes and simple labels, but it can also be used to link to other dashboards or other Checkmk components, as you can see in the following example of a top-down dashboard.

So now you are familiar with all of the available dashlets and finished dashboards, know where to access their configurations and layout options, and how to assemble a complete dashboard. However, dashboards do not necessarily have to stand on their own, but can also build on each other — for example, to navigate from a large overview to the smallest detail.

Basically, many dashboards already work exactly like this: The Host statistics visualises the host statuses and a click on one of the statuses redirects to a view that lists the associated hosts — and from there it goes on to the individual services of a single host.

For your own dashboards, you can also create links to other dashboards by simply linking the title bar of dashlets via Link of Title in the dashlet options. Let’s take a very concrete example: Here you see a dashboard that shows information on the CPU, RAM and file systems of all hosts that start with my.

In this example the title of the CPU graph links to another dashboard that visualises the CPU information for each host individually. In this dashboard, there is again a link at the top back to the overview, simply achieved using a Static text dashlet.

With such cross-links, you can develop complex research tools via dashboards. By the way, you are not limited to the title bar — you can certainly use HTML code as static text and thus incorporate entire navigations. Consider, for instance, distributed monitoring and paths such as General overview > Instance overview > Host overview > Container overview > Services > Problems.

It may occur that you will see only the following warning with a yellow background for a dashlet:

Unable to render this element, because we miss some required context information (host, service). Please update the form on the right to make this element render.

In this situation, the dashlet should be displaying information for only a single host and/or service — but for which no filter has been set. To fix this, you can either use the filters in the dashboard view or in the dashlet configuration.

There can be several reasons for completely empty dashlets without error messages. Usually it is a misconfiguration of the dashlet. Example: You create a dashlet for CPU load with the metric and the filtered service CPU load. Later you change the filter of the service description to something like Check_MK Discovery, but leave the selected metric at CPU load. When creating a dashlet, this cannot happen to you, because after the filter on the CPU load, the selection of an unsuitable metric is impossible — when reconfiguring dashlets, however, the originally selected metric is retained.

The solution to this problem is trivial — alter the service filter and the selected metric in the dashlet configuration. Of course, this also applies to all other dashlet variants.

The Total host problems and Total service problems dashlets are a special case for empty dashlets. Here you might encounter the following error message if you are using distributed monitoring: As soon as you add your Checkmk server(s) to the monitoring …​ Currently the following Checkmk sites are not monitored: …​

This basically means that Checkmk cannot see the remote site’s server as a host in the monitoring. You should first therefore not only check whether the connection for the distributed monitoring has been set up, but also whether the remote server has been included as a host.

It is possible that the remote site server is already being monitored but the error message still appears. In this case, it is usually due to the version of the remote site: If the central site is a 2.0.0, the remote site must also be a 2.0.0. In such a case, you need to update accordingly — but note the update notes.

There is another possible reason for the error message: In a connection to a remote site, a Site ID is assigned for it. If this ID does not exactly match the name of the site, but the IP address is correct, the connection itself is displayed as OK, but this error message will be triggered in the dashlet. The solution is simple: create a new connection with the correct ID.

The reason is identical in both cases: For the dashlets, the names of the connected sites are read from the connections of the distributed monitoring and from the service outputs — and the dashlets only function correctly if exactly the same sites are found in each case. This ensures that the correct data is actually output.