ID: 11021
Title: Fixed validation of regex filter
Component: Multisite
Level: 1
Class: Bug fix
Version: 1.7.0i1
If you use invalid regex or lookaheads in views filter like "service", this
could lead to timeouts and the possibility that you can not edit the view any
more.
Instead of that you will now get a message, that this input is not valid.
If you already have configured such regex it is possible, that you have to
adjust it.
ID: 10962
Title: Bugfix for AWS monitoring (conversion Sum --> rates)
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 1.7.0i1
This werk fixes a bug which affected the conversion of AWS
Cloudwatch metrics with a statistics of type "Sum" into rates.
Without this fix, the computed rates are too high by a factor
of 10. Affected checks:
- aws_elb.http_elb
- aws_elb.http_backend
- aws_elb.backend_connection_errors
- aws_elbv2_application.http_elb
- aws_elbv2_application_target_groups_http
- aws_elbv2_application_target_groups_lambda
- aws_s3_requests
- aws_s3_requests.http_errors
Note that only the absolute values were affected, no the
computed percentages (if any).
ID: 10961
Title: Monitoring of AWS DynamoDB tables
Component: Checks & agents
Level: 1
Class: New feature
Version: 1.7.0i1
This werk introduces monitoring of AWS DynamoDB tables. The
monitoring includes overall limits for AWS DynamoDB (both
account-wide and per-table limits on Read and Write Capacity
Units) and a summary of all tables. Furthermore, we also
monitor read and write capacities as well as latencies on a
per-table basis. To make use of this werk, you have to
configure the related AWS special agent to monitor Dynamo
DB.
ID: 10962
Title: Bugfix for AWS monitoring (conversion Sum --> rates)
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 1.7.0i1
This werk fixes a bug which affected the conversion of AWS
Cloudwatch metrics with a statistics of type "Sum" into rates.
Without this fix, the computed rates are too high by a factor
of 10. Affected checks:
- aws_elb.http_elb
- aws_elb.http_backend
- aws_elb.backend_connection_errors
- aws_elbv2_application.http_elb
- aws_elbv2_application_target_groups_http
- aws_elbv2_application_target_groups_lambda
- aws_s3_requests
- aws_s3_requests.http_errors
Note that only the absolute values were affected, no the
computed percentages (if any).
ID: 10778
Title: Cisco CPU checks: relax SNMP scan function
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 1.7.0i1
The Cisco CPU checks discovery ordering from Werk 7458 is revisited.
There are four Cisco CPU checks: cisco_cpu, cisco_cpu_multiitem, cisco_nexus_cpu, cisco_oldcpu. We discover the Cisco CPU utilization services in the following order:
- if it's a Nexus device the cisco_nexus_cpu check is used
- if the device contains the SNMP table .1.3.6.1.4.1.9.9.109.1.1.1.1.2.* then cisco_cpu_multiitem is used
- if the device either the OID .1.3.6.1.4.1.9.9.109.1.1.1.1.8.1 or
.1.3.6.1.4.1.9.9.109.1.1.1.1.5.1 then cisco_cpu. This acts now as a
fallback and is not strict about verifying device not belonging to cisco
nexus family. This as a relaxed condition to werk 5748.
- if .1.3.6.1.4.1.9.2.1.57.0 exists then cisco_oldcpu is used
There may be Cisco hosts which have discovered the 'wrong' check type. After a re-discovery the CPU check type may change.
ID: 10601
Title: Auto migration of check plugins to new section definitions
Component: Checks & agents
Level: 2
Class: New feature
Version: 1.7.0i1
We are now converting all plugins to the new format expected by
the future API. Migrated are plugins from
<ul>
<li>share/check_mk/checks</li>
<li>local/share/check_mk/checks</li>
<li>share/check_mk/inventory</li>
<li>local/share/check_mk/inventory</li>
</ul>
Although we are trying to migrate as many check and inventory plugins
as possible on the fly, for some plugins this may fail.
These are the anticipated reasons why auto-migration may fail:
<h4>A cluster aware checkplugin</h4>
Checkmk refuses to auto-migrate cluster aware (those with node_info
set to True) check plugins. Auto converting the data layout
is too error prone. These plugins must be migrated manually.
<h4>Checkplugins using 'extra_sections'</h4>
Checkmk refuses to auto-migrate check plugins that make use of the
'extra_sections' feature. In the new API the destiction between the
regular section and additional 'extra_sections' is not made, and all
section content will be passed in its 'parsed' version.
Therefore these Plugins have to be migrated manually.
<h4>A missing SNMP scan function</h4>
Every Checkplugin that specifies an 'snmp_info' key must
specify 'snmp_scan_function' as well.
<h4>A complex SNMP scan function</h4>
If Checkmk fails to auto-migrate a legacy SNMP plugin to a section
definition, this is most likely due to an elaborate scan function.
For the auto-migration to work, the scan function must be fairly
simple. Make sure your scan function has the following properties:
<ul>
<li>it only consists of one single return statement</li>
<li>it does not in turn call other functions (not even 'all' or 'any')</li>
<li>it does not negate compound expressions</li>
</ul>
If in doubt, take a look at scan functions that succeed to be migrated
to see what options are available.
<h4> Known limitations</h4>
<ul>
<li>HostLabels that are generated in a subchecks discovery function are lost</li>
</ul>
ID: 11020
Title: Quicksearch: Validate if search string contains lookahead
Component: Multisite
Level: 1
Class: Bug fix
Version: 1.7.0i1
If you enter a string containing lookaheads like "foo(?!bar)" you get a
livestatus error like "Unhandled exception: 400: Filter: invalid perl operator:
(?!".
This has been fixed. You will now get a message within the quicksearch,
that this input is not valid.
ID: 10960
Title: Monitoring of target group errors for AWS Application Load Balancers
Component: Checks & agents
Level: 1
Class: New feature
Version: 1.7.0i1
This werk adds two additional checks for Application Load Balancers. For
each registered target group, one additional service is created. For target
groups of type "instance" or type "ip", this service monitors the number
of HTTP 2XX, 3XX, 4XX and 5XX errors produced by the respective target
group. For target groups of type "lambda", the service monitors the number
of Lambda user errors. There are no default upper levels, but they can
be configured using the WATO rule "AWS/ELBApplication target errors".