[//]: # (werk v2)
# mk_redis: Fix for Werk #16329
key | value
---------- | ---
date | 2024-02-21T10:40:17+00:00
version | 2.3.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
With werk #16329 when a password was set, the plugin did not work.
This has now been fixed and configuring a password shouldn't cause any issues.
[//]: # (werk v2)
# downtimes: Added service_description field to services downtimes
key | value
---------- | ---
date | 2024-02-20T14:52:12+00:00
version | 2.3.0b1
class | feature
edition | cre
component | rest-api
level | 1
compatible | yes
When querying downtimes through the "show all downtimes" endpoint, the service_description field for service downtimes was not included. This werk introduces this field, which is not present in the host downtimes.
Werk 16493 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# netapp_ontap_snapvault: improves lagtime calculation
key | value
---------- | ---
date | 2024-02-16T09:39:38+00:00
version | 2.3.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# netapp_ontap_snapvault: improves lagtime calculation
key | value
---------- | ---
date | 2024-02-16T09:39:38+00:00
version | 2.3.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
- With this new type of calculation, since we don't have a reference for when this lagtime started or ended,
- we always consider a month to be made up of 30 days.
[//]: # (werk v2)
# aws: Add total reservation utilization service
key | value
---------- | ---
date | 2024-02-14T09:35:02+00:00
version | 2.3.0b1
class | feature
edition | cre
component | checks
level | 1
compatible | yes
This werk adds a service to monitor the total utilization of
reserved resources analogous to the reservation utilization graph
in the AWS cost explorer.
This service is discovered as soon as the AWS agent rule to monitor
costs and usage (CE) is enabled.
[//]: # (werk v2)
# netapp_ontap_snapvault: improves lagtime calculation
key | value
---------- | ---
date | 2024-02-16T09:39:38+00:00
version | 2.3.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
With this new type of calculation, since we don't have a reference for when this lagtime started or ended,
we always consider a month to be made up of 30 days.
[//]: # (werk v2)
# comment: site_id only required when deleting comments by id
key | value
---------- | ---
date | 2024-02-19T17:24:03+00:00
version | 2.3.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
When deleting a comment via the REST-API, only the 'by_id' option
leaves the comment selection ambiguous, while the options 'params'
or 'query' already have the ability to pinpoint the comment
requested. Therefore, the site_id should is not required in these
cases.
[//]: # (werk v2)
# event_console: site_id only required when deleting ec events by_id
key | value
---------- | ---
date | 2024-02-20T06:46:32+00:00
version | 2.3.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
When deleting an ec event via the REST-API, only the 'by_id' option
leaves the event selection ambiguous, while the options 'params'
or 'query' already have the ability to pinpoint the event
requested. Therefore, the site_id should is not required in these
cases.
[//]: # (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