In this article, the screenshots and the GUI navigation described have not yet been updated to Checkmk version 2.0.0. However, nothing fundamental has changed in the described functions themselves and most of the functions can be found quickly with the Monitor or Setup menu search of the Checkmk 2.0.0 user interface. We will update this article as soon as possible.

1. Introduction

In addition to the classical monitoring — i.e. the monitoring of status, log and measurement data — Checkmk includes another completely different function virtually free of charge: the Hardware/Software Inventory (or HW/SW Inventory for short). This can automatically identify elements on your hosts, such as, for example:

  • Which software packages — and which versions of these — are installed on a server?

  • What kind of RAM components does a server have?

  • Which BIOS version is installed on the motherboard?

  • The serial numbers of the installed hard disks.

  • Whether any ports on a switch not been used for a while (and which are thus probably free)?

  • …​ and much more

The data obtained in this way are displayed per host in a structured tree, and in various other views, and are also available via an API. Here is a small example of inventorying ORACLE databases:

inventory intro

With the Hardware/Software Inventory you can perform a variety of tasks, such as:

  • Provide data about installed software for a license management system

  • Determine type designations for spare parts orders (RAM, hard disks, fans)

  • Provide general hardware and software data for regular import into CMDBs, so that these are based on current data

  • Track changes to hardware or software, e.g., to determine when a specific BIOS update was performed

  • Be alerted if something has changed in the hardware or software

  • To identify servers that have not yet had a specific service pack installed

The most important advantage over other comparable systems is obvious — you can simply use the existing infrastructure of Checkmk and save yourself the effort of rolling out and administering another software environment. You just roll out a single additional agent plug-in. This is not even necessary with SNMP devices because the inventory scanner also supports SNMP and simply fetches the data over this route.

And besides, CMK does not need to hide behind other inventory scanners. As with our check plug-ins, we are constantly working to expand the data scanning. Each Checkmk version brings new plug-ins for the inventory scanner, and the information that can be collected is becoming more detailed and extensive.

2. Installation

Installing the HW/SW Inventory is performed in two steps. The prerequisite is that the Checkmk agent is already installed on the hosts (if they are not monitored via SNMP):

  1. Switch on inventory for the desired hosts

  2. Roll out the Inventory plug-in on these hosts

2.1. Activating the inventory for the desired host(s)

Creating the rule

As always, if you want to configure something for specific hosts this is also possible with the help of a rule. This rule can be found under WATO > Host & Service Parameters > Hardware/Software Inventory > Do hardware/software inventory. Of course it is even easier using the rule search with the word inventory (please do not confuse this with the Hardware/Software Inventory (Linux, Windows, Solaris, AIX) set of rules, which is for the agent plug-in, as we’ll see later). Create a new rule for the hosts for which you want to activate the inventory. There you will find several settings:

inventory rule value

For now simply leave everything as preset. The various options that you will see here are discussed below.

The rule you have just created will generate an active check for each host at the next ‘Activate Changes’ that collects all of the inventory data for that host — be it from the data that is received from normal Checkmk agents, or through additional SNMP queries. The new service can be found on the hosts in the service list, and it looks something like this:

inventory service

Please do not be concerned that the check found only one item — this is because we have not rolled out the plug-in yet.

Defining the interval

Inventory data is something that rarely changes, and recognizing a change is usually not time-critical anyway. Because of this it makes sense to adjust the interval during which the inventory check is performed rather than simply using the usual one-minute interval — mainly because the processing of the inventory data in the active check requires significantly more computing time than that for a normal service.

Checkmk instances that you have created with version 1.4.0 or later automatically have a rule in the Monitoring Configuration > Normal check interval for service checks set of rules which sets the interval to one day for all services with the name Check_MK HW/SW Inventory:

inventory check intervall

Important: If you do not find this rule, please create one yourself, otherwise the check will be performed once a minute and will require unnecessary processing time on your Checkmk system.

Of course if you find once a day insufficient, you can also adjust this rule — e.g., to four or eight hours. Naturally there is also always the option of setting it differently using multiple rules for different hosts.

2.2. Rolling out the Inventory Plug-in on these hosts

The most important step is to install the agent plug-in for the inventory on the relevant hosts. You can do this either manually or with the Agent Bakery (only Enterprise Editions).

Manual installation

For a manual installation you first need the plug-in. This can be found in the Enterprise Editions on the WATO > Monitoring Agents > Agent Files page, and in the Raw Edition directly under WATO > Monitoring Agents. Depending on the operating system, use one of the following plug-ins:

Operating systemBoxPlug-in


Windows Agent - Plug-ins



Linux/Unix Agents - Plug-ins



Linux/Unix Agents - Plug-ins



Linux/Unix Agents - Plug-ins


You can also find these files on the command line in the Checkmk instance in the share/check_mk/agents/plugins (Linux/Unix) subdirectory, or in share/check_mk/agents/windows/plugins (Windows).

Copy the plug-in to the destination hosts in the correct directory for plug-ins. For the Windows Agent version 1.6.0 it is C:\ProgramData\checkmk\agent\plugins. For details see the Windows Agent article.

For Linux and Unix the directory is /usr/lib/check_mk_agent/plugins. Please make sure that the file is executable (chmod +x …​). For details see the Linux Agent articles.

The important thing is that the agent is called by CMK, usually once a minute. The inventory plug-in, however, requires more processing time than normal plug-ins because, for example, it must search for installed software in many directories. It also generates significantly larger amounts of data. This is why it has been designed to only generate and deliver new data every four hours (14400 seconds).

So if for some important reason you have set a shorter interval than four hours for your inventory check, you will only actually get new data every four hours. If you really want to collect more data, in such a case you will need to adjust the default calculation interval.

For Windows replace the number directly in the plug-in. Search for the number 14400 and replace it with a different number of seconds. The location where this is found looks like this (detail):

Dim delay
Dim exePaths
Dim regPaths

'These three lines are set in the agent bakery
delay = 14400
exePaths = Array("")
regPaths =

With Linux and Unix this is a bit different. For this purpose create a configuration file /etc/check_mk/mk_inventory.cfg with the following line (here in the example with 7200 seconds):


One more note: The inventory plug-in itself dictates that it runs only every four hours. Therefore do not use the mechanism from the agent for asynchronously running plug-ins at longer intervals. Install the plug-in in the simple usual way for direct execution.

Configuration using the Agent Bakery

CEE Of course if you use the Agent Bakery to configure your agents, things are much more straightforward. There is only one rule set independent of the operating system. This rule set controls the rolling-out of the necessary plug-in as well as its configuration. It can be found at WATO > Monitoring Agents > Rules > Hardware/Software Inventory (Linux, Windows, Solaris, AIX):

inventory plugin rule

In addition to the interval you can also specify paths for Windows in which to search for executable .EXE files when it comes to finding the software installed on the system. You can also configure the paths in the Windows registry, which should be taken into account as an indicator for installed software.

2.3. Testing

If you have rolled out the plug-in correctly, you must find significantly more records the next time you run the host’s inventory check. The result will then look like this:

inventory service full

3. Working with the inventory data

3.1. Tree-structured display

The hosts’ inventory data is displayed on the one hand in a tree-structured display per host, and on the other hand in table-form. The tree can be reached in different ways. If you are in a host view (for example, Services of Host …​), at the top of the view in a menu of buttons you will also find a button labelled icon inv Inventory.

inventory contextbutton

Alternatively, go to the Check_MK HW/SW Inventory service, and from there to the icon menu menu icon, and then to icon inv Show Hardware/Software Inventory of this host:

inventory menu button

The same menu item can also be found in the icon menu menu of the host itself, which you will find in views that list hosts rather than services.

In all three cases you end up with the tree view of the host’s inventory data. Starting from the three basic categories icon hardware Hardware, icon networking Networking and icon software Software, you can expand and collapse the tree’s sub-branches:

inventory tree

3.2. Tabular displays

Many of the inventory data are individual values under very specific paths in the tree, e.g. the Hardware > System > Manufacturer > Apple Inc. entry. But there are also places in the tree with tables of similar objects. A very important one is, e.g. the icon software Software > icon packages Packages table:

inventory software packages

You can find the table of all the software packages installed on the host by clicking the Open this table for filtering/sorting link in the upper right corner. This additionally shows you that this table also exists as a view — with the usual options such as filtering and sorting. The important thing here is that this view gives you the ability to search in the data (e.g., software packages) from all hosts, not just one.

You can as usual access the filters with the icon filter icon:

inventory software search

If you came here via the link above, then the corresponding hostname is already listed in the hostname (exact match) filter. If you remove this, you can search for all hosts in your monitoring.

All table-like inventory views can also be found via the Views element in the sidebar under the Inventory entry. Those views which begin with the word Search do not submit data until you press the Search button (after you may have filled in some of the filters).

Please note that many general filters to the hosts are not available by default in the views. These are obtained when you edit the view and add additional host filters.

Further things you can do with the views:

Incidentally, you can also include such inventory data in views that are not table-like. There is a column type for each well-known path in the inventory tree, which you can add to views of hosts. An example of this is the predefined example view CPU Related Inventory of all Hosts. This is a table of hosts that displays additional data from the inventory per host. Here is an example of one of the column definitions that adds a column to the number of physical CPUs of the host:

inventory view column

4. Inventory data history

Once you have set up the HW/SW inventory for a host, CMK will record every change in the inventory data and also store its history. You can find these histories from a hostview using the icon inv Inventory History button:

inventory contextbutton 2

Here is an excerpt from a history. In the table of installed software packages you can see how a software update on a Linux system changed the version numbers of several installed packages. Unchanged data is not displayed here:

inventory software history

If you want you can be alerted whenever a change in software or hardware occurs. This is done via the status of the service Check_MK HW/SW Inventory. To do this edit the rule that you created at the very beginning of this article (in the Do hardware/software inventory ruleset). There in the value of the rule you will find a number of settings that affect the history. The following example sets up the service WARN if changes occur in software or hardware:

inventory warn on changes

The next time the inventory check detects changes, it will go to WARN. It will then look like this:

inventory software changes

At the next execution of the check, and if in the meantime nothing has changed, this resets automatically to OK. By manually triggering the execution you also have a way to manually reset the service to OK if you do not want to wait for the next normal periodic execution.

5. Status data

The tree of inventory data can be automatically updated with the latest suitable status data. This is very useful in some cases. An example of this is the ORACLE tablespaces. The actual inventory data contains only relatively static things like the SID, the name and the type. Current status data can supplement this with information on the current size, free space, etc.

If you want status data in your tree (and there’s nothing wrong with that), you really do not have to do anything more because usually — in those which you created in the beginning under Do hardware/software inventory — this is by default automatically enabled:

inventory rule value

If you have not actively removed the ‘x’ in the Status data inventory checkbox, or have changed the setting there, you will also receive status data. By the way, a change in the status data will not precipitate changes in the history! This would almost always lead to constant changes and render this function useless.

6. External access to the data

6.1. Access via Web-API

You can export a host’s HW/SW inventory data through a Web API. The URL to it is including the desired hostname. Example:

The output format in this case is Python source code. If you prefer JSON, just append a &output_format=json to it:

The result will look something like this:

    "result": {
        "hardware": {
            "chassis": {
                "manufacturer": "Apple Inc.",
                "type": "Notebook"
            "cpu": {
                "arch": "x86_64",
                "cache_size": 6291456,
                "cores": 4,
                "cores_per_cpu": 4,
                "cpus": 1,
                "max_speed": 2500000000.0,
                "model": "Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz",
                "threads": 8,
                "threads_per_cpu": 8,
                "vendor": "intel",
                "voltage": 1.1
... usw...

    "result_code": 0

If you enter the URL in the line of your browser, this will work immediately because you are already logged in to Checkmk there. From a script the best way to authenticate is to use Automation-User.

6.2. Access via a file

Alternatively, you can simply read the files that CMK generates itself. These files are in python format and are located in the var/check_mk/inventory directory. For each host there is a file in an uncompressed version (for example, myhost123), and a compressed version (for example, myhost123.gz).

7. Inventories in distributed environments

CEE On the Enterprise Editions HW/SW inventory also works in distributed environments. Here the inventory data are first determined by the local instances and stored there locally under var/check_mk/inventory. Status data are not stored in files, but like the results of checks are held directly in the main memory of the monitoring kernel.

The livestatus proxy daemon will periodically transfer all updated inventory data from the remote site to the central site, and also store it under var/check_mk/inventory. This is important because this data is too large to pick up live when queried at this moment.

As soon as the central instance makes queries about inventory data, these files are read and then merged with current status data, which is then retrieved from the remote instances via livestatus.

In short — you do not have to worry about anything.

CRE There is no live status proxy in the Raw Edition. Therefore the HW/SW inventory in the central GUI is incomplete and shows only the status data. You can do this by regularly transferring the files in the var/check_mk/inventory directory to the central site with a script or the like. It is sufficient to copy the files without the .gz file extension. For efficient data transmission rsync, for example, is suitable.

8. Files and directories

8.1. Directories on the Checkmk server



Here are agent plug-ins for Linux and Unix


Agent plug-ins for Windows


Inventory data from individual hosts as Python files (compressed and uncompressed)

8.2. Directories on the monitored hosts



Storage location for the Windows agent’s inventory plug-in


Storage location for the inventory plug-in for the Linux/Unix agent


Configuration for the inventory plug-in for the Linux/Unix agent

On this page