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.

Werk #10601: Auto migration of check plugins to new section definitions

ComponentChecks & Agents
TitleAuto migration of check plugins to new section definitions
Date2020-03-20 11:45:12
Checkmk EditionCheckmk Raw Edition (CRE)
Checkmk Version2.0.0i1
LevelProminent Change
ClassNew Feature
CompatibilityIncompatible - Manual interaction might be required

We are now converting all plugins to the new format expected by the future API. Migrated are plugins from

  • share/check_mk/checks
  • local/share/check_mk/checks
  • share/check_mk/inventory
  • local/share/check_mk/inventory

Although we are trying to migrate as many check and inventory plugins as possible on the fly, for some plugins this may fail.

These are the anticipated reasons why auto-migration may fail:

A cluster aware checkplugin

Checkmk refuses to auto-migrate cluster aware (those with node_info set to True) check plugins. Auto converting the data layout is too error prone. These plugins must be migrated manually.

Checkplugins using 'extra_sections'

Checkmk refuses to auto-migrate check plugins that make use of the 'extra_sections' feature. In the new API the destiction between the regular section and additional 'extra_sections' is not made, and all section content will be passed in its 'parsed' version. Therefore these Plugins have to be migrated manually.

A missing SNMP scan function

Every Checkplugin that specifies an 'snmp_info' key must specify 'snmp_scan_function' as well.

A complex SNMP scan function

If Checkmk fails to auto-migrate a legacy SNMP plugin to a section definition, this is most likely due to an elaborate scan function. For the auto-migration to work, the scan function must be fairly simple. Make sure your scan function has the following properties:

  • it only consists of one single return statement
  • it does not in turn call other functions (not even 'all' or 'any')
  • it does not negate compound expressions

If in doubt, take a look at scan functions that succeed to be migrated to see what options are available.

Known limitations

  • HostLabels that are generated in a subchecks discovery function are lost