Checkmk werks level2 February 2024

checkmk-werks-lvl2@lists.checkmk.com

1 participants
4 discussions

[2.4.0] Checkmk Werk 16259 created: New APIs for plugin development

by Checkmk werks level 2

[//]: # (werk v2) # New APIs for plugin development key | value ---------- | --- date | 2024-02-26T21:27:58+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 2 compatible | yes Checkmk 2.3 features new APIs for plugin development. There are three new APIs, and a new version of the agent based API (also known as "Check API"). The replaced APIs will not be supported after 2.3 (details below). Plugin APIs in general provide means to write own code that interacts with the main application using well defined and stable code libraries. While Checkmk has always offered the possibility to add custom plugins, the APIs were often ad-hoc and undocumented. In Checkmk 2.0 we started to address this with the introduction of the agent-based API. With this werk, all important elements of creating your own monitoring plugins are covered by an API. With the APIs we introduce here we clarify what is meant to be used by plugin developers and what are internal modules, which can and likely will change over time and should not be used. This is beneficial for all involved parties: * Checkmk developers can easily figure out what parts of the code can be changed without breaking plugins. We can focus on providing stable APIs while gaining the freedom to rapidly refactor the backend code. * Plugin developers know what features to use to prevent their plugin from unexpectedly breaking during an upgrade, without having to closely follow the changes we make to the code. * Checkmk users can have reliable information on which of their extensions will continue to work after a major upgrade. As a result, the increased transparency leads to a better stability and hence a better user experience on all sides. While the APIs are also intended to be stable, the main focus now is on transparency. All of the APIs have a limited scope, and we have tried to have them feature complete within these limits. However, as the development of Checkmk progresses, we might have to add some features or redesign others. The versioning of the APIs will allow us in these cases to maintain the old version (for a while) and provide documentation on how to migrate to the newer API version. **While we recommend testing the APIs and highly appreciate any feedback: Be aware that during the beta phase incompatible changes to the APIs might occur. Start with a small subset of your plugins to check out the APIs capabilities and limitations. Wait for the stable release before migrating a large amount of plugins to avoid having to make adjustments in all of them.** You can find a detailed technical documentation of the APIs in a running sites "Help" menu, under "Plugin API references". ## Compatibility For all affected plugins (see below) the following migration timeline is supported: For Checkmk 2.3 we tried our best to ensure all plugins will continue working as in 2.2. Note that we can't guarantee all plugins will work for the above reasons. We strongly recommend users migrate to the new APIs during the lifetime of 2.3. With the update to 2.4 all measures to ensure that older plugins still work are dropped, effectively making it extremely unlikely that these plugins will continue to work. ## General changes and common API properties The main changes of these APIs is to reduce side effects when importing the code (for better testablility) and allow for a better component oriented structure: * We move away from the "registry" approach we had in the past, to a discovery based approach. Plugins are instances of specific classes that are created in a certain place with a certain naming scheme. * All plugins (rulesets, check plugins, metrics, ...) of the same "plugin family" can now live in a common folder. A detailed description can be found in the technical documentation mentioned above. Plugins already migrated by us can be found in the [cmk/plugins](https://github.com/Checkmk/checkmk/tree/master/cmk/plugins) folder of the source code. ## Rulesets API: `cmk.rulesets.v1` This is the new API for the creation of rulesets used by the users to configure their plugins. The supported Ruleset types and input form elements can be found in the technical documentation. These are the plugins formally known to sit in your sites `local/share/check_mk/web/plugins/wato`. To be discovered by Checkmk they now have to be in `local/lib/python3/cmk_addons/plugins/<YOUR PLUGIN FAMILY NAME>/rulesets`. ## Graphing API: `cmk.graphing.v1` This is the new API for the creation of objects required for metric visualization, such as perfometers and graphs. The supported metric objects can be found in the technical documentation. These plugins previously where located at `local/share/check_mk/web/plugins/metrics`. To be discovered by Checkmk they now have to be in `local/lib/python3/cmk_addons/plugins/<YOUR PLUGIN FAMILY NAME>/graphing`. ## Server side calls API: `cmk.server_side_calls.v1` This is the new API for plugins that convert a configured ruleset for a special agent or active check to the command line command that is used to run the special agent or active check. Details on the exposed classes and their usage can be found in the technical documentation. These plugins previously where located at `local/share/check_mk/checks`, and filled a `special_agent_info` or `active_check_info` dictionary. To be discovered by Checkmk they now have to be in `local/lib/python3/cmk_addons/plugins/<YOUR PLUGIN FAMILY NAME>/server_side_calls`. ## New version of agent based API: `cmk.agent_based.v2` The new version of the agent based API was mostly added to increase consistency with the other three APIs (discovery mechanism, plugin location). It also features a couple of less important improvements. Details can be found in the technical documentation. These plugins previously where located at `local/lib/check_mk/base/plugins/agent_based`. To be discovered by Checkmk they now have to be in `local/lib/python3/cmk_addons/plugins/<YOUR PLUGIN FAMILY NAME>/agent_based`.

6 months, 1 week

[2.4.0] Checkmk Werk 14223 created: Introduced topology visualization

by Checkmk werks level 2

[//]: # (werk v2) # Introduced topology visualization key | value ---------- | --- date | 2024-02-25T15:22:55+00:00 version | 2.4.0b1 class | feature edition | cee component | multisite level | 2 compatible | yes The topology visualization is a new feature that allows the visualization of complex interconnected networks. A simple example for this visualization is the parent/child topology. The new mechanism that comes with this werk allows the linking of external data with the data of the monitoring core. When it comes to the display, you simply define some starting points via the filter form. Based on these, the topology visualization then builds a mesh of incoming and outgoing connections. The type of external data might be * Netstat, showing connections between the interfaces/ips/ports * LLDP/CDP, showing the network neighbors There is a common data format specification for all external data. So you just can create your own data file which provides information about the relationships between hosts, services or generic objects which are not linked to the core. If you drop this file into a specific folder, the visualization will handle the rest. There is no need to write python code. Right now you can configure * Objects - either linked to an entity in the core or some standalone object * Icons/emblems which should be added to the object * Connections between objects * Line style/color of specific connections Since this is a quite visualization heavy topic and hard to explain only via text, feel free to check out the [thread](https://forum.checkmk.com/t/network-visualization-now-in-version-2-… in our checkmk forum We will also publish a blog article in the coming weeks ``` Important: The visualization only works if external data is provided in a special folder. At the moment these are not created by Checkmk, but come from external MKP developments. ```

6 months, 2 weeks

[2.3.0] Checkmk Werk 15724 created: Change API specification computation

by Checkmk werks level 2

[//]: # (werk v2) # Change API specification computation key | value ---------- | --- date | 2024-02-17T13:24:38+00:00 version | 2.3.0b1 class | fix edition | cre component | rest-api level | 2 compatible | yes The specification of the REST API defines the structure of the API. It is computed automatically from the implementation in Checkmk. Previously the specification was computed during runtime when something requested access to the specification. This could be a user opening ReDoc or the Swagger UI. The specification was then computed ad-hoc and cached in the memory of the apache process. This caused several issues: * After spawning a new apache, the specification needed to be recomputed for every process. This caused a delay in the first request hitting an apache process asking for it. * It was held in memory by every process consuming a few MB. * The invalidation of the cache and computation of new specification could not be triggered manually. With this change the specification is now stored in the site and made available to all apache processes from there. With the dedicated command `cmk-compute-api-spec` the computation can now be triggered in specific situations automatically or manually for debugging. The specification is now updated in these situations: * post-create hook: Create the initial spec after a site has been created * post rename action: Update the spec after a site has been copied, restored or renamed * update-config action: Update the spec after the site has been updated

6 months, 2 weeks

[2.4.0] Checkmk Werk 15724 created: Change API specification computation

by Checkmk werks level 2

[//]: # (werk v2) # Change API specification computation key | value ---------- | --- date | 2024-02-17T13:24:38+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 2 compatible | yes The specification of the REST API defines the structure of the API. It is computed automatically from the implementation in Checkmk. Previously the specification was computed during runtime when something requested access to the specification. This could be a user opening ReDoc or the Swagger UI. The specification was then computed ad-hoc and cached in the memory of the apache process. This caused several issues: * After spawning a new apache, the specification needed to be recomputed for every process. This caused a delay in the first request hitting an apache process asking for it. * It was held in memory by every process consuming a few MB. * The invalidation of the cache and computation of new specification could not be triggered manually. With this change the specification is now stored in the site and made available to all apache processes from there. With the dedicated command `cmk-compute-api-spec` the computation can now be triggered in specific situations automatically or manually for debugging. The specification is now updated in these situations: * post-create hook: Create the initial spec after a site has been created * post rename action: Update the spec after a site has been copied, restored or renamed * update-config action: Update the spec after the site has been updated

6 months, 2 weeks

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2 February 2024