[//]: # (werk v2)
# check_httpv2: Introduce a reworked way to test web sites
key | value
---------- | ---
date | 2024-03-08T10:06:58+00:00
version | 2.3.0b3
class | feature
edition | cre
component | checks
level | 2
compatible | no
The legacy http monitoring plugin caused quite some trouble over the last
years. This included lots of effort to add features or just simply fixing
bugs.
With the new plugin, the functionality is moved to maintainable and
extendable code completely under control of Checkmk. This means also
breaking changes with the old plugin:
* Some metrics are not available anymore as it has been known. We
discovered that these are simply not directly understandable. Instead we
will add metrics as needed in the future. Some metrics will already be
added in this first release
* Some functionality has been a workaround and is now implemented directly
into the new plugin. This makes it hard to migrate rules automatically.
* Users are now able to decide on their own which functionality should be
in an own service. This means, that it is now possible to test the
certificate validity and response times in one service, if needed.
* User are able to configure multiple http checks within one rule. You can
provide standard settings to be used for all endpoints, and overwrite
them per entry for each endpoint. Migrating manually makes absolute
sense here.
Please note that we will not remove the old plugin for now. We understand
that you need some time to migrate your configurations. Nethertheless, we
will deprecate the old plugin and eventually remove it from Checkmk.
[//]: # (werk v2)
# omd update: Allow Aborting Before "Completed verifying site configuration."
key | value
---------- | ---
date | 2024-03-07T13:47:39+00:00
version | 2.3.0b2
class | fix
edition | cre
component | omd
level | 2
compatible | yes
Sites may have configuration, MKPs and other local files, which are incompatible with the version
targeted by `omd update`. If such a problem occurs, then aborting the update may be necessary. In
earlier versions, users were advised to perform a downgrade, which was not user-friendly and had
several pitfalls. Downgrading is not supported as it has many potential downsides. With this Werk,
`omd update` is better able to deal with these situations. `omd update` will show the message
```
Completed verifying site configuration. Your site now has version {target version}.
```
If the update is aborted before this message is shown, then the site is restored to it's previous
state. This includes selecting the `abort` option, unexpected internal errors, or aborting the
update using CTRL-C.
[//]: # (werk v2)
# cmk-update-config: Don't Prompt User if Using Conflict Mode "install" or "keepold"
key | value
---------- | ---
date | 2024-03-07T13:04:36+00:00
version | 2.3.0b2
class | fix
edition | cre
component | omd
level | 2
compatible | yes
While upgrading with `cmk-update-config`, the user can be prompted with questions about the next
update steps. This questioning can be disabled by using one of the conflict options `install`,
`keepold` or `abort`. Due to a regression in the 2.3.0b1 the options `install` and `keepold` do not
supress these questions. In particular, if there is a problem while `Verifying the Checkmk
configuration...`, then the update of Checkmk on Checkmk appliances will exit with a traceback.
Upgrading to the 2.3.0b1 is thus only possible here, if all problems are fixed beforehand.
Werk 15839 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Connection state of interface on Windows is supported out-of-the-box
key | value
---------- | ---
date | 2024-02-22T08:27:57+00:00
version | 2.3.0b1
class | feature
edition | cre
component | checks
level | 2
compatible | yes
Previously, users were required to install an additional plugin to
determine the state of a network interface on Windows.
With the current release, this functionality is now integrated directly into the
Windows agent, eliminating the need for extra plugins.
For enhanced consistency across operating systems, network interfaces that are
operational are now marked as `up`, and those that are not available are marked
as `down`, aligning with the terminology used on Linux.
This change may lead to critical alerts with interfaces correctly reported as
`down`, which have been in that state for a long time but were previously
erroneously reported as `Connected`.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Connection state of interface on Windows is supported out-of-the-box
key | value
---------- | ---
date | 2024-02-22T08:27:57+00:00
version | 2.3.0b1
class | feature
edition | cre
component | checks
level | 2
compatible | yes
Previously, users were required to install an additional plugin to
determine the state of a network interface on Windows.
With the current release, this functionality is now integrated directly into the
Windows agent, eliminating the need for extra plugins.
For enhanced consistency across operating systems, network interfaces that are
operational are now marked as `up`, and those that are not available are marked
as `down`, aligning with the terminology used on Linux.
+ This change may lead to critical alerts with interfaces correctly reported as
+ `down`, which have been in that state for a long time but were previously
+ erroneously reported as `Connected`.
+
+
[//]: # (werk v2)
# New APIs for plugin development
key | value
---------- | ---
date | 2024-02-26T21:27:58+00:00
version | 2.3.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`.
[//]: # (werk v2)
# Connection state of interface on Windows is supported out-of-the-box
key | value
---------- | ---
date | 2024-02-22T08:27:57+00:00
version | 2.3.0b1
class | feature
edition | cre
component | checks
level | 2
compatible | yes
Previously, users were required to install an additional plugin to
determine the state of a network interface on Windows.
With the current release, this functionality is now integrated directly into the
Windows agent, eliminating the need for extra plugins.
For enhanced consistency across operating systems, network interfaces that are
operational are now marked as `up`, and those that are not available are marked
as `down`, aligning with the terminology used on Linux.
[//]: # (werk v2)
# Introduced topology visualization
key | value
---------- | ---
date | 2024-02-25T15:22:55+00:00
version | 2.3.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.
```
[//]: # (werk v2)
# Fix performance issues when processing performance data (process_perfdata.pl) and missing metric data
key | value
---------- | ---
date | 2024-05-22T13:57:02+00:00
version | 2.4.0b1
class | fix
edition | cre
component | omd
level | 3
compatible | yes
This werk affects all users of Checkmk Raw.
You might have perceived a severe performance degradation in Checkmk 2.3.0 and a lot of errors in
the NPCD log. This was due to missing RRD packages and thus expensive fall-back computations.
This werk fixes a performance issue in combination with potentially missing metric data, which can
result in gaps in the service graphs.
[//]: # (werk v2)
# Microsoft SQL Server (Windows) ruleset is deprecated
key | value
---------- | ---
date | 2024-04-17T13:40:06+00:00
version | 2.3.0b6
class | feature
edition | cre
component | checks
level | 2
compatible | no
We've introduced a new `Microsoft SQL Server (Linux, Windows)` plug-in for MS SQL
database monitoring, see
[werk 15842: Enhanced MS SQL Server monitoring](https://checkmk.com/werk/15842).
The new plugin extends the functionality of `Microsoft SQL Server (Windows)`
by adding more options and features.
We recommend that you upgrade to the `Microsoft SQL Server (Linux, Windows)` plug-in to monitor MS SQL databases. This new agent plugin can be deployed
alongside the Checkmk agent on your database systems, just like the previous
plugin. You can also use this plugin on any Windows or Linux
server to monitor remote MSSQL servers over the network.
The previous `Microsoft SQL Server (Windows)` rule set is deprecated and renamed to `Microsoft SQL Server (deprecated)`. Please note that you may need to adjust settings on your databases or continue running the old plug-in for the time being, as the agent plug-in cannot connect to local database instances that are not available over a TCP/IP connection.
[//]: # (werk v2)
# Enhanced MS SQL Server monitoring
key | value
---------- | ---
date | 2024-04-03T07:47:56+00:00
version | 2.3.0b4
class | feature
edition | cre
component | checks
level | 2
compatible | yes
With this release MS SQL Server is monitored using new plugin and new GUI.
The old plugin is still supported but are considered deprecated.
Key Enhancements out-of-the-box:
- Configuration flexibility: The plugin can be configured through a YAML config file for any edition and/or a graphical user interface (GUI) for enterprise edition or better.
- Cross platform: The plugin can be deployed on Linux and Windows.
- Enhanced monitoring capabilities: Supports monitoring of remote databases on both Linux and Windows hosts, in addition to local monitoring on Windows hosts.
- Customizable monitoring sections: Sections are now selectable and configurable
- Customizable SQL statements: you may change SQL statement either manually(place file in `mssql` sub directory in config dir) or using `Custom files` rule in GUI.
- Multi-instance support: Enables the selection of different instances for monitoring. Every instance can be configured separately
- Multi-host support: possible to monitor databases on various hosts using one deployed plugin.
- Security enhancements: Limited support for certificates is now available.
- Asynchronous operation: Any section with exception `instances` can be set up for asynchronous operation.
- Piggyback: It's possible to direct the output of a plugin to a different host, rather than to the host that retrieves the data.
- Other improvements:
- Automatic detection of instances is possible for any Windows host, local and remote, depending on SQL Server Setup.
- Full logging support including rotation and file limits
- Limit for maximal connection counts
- Cache time and timeout can be configured too
With regard to the old plug-in, there are also a few restrictions at the moment:
- The database instances must be accessible via TCP/IP.
- If several databases are running on a system, each using their own IP addresses, these must be explicitly specified in the configuration of the agent plug-in, as the addresses and ports are currently not yet found automatically.