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 visualize 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 widgets — 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.

What sets Checkmk dashboards apart is our very own anchored layout: Using a smart algorithm, dashboards automatically adjust to the dimensions of the display or browser window. You can specify exactly how each individual element of the dashboard—the widgets—behaves and in which directions they expand when necessary.

Starting with version 2.5.0, the commercial editions also include an alternative responsive layout: Here, you can easily design your layout using drag-and-drop, and the layout automatically adapts to different screen sizes.

For a comparison of the two systems and further details, see the chapter Layout.

Widgets 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 widgets can be found below.

Some of the widgets are available exclusively in the commercial 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 analyzing problems and states.

This layout system is completely intuitive: You place widgets using drag-and-drop, and resize them using the handle in the lower-right corner. Here is an example, for simplicity’s sake, featuring eight versions of the same Site overview widget:

For example, if this dashboard is viewed on a mobile device, or if you simply resize the browser window to make it a bit narrower—as shown here for demonstration purposes—the layout and scaling of the widgets will adjust accordingly:

The big advantage: Everything happens automatically. The downside: If you want to display a specific widget—such as a graph with a timeline—across the full width at all times, this system doesn’t allow for that.

The principle is simple: any corner of a widget is set as an anchor. From this fixed point, the widget 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 widgets changes.

To illustrate this function, here is an example — in the center a host matrix widget with manual height and width settings, and in its upper left corner an anchor. You can recognize the anchor by the green corner, the settings for current height and width can be found in the middle of the widgets.

This is framed by four host-overview widgets, all with automatic height, the side ones also with automatic width — the widgets at the top and bottom get the setting max width. By default, the anchor is at the top left, but here the right widget gets the anchor at the top right and the bottom one at the bottom left.

If you now move the widget in the middle further to the left and down, for example, the widgets on the left, right and bottom change — because they automatically grow from their anchors towards the central host matrix widget.

The top widget, on the other hand, remains as it is — after all, it cannot grow downwards because the two side widgets are anchored at the top.

If you now switch the lower widget from Max width to Auto width it no longer extends over the entire width — because the automatic height of the right widget is rendered before the automatic width of the lower widget.

If widgets with automatic dimensions are competing for the same space, you can use the maximum setting to determine the winner, so to speak — but be careful: If two widgets set to maximum compete for the same space, overlapping can occur.

The whole dynamic layout principle is easier to understand if you create such a test setup yourself and try pushing the widgets around a bit.

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 > Visualization > Dashboards) or the Settings > Dashboard 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.

You can view the configuration of individual widgets automatically when you add them to a dashboard. Later, in the layout mode, you can access their configurations directly via the gear icon on the widgets.

By the way: In the Responsive Layout, the widgets look slightly different, but the icons are the same:

Configuring most widgets is quite simple. Typically, you will find Data settings for limiting and displaying data, as well as Widget settings with options for titles, links, and so on—here using the Gauge widget as an example.

For all widgets that refer to some or specific hosts and services, you will also find corresponding filter options.

A detailed description of the filters can be found in the chapter Filters, and specific examples of widget configurations in the chapter Example Dashboard.

Even away from the dashboard and widget 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.

Filtering dashboards and widgets is a powerful feature available in several forms. Here is an overview:

Default filters set specific criteria for the entire dashboard; for example, the Host name (exact match) filter with the value myhost.

Setting Runtime filters in the dashboard configuration sets empty defaults for the entire dashboard—for example, the Host name (exact match) filter—and users must then set these themselves at runtime (i.e., when viewing the dashboard). If Runtime filters are set in the configuration, the dashboard starts with the filter dialog open—after all, users must fill these filters with values.

Widget filters are set for each widget in its respective widget configuration. Here, filtering is based not only on hosts and services, but also on metrics (from services) if required.

You can access the two dashboard filters from the dashboard via Settings > Filter settings, and the widget filters via the gear icon on the widgets themselves.

Runtime filters are also available outside the configuration in the regular dashboard view — for regular users. You can access these filters via the Filter button right next to the dashboard selection.

It is also important to note how these filters interact with each other: Widget filters override runtime filters, which in turn override default filters.

The following image illustrates the entire filter spectrum for hosts (points 3 through 5):

This dashboard includes a predefined Metric widget that always displays the RAM usage metric for the Memory — as standard, via the default filter from the host localhost, which is overridden here by the runtime filter to the host myhost, which in turn is overridden by the widget filter to the host raspi_lan.

In other words: When creating dashboards, you can set dashboard-wide defaults that users can either override (runtime filters in the view) or are required to override (runtime filters in the configuration). Individual widgets, on the other hand, can be configured with fixed settings, preventing users from applying additional filters.

Have you spent hours building a powerful dashboard? It would be a shame to keep it to yourself. That’s why you can share dashboards, both internally and externally.

You can access the corresponding configuration in the respective dashboard via Share > Configure sharing.

An internal link to the dashboard is available by default at Internal access — and this does not affect the status shown at the top of the image (here Sharing paused).

This status applies solely to the public link at Public access; after all, dashboards may well contain sensitive information that is not necessarily intended for public viewing.

As soon as you enable a link here, the status changes from Sharing disabled to Sharing enabled. If public access is enabled and you make changes to the dashboard, you will see the status Sharing paused. To resume sharing, you must share the dashboard again. The sharing link itself does not change.

The only option when sharing: You can set an expiration date for the share. In Checkmk Community, shares are limited to a maximum of 30 days; in the commercial editions, an expiration date is completely optional.

Shared, public dashboards have a few restrictions for security reasons: navigation and menus are hidden, there are no filtering options, and sidebar elements are not available. Additionally, not all entries may be visible in list views because they are limited by default, and the buttons to remove these limits are missing — again, for security reasons.

A list of all individually-created and built-in dashboards can be found via Customize > Visualization > 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 customize the clone.

Here is an excerpt of the built-in dashboards:

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

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

A special role is played by the Custom URL widget. 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 or a small chat program.

The Site overview widget 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 widget shows an overview of the namesake sites.

The widget 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 widgets 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 visualizes the host states and a click on one of the states 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 linking the title bar of widgets via Link of Title in the widget options. Let’s take a concrete example: Here you see a dashboard that shows information on the CPU, RAM and file systems of some hosts.

In this example the title of the CPU graph links to another dashboard that visualizes 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 widget.

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 widget:

Enter runtime filter to load data

In this situation, the widget 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 widget configuration.

There can be several reasons for completely empty widgets without error messages. Usually it is a misconfiguration of the widget.

Example: You create a widget 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 widget, this cannot happen to you, because after the filter on the CPU load, the selection of an unsuitable metric is impossible — when reconfiguring widgets, however, the originally selected metric is retained.

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