Werk #10601: Auto migration of check plugins to new section definitions
Komponente | Checks & agents |
Titel | Auto migration of check plugins to new section definitions |
Datum | 20.03.2020 |
Checkmk-Edition | Checkmk Raw (CRE) |
Checkmk-Version | 2.0.0i1 |
Level | Bedeutende Änderung |
Klasse | Neues Feature |
Kompatibilität | Inkompatibel - Manuelle Interaktion könnte erforderlich sein |
We are now converting all plugins to the format expected by the new API for check and inventory plugins.
This 'auto-migration' is done in memory upon loading the plugins, all files will remain unchanged on disk.
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. You can check for failing auto-migrations running the command `cmk -R`. You will be informed of any auto-migration failures.
If that is the case, you have to migrate your plugin manually.
These are the anticipated reasons why auto-migration may fail:
A cluster aware checkplugin
Checkmk refuses to auto-migrate cluster aware check plugins (those with node_info set to True). Auto converting the data layout is too error prone.
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. Please refer to the Sphinx documentation of `register.check_plugin` for details on the usage of the `sections` keyword.
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 are only supported via the new API (see werk #11117)