1. Introduction

In this article you will find the most important topics relevant to an update of your Checkmk from version 2.2.0 to version 2.3.0.

We recommend that you read through the entire article before updating so that you know exactly what to expect: before, during and after the update.

2. Preparations

This chapter gives you an overview of the topics you should take into consideration before you perform the update. Probably not every topic will be relevant for you: For each topic, you can check the corresponding box for your own reference and immediately move on to the next topic.

2.1. Backup

As with any update to production software, you should check that your backups are up to date before performing the update of Checkmk.

Does this affect you? Yes.

What do you have to do? If you create your backups automatically via Setup > Maintenance > Backups, check there that your backups are up to date and that the most recent backup jobs have completed without errors.

For more information, see the articles on Backups and on Backing up and restoring sites.


From the update to 2.3.0, changes are rolled back in the event of a failed update (Werk #16408). An update can fail due to an unexpected internal error, but also due to user input during the update process, for example by selecting the menu option abort or by pressing the key combination CTRL+C. Only when the text Completed verifying site configuration. Your site now has version 2.3.0pX is displayed, the updated configuration is active. Restoring the configuration does not replace a backup, but usually reduces downtime if something goes wrong.

2.2. Check hardware utilization

Checkmk 2.3.0 requires slightly higher system resources than 2.2.0. It is therefore advisable to find out before updating which free capacity the servers used for Checkmk still have.

Does this apply to you? Yes, but the extent to which you are affected depends heavily on how you use Checkmk. The update of the Python interpreter from version 3.11 to 3.12 alone causes a load increase in the single-digit percentage range. Furthermore – depending on the proportion to the total number of checks – more extensive checks, especially in the cloud area, can result in further additional load, so that a total of 10-15 % (in extreme cases around 20 %) more CPU load can be expected.

What do you have to do? Make sure that there is sufficient free capacity available. As a rule of thumb: If the CPU load is below number of processor cores × 0.8 and the CPU utilization is below 70 %, no problems are to be expected. If one or both values are higher, create sufficient free capacity, for example by deactivating test sites on the same server or moving hosts to other sites.

2.3. Linux distribution versions

In Checkmk version 2.3.0 some obsolete distributions will no longer be supported.

Does this affect you? This affects you if one of the following Linux distributions - still supported in 2.2.0 - is installed on your Checkmk server:

  • RedHat Enterprise Linux 7

  • Ubuntu Short Term Support (STS) versions 22.10 to 23.10.
    From 2.3.0 Checkmk only supports Ubuntu Long Term Support (LTS) versions.

  • SLES 15 SP1 and SP2

What do you need to do? Before updating Checkmk, first perform an Linux distribution version upgrade. Make sure that the target version of the Linux distribution of Checkmk is 2.2.0 and 2.3.0 is supported. You can find out which Linux distribution versions Checkmk supports in the update matrix for 2.3.0 and on the download page after you have selected the Checkmk version and your Linux distribution.

Shortly after the release of Ubuntu 24.04 LTS, we will provide packages of Checkmk 2.2.0 and 2.3.0 for this distribution version. This will allow you to first update to the latest patch version of Checkmk 2.2.0, then update from Ubuntu 23.10 STS to 24.04 LTS and finally update to the latest patch version of Checkmk 2.3.0.

2.4. PHP on SLES 15 SP3/SP4

With Checkmk version 2.3.0 (and 2.2.0p21) on SUSE Linux Enterprise Server 15 Service Pack 3 and 4, the dependency on the PHP programming language runtime environment is increased from version 7 to version 8.

Does this affect you? Yes, as a user of SLES 15 SP3/SP4. The update is somewhat more complex, as package sources for the outdated version 7 must be deactivated and activated for the new version 8.

What do you need to do? If, in addition to Checkmk applications on your server that use the PHP programming language, make sure that they can handle PHP 8 without any problems. Then prepare the package sources for the update to 2.2.0p21 (or higher), which is mandatory for the installation of Checkmk 2.3.0, as described in Werk #16025.

2.5. Browser support

Checkmk 2.3.0 uses new JavaScript features that are not available in older browsers. Which browsers are supported in which versions can be found in the Release notes.

Does this affect you? You will usually have automatic updates to the latest version enabled on desktop systems.

What do you need to do? Check the browser version you are using and install a more recent browser if necessary. If you are using Single Board Computers, Smart TVs or Digital Signage solutions to display dashboards and you have no control over the system browser, test that any required dashboards are displayed correctly before updating. If necessary, contact the hardware manufacturer for updates.

2.6. SSL compatibility

For the first time, Checkmk 2.3.0 provides OpenSSL in version 3.0 instead of the previous 1.1. This change affects almost all components that use Secure Socket Layer or Transport Level Security.

Does this affect you? As OpenSSL 3 is now widely used, hardly any surprises are to be expected. Problems can occur - especially with active checks - if connections are to be established to devices that expect old ciphers or attempt renegotiation. These are usually old network devices (switches, printers…​) that no longer receive updates. In some cases, services on older Linux distributions or Unix versions are affected, which are still supplied with updates.

What do you need to do If possible, try to find out in advance which devices are likely to have problems. Good indicators for this are age and how long ago updates were installed. Test these devices with Checkmk 2.3.0. If problems occur, you have two options:

  1. Check whether updates or configuration changes are possible. Older but still supported operating systems in particular often allow older default settings to be overwritten with more secure modern settings.

  2. If this is not possible, the affected active checks can be manually configured for other default settings using the rule Integrate Nagios plugins. We are currently preparing detailed instructions. If required, you can request a preliminary version via Help Desk Beta or in the forum.

2.7. Managed Services Edition is based on Cloud Edition

With Checkmk 2.3.0, Managed Services Edition changes its foundation from Standard Edition to Cloud Edition. This not only means that the Managed Services Edition receives the extended range of functions of the Cloud Edition, but also that the license management is aligned with that of the Cloud Edition.

Does this affect you? This only affects users of Managed Services Edition, other forms of distributed monitoring are not affected.

What do you need to do? Updating a Managed Services Edition to 2.3.0 follows the general procedure in distributed environments with distributed setup. However, it must be ensured that the central site can still transfer the license information under Checkmk 2.2.0 to remote sites already updated on Checkmk 2.3.0.

As the necessary changes are only implemented in Checkmk 2.2.0p17 (Werk #16193), you must therefore update the central site to at least this version. This ensures the transfer of the license information. The remote sites can then be updated to 2.3.0 and finally the central site.

Irrespective of the minimum requirement for 2.2.0p17 mentioned here, we recommend that you first update all involved sites to the latest available patch version of 2.2.0 and only then start the update to 2.3.0.

2.8. Automatic agent updates from versions prior to 2.2.0p8

Checkmk 2.3.0 no longer creates SHA1 signatures for agent packages. The verification of SHA256 signatures was introduced with Checkmk 2.2.0p8. In order for agent updates to version 2.3.0 to take place automatically, the agents must first be updated to version 2.2.0p8 or higher.

Does this affect you? This affects you if you perform automatic agent updates but occasionally skip patch versions of the agent. It also affects you if your deployment uses prepared operating system images that include the Checkmk Agent Updater and rely on automatic installation/update.

What do you need to do? Make sure that all agents that are to be updated automatically have been updated to at least version 2.2.0p8. In particular, check prepared operating system images and update the existing agent to version 2.2.0p8 or higher. And if you are currently working on agent updates, you can already add the certificate provided by the agent bakery now, if this is required later.

2.9. The agent for Windows: Deprecated plug-ins

Some plug-ins that were marked as deprecated have been removed and may require manual installation if needed: Werk #16359

2.10. The agent for Windows: Python 3.4 removed

The official support for the Checkmk agent under Windows Server 2008 and Windows 7 by Checkmk GmbH already ended with the release of Checkmk 2.2.0. Nevertheless, operation under Windows Server 2008 R2 and Windows 7 was still possible without restrictions. With 2.3.0, restrictions must be accepted: The previous option of supplying a Python 3.4 runtime environment for Windows agents via the agent bakery rule is no longer available in 2.3.0.

Does this affect you? Hopefully not: The discontinuation only affects you if you use agent plug-ins written in Python on Windows Server 2008 R2 or Windows 7 (both end-of-life already in 2020). Current Python versions run on all newer Windows versions. On all even older Windows versions - such as Windows Server 2008 R1 or Windows Vista - the agent could no longer be used in version 2.2.0.

What do you have to do? If you want to continue monitoring these Windows systems, you must provide the runtime environment for agent plug-ins that require Python yourself: Install Python 3.4 manually on affected systems. For these systems, usually set Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Windows modules > Install Python runtime environment the setting Install Python runtime environment > Installation to Never install Python with the agent. Please note that we cannot guarantee support for such old Windows systems and no longer test new agent versions in patch releases.

2.11. Checkmk without Apache module mod_auth_mellon

mod_auth_mellon is a software module for Apache that provides services for authentication via Secure Assertion Markup Language (SAML). The connection to SAML authentication services was possible in Checkmk 2.2.0 in two ways: At Apache level with mod_auth_mellon (the only supported option until version 2.1.0) or in the commercial editions of Checkmk the built-in SAML authentication. With version 2.3.0 mod_auth_mellon` is no longer delivered with the Checkmk software.

Does this affect you? This affects you if you use SAML authentication with mod_auth_mellon.

What do you need to do? Users of the commercial editions should switch SAML authentication to the solution integrated in Checkmk before updating to 2.3.0.

If you are using the Raw Edition, you can already install mod_auth_mellon system-wide before the update according to the instructions on the project page. Then change the line for loading the module in the configuration file ~/etc/apache/conf.d/auth.conf to the system-wide installation path. The installation directory may vary depending on the distribution used:

LoadModule auth_mellon_module /usr/lib/apache2/modules/

Restart your site after making the change. Finally, test — still under 2.2.0 — whether SAML authentication continues to work. If this is the case, no difficulties are to be expected after the update.

2.12. Uninstalling Python modules

Checkmk 2.3.0 updates Python from 3.11 to 3.12. This update affects modules installed to a Checkmk site. In many cases, post-installed modules are incompatible with Python 3.12. In the worst case, obsolete modules overwrite the functionality of the modules supplied by Checkmk.

Does this affect you? This will only affect you when you have explicitly-installed Python modules for special agents or agent-based check plug-ins that you have written yourself or obtained from the Exchange. If you are unsure, carry out the check described in the following section.

What do you need to do? First find out whether Python modules are installed in the site, and if so — identify them. To do this, search for the directories dist-info and egg-info:

OMD[mysite]:~$ find ~/local/lib/python3/ -type d -name '*.*-info'

Make a note of the installed modules and then uninstall them:

OMD[mysite]:~$ pip3 uninstall cryptography ecdsa

You can find out how to deal with uninstalled Python modules after the update below.

2.13. Prometheus checks data source and settings

The Prometheus special agent offered kube-state-metrics as data source, whose checks are no longer supported. These have since been replaced by improved counterparts in the Kubernetes agent (see Werk #14572). In addition, in the Prometheus and Alertmanager rules, the specification of IP address/host name, port and path prefix has been replaced by a single input field Custom URL (see Werk #14573).

In both cases, the old method continued to work in 2.2.0. To use it in 2.3.0, however, you must have changed your configuration to the new method.

2.14. Packaged (MKPs) and non-packaged local files

Local files allow you to customize and extend the functionality provided by Checkmk. These files are located in the local part of the site directory structure, i.e. in ~/local and can be organized in extension packages or just "lying around". Local files can cause problems during an update if they no longer match the new Checkmk version.

Does this affect you? Since it is not possible for Checkmk to fully ensure the compatibility of local adaptations during an update, you should check your Checkmk site before an update to see whether local files are used, which ones they are and how they are organized.

What do you need to do?

  1. Use mkp list to create an overview of existing extension packages (MKPs) and their sources: You can usually easily test the extensions you have developed yourself and adapt them if necessary. For externally sourced MKPs, you should research whether there are known problems with Checkmk 2.3.0 and whether new versions are available. In cases where functionality previously provided by the MKP is now provided by Checkmk 2.3.0, deactivate the package before updating.

  2. Get an overview of unpackaged local files of your Checkmk site by executing the command mkp find as site user. If paths with python3 appear here, go back to Python modules again. The following applies to all other files: Combine files that belong together in MKPs. This makes it easier to deactivate en bloc later if incompatibilities are detected after the update.

  3. In the case of MKPs that require different versions for Checkmk 2.2.0 and 2.3.0, you should have installed both package versions with correct compatibility information in Checkmk before performing the update. If different versions of a package are available, Checkmk automatically activates the appropriate version during the update. As central sites with Checkmk 2.2.0 can hold packages for 2.3.0 and distribute them to remote sites, this feature also helps when updating in distributed environments with a distributed setup.

2.15. Programming interfaces

In Checkmk 2.3.0 some internal programming interfaces (APIs) have been rebuilt. Some previously ad-hoc defined APIs have been replaced by well-specified ones. In addition, the check APIs already marked as deprecated in 2.0.0 have been permanently removed.

Does this affect you? The topic of APIs affects you if you have extended the checks delivered with Checkmk with your own, self-written checks and/or if you use plug-ins from other sources.

What do you need to do? Check the functionality of extensions you have written yourself and those from third-party providers. Since the new APIs can be used parallel to the old ones during Checkmk 2.3.0 and changes to the existing APIs could be small, most extensions will continue to be usable without modifications. If changes are necessary, we recommend migrating to the new APIs, which are available from Checkmk 2.4.0 completely replace the old APIs.


With Checkmk 2.3.0b6, the check APIs for versions up to 1.6.0 that were already marked as deprecated in 2.0.0 finally have been removed (Werk #16689). Checks that were created using these programming interfaces will be deactivated during the update. Before updating, check whether such checks are present and port them to one of the two new API versions — preferably, of course, the well-specified ones available from 2.3.0.

2.16. Deprecations in the REST-API

Deprecated endpoints or parameters of the Checkmk REST API are marked in the API documentation with the icon .

Does this affect you? This may affect you if you use the Checkmk REST API in your own scripts, for example.

What do you need to do? Open the REST API documentation with Help > Developer Resources > REST API documentation. Search for Deprecated in the browser on the page, check whether you are using deprecated elements in your scripts and replace them before updating. In the REST API documentation, you will usually find instructions on how to replace the functions that no longer exist in the new version.

2.17. Incompatible changes

As in every Checkmk version, there are also changes to the software in the current version 2.3.0 – at Checkmk organized and documented in so-called Werks – which may have repercussions on your Checkmk installation. A so-called incompatible change requires that you make manual modifications in order to allow existing functions to continue to run as usual and/or to be able to use new functions.

Does this affect you? In general, there will be incompatible changes that will also affect your Checkmk installation, it is however impossible to make a general statement. In this article we have collected those issues that apply to all or most Checkmk installations. In any case there may be additional changes that are relevant to you, for example in checks that you use in your installation.

What do you need to do? After every update – including patch releases – Checkmk will show you the number and content of incompatible changes and ask you to check and take note of them. Before performing the update is the right time to check for any changes from version 2.2.0 that may have an impact on the update. Since Checkmk 2.3.0, such Werks are no longer dragged on, but deleted during the update after showing a confirmation dialog (Werk #15292).

It is also a good idea to get an overview of the incompatible changes in version 2.3.0 before the update: Open the list of Werks on the Checkmk website. In the description of a Werk, you will find information on what you may need to do to make the change compatible.

After you have carried out the update, the number and content of the incompatible changes will be displayed in the Checkmk interface and you will be asked to check and take note of them. Links help you to check so that you can find out with just a few clicks whether you are using an affected component. If it is certain that a Werk has no impact or you have made the required changes, confirm it with Acknowledge.

3. Update

3.1. Best practices when updating

In this section we describe the best practices that we follow even when updating large Checkmk environments. These are certainly not mandatory in every environment, but they can make the process of updating easier for you.

Update the Checkmk version

Before updating to version 2.3.0, the Checkmk site must have version 2.2.0 installed.

We have previously advised against omitting an intermediate major version when performing a major update, as there are simply too many changes in between that will hinder a smooth update and almost certainly cause problems. With version 2.2.0, this recommendation was turned into a requirement — and a lock was introduced that prevents, for example, a direct update from version 2.0.0 to 2.3.0.

The update to 2.3.0 currently requires at least 2.2.0p8. However, in the future, a specific 2.3.0 patch version may require a higher 2.2.0 patch version for the update. In general, we recommend updating Checkmk to the latest 2.2.0 patch version first, and only then updating to 2.3.0.

Perform a test run of the update

In large environments, where obviously even restoring a current backup of your Checkmk environment could take quite some time, it is recommended to perform a test with a cloned site before updating the production environment. For this purpose, you can, for example, restore the last regular backup of your site under a different name.

root@linux# omd restore newsite /path/to/backup

Alternatively you can also copy your site using omd cp. For this, however, the site must be stopped for a short time:

root@linux# omd stop mysite
root@linux# omd cp mysite newsite

Then, perform the update first on this new cloned site, for example to check the above mentioned local changes in the new environment.

Temporarily disable agent updates

CEE If you are using the automatic agent updates in the commercial editions, you should consider disabling them temporarily before updating Checkmk so as to be able to later switch to the new agents at the hosts in a controlled manner. To do this, first select Setup > Agents > Windows, Linux, Solaris, AIX and on the following page select the menu item Agents > Automatic updates. By clicking on the Icon to edit a list entry. button in front of the Master switch you can disable the agent update completely:

 Disabling agent update using the master switch.

Following a successful update of Checkmk, you can reactivate the agent update in the same way.

At this point, we recommend that you initially only reactivate the automatic agent update for individual hosts or host groups. By doing so, the new agent will not be rolled out to all of your servers right away and you can familiarize yourself with the newly delivered data on a few systems. Also, due to the significant increase in the number of check plug-ins supplied, you might find a whole new set of services that you can then set up properly on the test systems you choose. You may also need new thresholds for new services. If you tackle this on a small scale first, you will be able to minimize unnecessary false positives.

To do this, you can simply enter a few hosts or host groups in the appropriate fields on the above page and then re-enable the Master switch.

Options when updating agents to activate on specific hosts.

Important: Remember to remove these restrictions on explicit hosts and host groups again once you are satisfied with the results.

Temporarily disable notifications

You should also consider turning off notifications in the pre-update site — for similar reasons to the ones we explained in the previous section on automatic agent updates. This way you avoid your colleagues from the monitoring team receiving unnecessary notifications.

You can turn off notifications centrally with the main Notifications switch in the Master control snap-in.

It may will happen that after the update one or another service is CRIT which had not been the case previously. Take care of new problems after the update first. You can also view any 'unhandled' problems, e.g. in the Overview snap-in.

Important: Don’t forget to turn on the notifications again, e.g. when the number of unhandled problems after the update has leveled off to the level before the update.

3.2. Updates in distributed monitoring

There are two different procedures for performing an update of all sites included in a distributed monitoring:

  • Stop all sites, perform the update of all sites in a bulk action, and then restart all sites.

  • Under strict conditions, a mixed operation is possible for a certain period of time, in which the remote sites are updated first, following which version equivalency is restored with the update of the central site.

In particular, if you want to update while the system is running, you should read the notes in the general article on Updates and Upgrades.

3.3. Performing the update

Nothing fundamental has changed with the actual update of the software in Checkmk 2.3.0, i.e. you install the new version, perform the update of the Checkmk site, rectify any possible conflicts and check and confirm the incompatible changes.

Perform the update procedure as described in the article on Updates and Upgrades.

4. Follow-ups

4.1. Changes to the user interface

The Checkmk user interface (GUI), which was completely redesigned with version 2.0.0, has not been changed fundamentally in version 2.3.0. The general procedures, which you are already familiar with from versions 2.0.0 and 2.2.0, can also be used as they are in 2.3.0. However, menus, menu items, icons, and other details have been modified to make new features available — and to improve existing ones.

We will present these changes in this User Guide’s articles — and in the Beginner’s Guide you will find a detailed introduction, including the most important elements of the user interface.

4.2. Updating services

As with every major version, Checkmk 2.3.0 introduces a whole new set of check plug-ins. If you do not use the 'discovery check', i.e. the automatic update of the service configuration via the periodic service discovery, you will have to search for services on quite a number of hosts.

If your hosts are organized accordingly (e.g. in folders), you can generally use the Bulk discovery function for this. This function can be found under Setup > Hosts > Hosts and then in the Hosts > Run bulk service discovery menu.

Service descriptions

Each update of Checkmk will involve changing service descriptions to improve the consistency of naming within the monitoring and documentation of Checkmk. Since changing service descriptions means that rules sometimes need to be modified and historical monitoring data is lost, Checkmk initially leaves the old descriptions in place for updates. For services where the loss of old monitoring data is acceptable and the effort for adapting rules is manageable, you should switch to new service descriptions as soon as possible.

To do this, go to Setup > General > Global settings > Execution of checks and go through the list Use new service descriptions and identify the services where the checkboxes are not yet active and activate them. After applying the changes, the new service descriptions will be active and a few minutes will pass before you see the defined states of the affected services in the monitoring again.

4.3. Certificate check for agent updates

The behavior of the command line parameter --trust-cert of the cmk-update-agent command has been changed. Previously, the entire certificate chain was checked and the highest self-signed certificate found in the hierarchy was trusted; this is usually the root or an intermediate certificate. From Checkmk 2.3.0, only the server certificate is imported and trusted.

Does this affect you? This only affects you if you rely on --trust-cert when registering hosts for automatic agent updates and do not provide an certificate via agent bakery. In this case, from Checkmk 2.3.0 hosts already lose the trust position when the server certificate expires, hosts registered with Checkmk 2.2.0 only when the root or intermediate certificates expire.

What do you need to do? We recommend providing the correct certificates via agent bakery promptly after the update to 2.3.0 and updating all agents to ensure consistent behavior for all hosts that use the Agent Updater.

4.4. Installing Python modules

Does this affect you? This will only apply to you if you have explicitly installed Python modules for special agents or agent-based check plug-ins that you have written yourself or obtained from the Exchange and have removed these in the course of preparing for the update.

What do you need to do? First find out whether the previously uninstalled modules have already been delivered with the new Checkmk version, for example:

OMD[mysite]:~$ pip3 list | grep '^cryptography'

If the module has already been found, mark it as not required in your notes. Install the latest version of any modules that are not included:

OMD[mysite]:~$ pip3 install ecdsa

Then test the check plug-ins or special agents that rely on Python modules installed in the site.

4.5. Network interfaces on Windows

Until Checkmk 2.2.0, the Windows agent relied on the additional plug-in Windows: State and Performance of Network Interfaces to correctly transmit the status of network interfaces. Without the plug-in, the status was always up. As of Checkmk 2.3.0, the agent can transmit the correct status on its own (Werk #15839).

Does this affect you? Depending on the extent to which you have distributed the plug-in and whether you have deactivated the monitoring of the status of network interfaces for hosts without a plug-in, this may affect you. Hosts that have not previously used a plug-in and whose network interfaces were included in the monitoring will change many interfaces from up to down, resulting in the status CRIT and triggering notifications.

What do you need to do? Check whether the status determined for the affected network interfaces is the desired one. Then carry out the service discovery again for the affected hosts. Take the opportunity to first implement the recommendations of the blog article Network monitoring with Checkmk: 3 rules to rule them all, at least for your Windows hosts. For Windows, the above-mentioned settings have to be made in the Network interfaces on Windows rule.

4.6. Synchronize license information

With Checkmk Cloud Edition and Managed Services Edition with distributed setup, license information is sometimes not synchronized to remote sites during the update.

Does this affect you? If you need a complete overview of your license usage immediately after the update, you may be affected. Check the license status and initiate synchronization manually if necessary.

What do you need to do? Under Setup > General > Distributed Monitoring, take a look at the overview of remote sites and search for sites marked with License state: trial. To force an immediate synchronization for these sites, check the license under Setup > Licensing or save the license settings. If this step is forgotten, the license data is usually synchronized in the background within seven days of the update.

5. The outlook

This chapter covers topics not directly related to the current Checkmk version 2.3.0, but to one of its subsequent versions.

5.1. HTTP check in new version

Checkmk 2.3.0 contains a new active check for HTTP connections and certificates, which is significantly better performing, more robust and easier to configure than the previous Check HTTP service. In addition, it is now possible to monitor several things at once with a single rule, for example HTTP response code, response time and certificate validity.

The new Check HTTP web service can be found under Setup > Services > HTTP, TCP, Email, …​ in the Networking box. In the medium term, it will completely replace the old Check HTTP service, which you can find on the same page. For this reason, we recommend that you no longer use the previous check (internal: check_http) when creating new hosts and gradually migrate existing hosts to the new check (internal: check_httpv2).

Migration help will be provided during the lifecycle of Checkmk 2.3.0, but a fully automated migration tends to be difficult because for many hosts rules from two checks need to be merged to benefit from the improved efficiency. Further information can be found in the two Werks #15514 and #15515.

5.2. New check for certificates

The legacy Check HTTP service contained basic functionality for checking certificates and the new Check HTTP web service mentioned in the previous section improves it even further. However, both have a few things in common: First of all, they are just only applicable if a certificate is used at an HTTPS endpoint, and they also lack the option of a detailed examination of the certificates, for example for contained Certificate Subject Alternative Names or the issuing authority.

We have implemented the resulting user requests with the new Check certificates (internal: check_cert). All settings for the new check can also be found under Setup > Services > HTTP, TCP, Email, …​ in the Networking. box.

Further information can be found in the work #15516.

5.3. Programming interfaces

After Checkmk version 2.3.0 only the well-specified APIs for programming check plug-ins, special agents, graphing, etc. will be supported. The changes concern the directory structure, recognition of plug-ins (Discovery instead of Registry) and of course the functions and objects of the APIs themselves. An overview of the biggest changes can be found at Werk #16259.

As the previous APIs are no longer supported from Checkmk 2.4.0, all plug-ins that use the older APIs must be migrated to the new APIs before the update to 2.4.0.

5.4. Improved Microsoft SQL Server Monitoring

A new agent plugin is available for monitoring Microsoft SQL Server with Checkmk 2.3.0. You can find it under Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Microsoft SQL Server (Linux, Windows). This one is implemented in Rust and will replace the previous one written in VBS in the long term. The new plugin runs under Linux and Windows on the x86/64 platform. It also offers increased flexibility through local and remote monitoring under Windows and remote monitoring under Linux. Of course, you can monitor an MS SQL database running locally under Linux using the TCP/IP interface.

The configurability has been significantly improved, so now you can choose which sections are to be checked and add your own SQL statements. Furthermore, you can monitor databases on different hosts using a plugin. To keep this clear, the piggyback mechanism can be used to assign databases to other hosts. All configuration is done via a YAML file. The stable options are available via Bakery rules. Other settings, which we reserve the right to modify, can be configured using the text editor. Details can be found in the Werk #15842.

With the introduction of the new plugin, the deprecation of the previous plugin Microsoft SQL Server (Windows) starts. In Checkmk 2.3.0 you will only receive information about the use of an obsolete ruleset. From 2.4.0 it will no longer be possible to create new rules and with 2.5.0 the previous plugin will probably be removed from Checkmk. Further information can be found at #15844.

5.5. Management Boards

The term Management Board stands for separate plug-in cards or extended BIOS functionality (Baseboard Management Controller/BMC, Management Engine/ME, Lights Out Management/LOM) for monitoring and managing the hardware in addition to the installed operating system.

Up to Checkmk 2.3.0, management boards can be configured in two ways: As a property of a host or as a separate host. As the configurability as a property of a host is very limited, this option will no longer be available in the future. Support for Redfish compatible management boards will be added and improved during the lifecycle of Checkmk 2.3.0, initially as an optional MKP (Werk #16589). We explain additional background information and alternatives in the blog article Monitoring management boards.

5.6. Authentication via GET parameter

Up to Checkmk 2.2.0, every automation user could be logged in with a user name and password passed via GET parameter. This option will be reduced from Checkmk 2.3.0 and eventually removed completely (Werk #16223). In the medium term, you must therefore switch your scripts to authentication via HTTP headers.

First, 2.3.0 makes the option of logging in via GET parameter configurable. However, the global setting Enable automation user authentication via HTTP parameters will initially use enabled as the default. In Checkmk 2.4.0, the default will then change to disabled. Finally, the option of logging in via GET parameter will be completely removed with Checkmk 2.5.0.

5.7. ntopng 5.6 and older are no longer supported

Checkmk 2.3.0 will be the last version to support ntopng in versions 5.x and 6.x (Werk #16483). With Checkmk 2.4.0, support for ntopng 5.x will be discontinued and only ntopng 6.x will be supported. Therefore, update your ntopng installations to 6.x during the lifecycle of Checkmk 2.3.0.

On this page