ID: 10291
Title: New Checkmk REST-API introduced
Component: Core & setup
Level: 3
Class: New feature
Version: 2.0.0i1
With the Checkmk REST-API you can execute tasks you would normally perform manually in Checkmk's GUI
on the Checkmk server via custom made scripts.
REST stands for REpresentational State Transfer and describes an architecture for the exchange of
data on distributed systems - especially for Web services. The implementation of this REST-API is
done via the HTTP/1.1 protocol, where resources are addressed via URIs and accessed with HTTP
methods (GET, PUT, POST, DELETE).
The API is documented in a machine-readable schema and a human-readable document in English, with
all resources, their input and output parameters and the associated value ranges. The API is
specified in the OpenAPI 3.x specification format.
The documentation for the API can be accessed in Checkmk's GUI under "Navigation > Help > REST-API
Documentation". The specification file can be downloaded by clicking on the "Download OpenAPI
Specification" button at the top of the documentation.
A chapter in the Checkmk Manual specific to the REST-API is currently being created and will be
ready for the 2.0.0 release.
ID: 11500
Title: Microcore: Improved memory efficiency of helper processes
Component: Core & setup
Level: 3
Class: New feature
Version: 2.0.0i1
In previous versions the Checkmk Microcore used so called Checkmk helper
processes to execute the "Check_MK" services of the monitored hosts.
In larger installations, these processes consumed a lot of memory, because a)
they held the Checkmk configuration in memory and b) you needed to configure a
lot of them to scale the performance of your monitoring with the growing number
of hosts. This resulted in a resource bottleneck.
Checkmk 2.0 comes with a completely reworked helper model. This introduces two
kinds of helper processes.
<ul>
<li>Fetcher: It's only task is to fetch the needed information from the
monitored hosts. So it handles the network communication with the Checkmk
agent, SNMP agent or other special agents. It may take some time to gather
these information and it also may be blocked by network timeouts. But it
consumes only a small amount of memory. So you can configure a lot of these
processes without problems.</li>
<li>Checker: It's task is to parse, analyze and evaluate the information
gathered by the fetcher. It produces the check results for your services. It is
a memory hungry process, because it needs to know all of your Checkmk
configuration. It only takes a very short time to process the information from
the fetcher. There is no network IO done by this helper process, which makes it
pretty fast. You only need a small number of these processes.</li>
</ul>
This new model separates the problems of the previous "Checkmk helpers" into
two separate pools: a) The network IO bound fetching of information and b) the
CPU bound checking of the fetched information. We can now scale these different
helper types independently from each other.
Bottom line: Checkmk 2.0 has consumes significantly less memory (~ factor of 4,
depending on your configuration) while achieving the same amount of checks per
second. As a result, Checkmk 2.0 can monitor even more hosts on the same
platform than before.
The new model is enabled with Checkmk 2.0 by default. It can be configured
using the global settings "Use separate fetchers and checkers", "Maximum
concurrent Checkmk fetchers", "Maximum concurrent Checkmk checkers".
All sites start with 13 fetcher processes and 4 checker processes.
After updating you should have a look at the "Fetcher helper usage" and
"Checker helper usage". It can be viewed in the "Micro core statistics" snapin
and the detailed output of the "OMD [SITE] performance" services on your
Checkmk host. The usage of both pools should not exceed 80%. In case it does,
you should consider increasing the number of helpers of that type.
ID: 11401
Title: New Bakery API
Component: agents
Level: 3
Class: New feature
Version: 2.0.0i1
It is now possible to extend Checkmk by writing your own bakery plugins.
That is, you can now deploy your own agent plugins and have them baked into
your agents by the agent bakery.
While this was also possible before by placing the right files at the right
locations, you can now deploy your plugins with the help of a well-documented,
versioned and comprehensive API. A bakery plugin is a Python 3 module that specifies
files that should be deployed to the baked agents, scriptlets that should be
executed on the target system (RPM scriplets, DEB maintainer scripts, Solaris PKG
installation scripts) on package transition, and Windows agent config entries (YAML config)
that should be available for the baked windows agents.
You can add your own bakery plugins by placing them at
<code>~/local/lib/check_mk/base/cee/plugins/bakery/</code>. For instructions and details
on how to use the new API, please refer to the official Checkmk documentation. With Checkmk 2.0,
also the majority of the builtin bakery plugins have been migrated to the new Bakery API, so
having a look at them at <code>~/lib/check_mk/base/cee/plugins/bakery/</code>
can also help to write your own plugins.
If you have deployed your bakery plugins to Checkmk before, using the previous method
of placing a plugin file to <code>~/local/share/check_mk/agents/bakery/</code>, your plugins
will continue to work with Checkmk 2.0, if you convert them to Python 3 syntax. However,
the Agent Bakery will display a deprecation warning on baking agents (visible at the
bake-agents background job details at the GUI, or on the console if baking via command line),
and the support for legacy bakery plugins will be removed in an upcoming version of Checkmk,
so it's worth it to migrate your plugins to the new API early.
