ID: 7445
Title: Historic data views and painters for capacity management
Component: Reporting & Availability
Level: 2
Class: New feature
Version: 1.7.0i1
Capacity management allows you to work with the service metrics historical
data. When configuring a view you can select for a column the "Service
Historic Metrics" option from the drop-down menu, available for the "All
hosts" and "All services" data-sources.
This customizable painter allows you to select, which service metric you
want to analyze, over which time range should data be recovered from your
RRD database, how data is to be consolidated and aggregated. Finally, you
need to label this column to your best convenience.
Some ideas you might want to consider when creating your views:
List all your hosts Peak CPU utilization, over the last week, and also last
month. Maybe you want also to create a new column corresponding to the to
the times a new version of your software was deployed. Time ranges are
completely flexible, and you can keep adding columns for any time window
you prefer.
Analyze over the same time window, the peak, average and minimum CPU
utilization of all your hosts over the last week or last month.
You can also get data from different services at the same time. For example
showing CPU utilization, used memory and disk IO averaged over the last
week.
One last note. Because you will be querying from the RRD data of many hosts
at the same time, query time will increase linearly with the volume of data
you are processing.
ID: 7445
Title: Historic data views and painters for capacity management
Component: Reporting & Availability
Level: 2
Class: New feature
Version: 1.7.0i1
Capacity management allows you to work with the service metrics historical
data. When configuring a view you can select for a column the "Service
Historic Metrics" option from the drop-down menu, available for the "All
hosts" and "All services" data-sources.
This customizable painter allows you to select, which service metric you
want to analyze, over which time range should data be recovered from your
RRD database, how data is to be consolidated and aggregated. Finally, you
need to label this column to your best convenience.
Some ideas you might want to consider when creating your views:
List all your hosts Peak CPU utilization, over the last week, and also last
month. Maybe you want also to create a new column corresponding to the to
the times a new version of your software was deployed. Time ranges are
completely flexible, and you can keep adding columns for any time window
you prefer.
Analyze over the same time window, the peak, average and minimum CPU
utilization of all your hosts over the last week or last month.
You can also get data from different services at the same time. For example
showing CPU utilization, used memory and disk IO averaged over the last
week.
One last note. Because you will be querying from the RRD data of many hosts
at the same time, query time will increase linearly with the volume of data
you are processing.
ID: 7444
Title: Rename metric name in Filesystem checks from mount point to fs_used
Component: Core & setup
Level: 3
Class: Bug fix
Version: 1.7.0i1
Filesystem Nagios check plug-in stored the filesystem usage of every mount
points in the RRD databases under the path of each mount point. Checkmk
assigned to every mount point a service, still it kept naming the
filesystem usage with the mount point path for compatibility. Our graphing
system learned to deal with this unpractical convention, however new
features in Checkmk performing bulk access to data can't.
<ul>
<li>All sites created with Checkm 1.6.0 onwards will automatically use the
new naming convention and don't need to be migrated</li>
<li> The migration is not mandatory, your Checkmk instance will continue
working under the legacy mode until you migrate.</li>
<li>If you use CRE, you don't need to de the migration</li>
<li>If you don't plan to do bulk access to data as required by the Historic
Data Views for filesystems (see Werk #7445), you don't need to migrate your
RRD databases.</li>
<li>If you want to use the Historic Data Views for Capacity Management on
Filesystems, you need to do migration.</li>
</ul>
The incorporation of Historic Data Views, for Capacity Management,
requieres querying the filesystem usage of all host in a given time
window. It becomes prohibitive expensive to do such request since first
every service is queried for its mount point name and then every RRD is
individually queried again for the mount point name data.
In this werk we provide a migration script that would edit all meta data
files describing the RRDs that receive output from all our supported
filesystem checks. It will also set a flag in your config so that
Filesystem check plug-ins start delivering usage perfomance data under the
static name of fs_used.
You are advised to do a backup of your RRD files and journal files before
performing the migration and your Checkmk instance needs to be stopped
during the migration.
Migration is one way and needs to be performed once per site any rollback
has to be done from your own backup.
ID: 7893
Title: systemd_units: filter out disabled services from summary monitoring
Component: Checks & agents
Level: 2
Class: Bug fix
Version: 1.7.0i1
This fix solves the permanent crit status of the systemd summary checkup. Disabled (explicit & implicit) services are now excluded from the summary but still mentioned in the overall message
ID: 8780
Title: mknotifyd: fix race condition in distributed setups
Component: Notifications
Level: 2
Class: Bug fix
Version: 1.7.0i1
In a distributed setup a slave site may try to deliver
notifications locally during an activate changes even
though the slave site should forward notifications to
the master site.
This effect appears when the option "Notification Spooling"
is set to "Asynchronous local delivery by notification
spooler" in the global settings and to "Forward to
remote site by notification spooler" in the "Site specific
global settings" of the slave site.
This werk fixes this issue by locking the Checkmk
configuration when a configuration snapshot is installed
on the remote site. This way the "cmk --notify"
command and the mknotifyd cannot use a partially installed
Checkmk configuration.
As a workaround the "Notification Spooling" can be set to
"Forward to remote site by notification spooler" in the
global settings and to "Asynchronous local delivery by
Notification spooler" in the "Site specific global settings"
of the slave site.
ID: 7967
Title: Fix blocked liveproxy after executing livestatus commands
Component: Livestatus Proxy
Level: 2
Class: Bug fix
Version: 1.7.0i1
The 1.6.0b3 release introduced an regression which made the liveproxyd treat
channels to sites as blocked after executing a livestatus command. When
executing multiple commands this resulted in a busy site and finally GUI
timeouts, because all channels were blocked.
ID: 7262
Title: Initial version of new Business Intelligence visualization
Component: BI
Level: 2
Class: New feature
Version: 1.7.0i1
This werk introduces the initial version of the new business intelligence visualiziation, which was mentioned at our last conference
https://www.youtube.com/watch?v=zYfIBJkbKxA
You can navigate to the new visualization through an icon, which is shown in the classical view.
The new visualization enables you to view aggregations in a different perspective.
A more elaborate documentation will be provided later on. Some first notes.
You can create layout templates for a group of aggregations. These templates can be assigned in the aggregation configuration.
You can also specifically assign a layout to one aggregation.
ID: 7429
Title: pushover: fix broken error handling
Component: Notifications
Level: 2
Class: Bug fix
Version: 1.7.0i1
Since its introduction in version 1.2.8 the error handling of the
pushover notification script is broken. Notifications were always
handled as successful even if the Pushover API returned an error.
Version 1.5.0 introduced another bug that printed an error
message to the notify.log for successful notifications.
ID: 7769
Title: Fix broken computation of host contact groups in some cases
Component: Core & setup
Level: 2
Class: Bug fix
Version: 1.7.0i1
The core config creation was broken in 1.6.0b1 when using the WATO
folder hierarchy for assigning contact groups to hosts.
An exception like this was displayed after the update or later, e.g.
when executing <tt>cmk -U</tt> to update the core configuration:
C+:
File "/omd/sites/produktiv/lib/python/cmk_base/cee/core_cmc.py", line 457, in cmc_all_hosts
cmc_hosts = CMCHosts(config_cache.all_active_hosts(), CMCHostConfig)
File "/omd/sites/produktiv/lib/python/cmk_base/cee/core_cmc.py", line 501, in __init__
self._compute(hostnames, host_class)
File "/omd/sites/produktiv/lib/python/cmk_base/cee/core_cmc.py", line 513, in _compute
host_config = host_class(hostname)
File "/omd/sites/produktiv/lib/python/cmk_base/cee/core_cmc.py", line 962, in __init__
super(CMCHostConfig, self).__init__(hostname)
File "/omd/sites/produktiv/lib/python/cmk_base/cee/core_cmc.py", line 753, in __init__
self._host_contact_groups = self._host_config.contactgroups
File "/omd/sites/produktiv/lib/python/cmk_base/config.py", line 2471,
in contactgroups
return list(set(cgrs))
TypeError: unhashable type: 'list'
C-:
ID: 7711
Title: New Windows Agent
Component: Checks & agents
Level: 2
Class: New feature
Version: 1.7.0i1
This release introduces New Windows Agent
Important Notes:
The Location of the New Agent is "Program Files(x86)\check_mk_service"
The Name of Service is "checkmkservice"
The Log files is located in the "/Users/Public"
New Agent doesn't support Windows XP or Windows 2003
User Data for New Agent, like plugins and configurations are in the /ProgramData/CheckMK/Agent
Configuration file is check_mk.user.yml, located in /ProgramData/CheckMK/Agent
New Agent can re-use configuration and plugins of the Legacy Windows Agent