ID: 11515
Title: prism_containers: Fix evaluation of percentage levels and scale of levels in graphs
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.0.0i1
Levels for the usage regarding the capacity can be set absolute or in percent.
The percentage levels did not apply correctly. Also the warn and crit values
were not displayed correct in the related graphs.
ID: 11427
Title: WATO: Improved performance on host lookup on various pages
Component: WATO
Level: 1
Class: New feature
Version: 2.0.0i1
Bigger installations (>200k services) tend to have a large WATO configuration with thousands of folders and hosts.
Finding a host in these configuration took a considerable amount of time on some pages
<ul>
<li>Web API host calls, except add_host</li>
<li>Bulk discovery</li>
<li>Host diagnose</li>
<li>Fetching agent output</li>
<li>Service discovery</li>
<li>And some other pages, where the actual folder of the host is not known/specified</li>
<li></li>
</ul>
To fix this problem, a folder lookup index has been introduced to improve the time taken to find a hostname in the configuration.
ID: 11501
Title: Fix possible XSS using titles of views
Component: Multisite
Level: 1
Class: Security fix
Version: 2.0.0i1
Authenticated users that are allowed to configure and share custom views
could inject arbitrary JS code to all users which are permitted to view this
view.
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: 11405
Title: Improved performance of agent bakery
Component: agents
Level: 1
Class: New feature
Version: 2.0.0i1
With the introduction of the new Bakery API (see Werk #11401), the
Agent Bakery itself has undergone a complete overhaul.
While baking agents, the agent bakery now tries to reuse as many
resources as possible, instead of collecting data for every
package separately. If the contents for a to-be-baked package are
identical to an already-baked one, this optimization will be communicated
as "fast repackage" (visible at the bake-agents background
job within the GUI or at the console directly when baking on the command
line).
Furthermore, the packaging processes for RPM and DEB packages have been
optimized in performance.
In summary, you will experience an agent bakery that runs noticeably
faster and finishes earlier, compared to Checkmk 1.6 and before.
ID: 11331
Title: heartbeat_crm: fixed crash when checking pacemaker version 2.0.3
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.0.0i1
The check heartbeat_crm crashed when checking pacemaker version 2.0.3 (CentOS8
/ RHEL8). This has been fixed.
ID: 11404
Title: Better detection of changes in baked agent packages
Component: agents
Level: 1
Class: New feature
Version: 2.0.0i1
Previously, the only property that has been observed by the agent bakery to decide whether
to bake new agents, was the WATO agent configuration. This sometimes lead to problems when
deploying your own plugins, because changes in agent plugin files won't get recognized and
hence no new agent would get baked. Furthermore, if you managed to force-bake the agents,
including the file changes, the config hash would still stay the same, hence the agent updater
would refuse to deploy the new package to the hosts.
The agent bakery will now recognize changes in every file that gets deployed to the configured
agent packages and reflect them in generating a different agent hash on baking agents. This is
also true for files that get superceded by their counterpart at the local hierarchy, see Werk #10975.
Similar to a config change, changes in underlying files will lead to a highlighted "Bake agents"
button at the agent bakery.
Please note that this mechanism will only work work bakery plugins that are specified via
the new Bakery API, see Werk #11401. This includes all builtin bakery plugins. E.g., if you
decide to adapt the Checkmk linux agent (copy an adapted version to the local hierarchy),
your changes will get recognized.