We use cookies to ensure that we give you the best experience on our website.  Visit our Privacy Policy to learn more. If you continue to use this site, we will assume that you are okay with it.

Your choices regarding cookies on this site.
Your preferences have been updated.
In order for the changes to take effect completely please clear your browser cookies and cache. Then reload the page.

The HW/SW Inventory

1. Introduction

In addition to the classical monitoring – ie 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:

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:

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:

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:

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 system Box Plug-in
Windows Windows Agent - Plug-ins mk_inventory.vbs
Linux Linux/Unix Agents - Plug-ins mk_inventory.linux
AIX Linux/Unix Agents - Plug-ins mk_inventory.aix
Solaris Linux/Unix Agents - Plug-ins mk_inventory.solaris

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

mk_inventury.vbs
Dim delay
Dim exePaths
Dim regPaths

'These three lines are set in the agent bakery
delay = 14400
exePaths = Array("")
regPaths =
Array("Software\Microsoft\Windows\CurrentVersion\Uninstall","Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall")

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

/etc/check_mk/mk_inventury.cfg
INVENTORY_INTERVAL=7200

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

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

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:

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 Inventory.

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

The same menu item can also be found in the 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 Hardware, Networking and Software, you can expand and collapse the tree’s sub-branches:

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 Software ➳ Packages table:

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:

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:

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 Inventory History button:

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:

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:

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

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:

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 host_inv_api.py?host= including the desired hostname. Example:

http://mycmkserver01/mysite/check_mk/host_inv_api.py?host=myhost123

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

http://mycmkserver01/mysite/check_mk/host_inv_api.py?host=myhost123&output_format=json

The result will look something like this:

myhost123.json
{
    "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

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.

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

Path Description
share/check_mk/agents/plugins/ Here are agent plug ins for Linux and Unix
share/check_mk/agents/windows/plugins/ Agent plug-ins for Windows
var/check_mk/inventory/ Inventory data from individual hosts as Python files (compressed and uncompressed)

8.2. Directories on the monitored hosts

Path Description
C:\ProgramData\checkmk\agent\plugins\ Storage location for the Windows agent’s inventory plug-in
/usr/lib/check_mk_agent/plugins/ Storage location for the inventory plug-in for the Linux/Unix agent
/etc/check_mk/mk_inventory.cfg Configuration for the inventory plug-in for the Linux/Unix agent