With Checkmk 2.0, we are also pushing the automation of Checkmk further and at the same time making it easier to develop your own plug-ins for monitoring with Checkmk. The new Check API will make it easier for users to develop and maintain their own plug-ins. The REST API, which is also new, is additionally intended to improve the automation options. It already includes large parts of the various current APIs, but now also allows automation of your monitoring operations. But the Agent Bakery will also receive new functions with the new product version.

The new Check API simplifies the development of your own plug-ins

In future, the development of check plug-ins will become much easier. This was necessary as the existing plug-in API had grown and was also not the result of a top-down design. This has repeatedly led to problems during development, as inconsistencies have arisen in detail and it has required implicit knowledge.

For this reason we decided to develop a new Check API from scratch. A reference to the version currently in use can be viewed in the Checkmk interface. An accompanying manual article should also make it easier to get started programming with the new Check API.

As of Checkmk 2.0, the check plug-ins are now Python 3 modules, and the import of these plug-ins is also versioned and precisely defined by the API. This should make it easier for users to write plug-ins, to perform separate checks, to use Python IDEs and to test their own code. In addition, the new API comes with many other smaller improvements, including cluster compatibility, for example.

Due to the change from Python 2 to Python 3, we recommend checking plug-ins code you have programmed yourself. While the Checkmk internal auto-migration to the new API should work without problems in most cases, you may need to adjust your plug-in in rare cases. In the Werk #10601, you can look up possible reasons for auto-migration failure. You can also find detailed instructions for migration plug-ins to the new Check API in our blog.

Automating the configuration & operation of Checkmk

To further automate monitoring with Checkmk, we have also developed a new REST API that will significantly simplify the automated configuration and operation of Checkmk.

In developing the new REST API, we used tried and tested methods. For example, the interface is based on HTTP/1.1 and JSON as the transport format, it is formalized with the OpenAPI 3.x specification, it is based on Level 3 of the Richardson Maturity Model and it includes automated documentation.

Furthermore, the new REST API offers more functionality than the previously APIs by enabling, for example querying of host and service status or doing operational tasks, such as problem acknowledgement for individual services or all hosts of a host group, among others. The creation of planned downtimes can also be easily implemented with the new API. Also possible now is the complete configuration and querying of Checkmk's Business Intelligence.

In many aspects the REST API already includes significantly more functionality than the existing APIs. That said, for the moment it does not represent the complete functionality of the existing APIs yet. Our goal, however, is to completely replace the current APIs with the REST API as soon as it can provide all of the current API's functionality.

Read more about the new REST API in our documentation.

Upgrades for the Agent Bakery

The Agent Bakery in the Checkmk Enterprise Edition will also receive new functions and usability improvements with the introduction of Checkmk 2.0. The frequent baking and signing of agents can be done with a single action in the new version. The Bakery also knows more precisely which packages it needs to bake again and can thus speed up the creation process. In addition, it now supports locally customized plug-ins and can reliably detect changes to data. Another new feature is that the Bakery automatically bakes packages for new hosts - although not yet with a signature.

We have also optimized the Bakery's workflow in globally distributed or in strictly segmented environments. Now the Bakery is able to distribute agents from remote sites. This means that the agent updaters no longer all communicate with the central site, but only with their responsible remote site, thus saving bandwidth. However, the configuration for baked agents remains on the central site.

Likewise, in addition to the Check API, we have also developed the Bakery API to simplify the building of Bakery plug-ins. The Bakery now offers freedom of choice by configuration the use of either systemd or xinetd for the Linux agent. It can thus be more responsive to the system being monitored, depending on the daemon used, and can also detect whether Python 2 or Python 3 is available.

More information about Checkmk 2.0

For deeper insights into the many changes and features Checkmk 2.0 has in store, read one of our blog posts on a specific topic:

You can also find more information about Checkmk 2.0 in the Checkmk forum in our documentation or on our YouTube channel.


Related Articles

How to monitor servers with broken TLS in Checkmk 2.3
How to monitor servers with broken TLS in Checkmk 2.3
With Checkmk 2.3.0 we bumped the version of OpenSSL from 1.1 to 3.0. This means much stricter defaults regarding security relevant ciphers, handshake…
These operating systems are supported by Checkmk
These operating systems are supported by Checkmk
More reliability in planning future updates of Checkmk was a major reason why we introduced a policy with Checkmk 2.0 regarding which operating…
Deploy and run Checkmk in your Azure or AWS tenant
Deploy and run Checkmk in your Azure or AWS tenant
Starting today, the Cloud Edition is available on the AWS and Azure Marketplaces as an AMI and Virtual Machine, respectively. These pre-configured and…