Checkmk git commits June 2018

checkmk-commits@lists.checkmk.com

10 participants
179 discussions

by Andreas Umbreit

Module: check_mk Branch: master Commit: cd583fd181efac117875c5ca889012267ff0a635 URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=cd583fd181efac… Author: Andreas Umbreit <au(a)mathias-kettner.de> Date: Thu May 17 13:35:20 2018 +0200 CMK-538: Add Werk 5498 5498 Allow multiple folders in Agent Bakery Host selection Change-Id: I036f7585f6d5135125d7693ecb4417bf5bd9ae9d --- .werks/5498 | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/.werks/5498 b/.werks/5498 new file mode 100644 index 0000000..f94ffb3 --- /dev/null +++ b/.werks/5498 @@ -0,0 +1,11 @@ +Title: Allow multiple folders in Agent Bakery Host selection +Level: 1 +Component: agents +Compatible: compat +Edition: cee +Version: 1.6.0i1 +Date: 1526556867 +Class: feature + +Previously, only one WATO-folder could be selected as a filter to enable agent deployment for specific hosts. +This selection has now been extended to an arbitrary number of WATO-folders.

6 years

Fixed typo in check manpage of hitachi hus

by Marcel Arentz

Module: check_mk Branch: master Commit: 77c56dbc4381f5f014df15f1484a100026e8ad53 URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=77c56dbc4381f5… Author: Marcel Arentz <ma(a)mathias-kettner.de> Date: Fri Jun 15 09:02:08 2018 +0200 Fixed typo in check manpage of hitachi hus Change-Id: I675e508b17f00a77c9df31d8af090416e9cbbd24 --- checkman/hitachi_hus_dkc | 2 +- checkman/hitachi_hus_dku | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/checkman/hitachi_hus_dkc b/checkman/hitachi_hus_dkc index 0eae573..9d940b9 100644 --- a/checkman/hitachi_hus_dkc +++ b/checkman/hitachi_hus_dkc @@ -7,7 +7,7 @@ description: This check monitors the state of various hardware components of Hitachi Unified Storage Disk Controller Chassis (HUS DKC), which are part of an - Hitache Unified Storage VM System. The check uses SNMP and the USPMIB to + Hitachi Unified Storage VM System. The check uses SNMP and the USPMIB to extract state information of the following hardware components of the DKC: Processor, Internal Bus, Cache, Shared Memory, Power Supply, Battery, Fan, Environment. diff --git a/checkman/hitachi_hus_dku b/checkman/hitachi_hus_dku index 6f5b4da..55017cc 100644 --- a/checkman/hitachi_hus_dku +++ b/checkman/hitachi_hus_dku @@ -6,7 +6,7 @@ distribution: check_mk description: This check monitors the state of various hardware components of Hitachi Unified Storage Disk Units Chassis (HUS DKU), which are part of an - Hitache Unified Storage VM System. The check uses SNMP and the USPMIB to + Hitachi Unified Storage VM System. The check uses SNMP and the USPMIB to extract state information of the following hardware components of the DKU: Power Supply, Drive, Fan, Environment.

6 years

Removed two import cycles related to the check API.

by Sven Panne

Module: check_mk Branch: master Commit: d53aa6236c566bc04bcbf7ea1a3f1e832ec77230 URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=d53aa6236c566b… Author: Sven Panne <sp(a)mathias-kettner.de> Date: Fri Jun 15 08:55:29 2018 +0200 Removed two import cycles related to the check API. This brings the number of cycles down to 3 (from 5). Threading through things doesn't win a beauty contest, but this doesn't matter at all here: Removing cycles is far more important than some vague aesthetic issues. Once again, threading through things is a clear sign of some missing abstraction, in our case: We are missing a self-contained class/module representing our check API. Change-Id: Ieb9e4be113c4eb5d9ee42f2993acc70aeb5390bc --- bin/check_mk | 3 ++- cmk_base/automations/__init__.py | 3 ++- cmk_base/automations/check_mk.py | 3 ++- cmk_base/check_api.py | 4 ++-- cmk_base/checking.py | 3 +-- cmk_base/checks.py | 13 ++++++------- cmk_base/core_nagios.py | 3 ++- cmk_base/inventory.py | 3 ++- cmk_base/inventory_plugins.py | 8 ++++---- cmk_base/modes/check_mk.py | 6 ++++-- tests/integration/cmk_base/test_check_variables.py | 7 ++++--- tests/integration/cmk_base/test_data_sources.py | 3 ++- tests/integration/cmk_base/test_mgmt_board.py | 3 ++- tests/testlib/__init__.py | 6 ++++-- tests/unit/cmk/test_man_pages.py | 3 ++- tests/unit/cmk_base/test_checks.py | 9 +++++---- 16 files changed, 46 insertions(+), 34 deletions(-) Diff: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commitdiff;h=d53aa6236c…

6 years

Minor cleanup

by Simon Betz

Module: check_mk Branch: master Commit: cb54f2631a889199ee4940b513ee91be6b550298 URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=cb54f2631a8891… Author: Simon Betz <si(a)mathias-kettner.de> Date: Fri Jun 15 10:14:52 2018 +0200 Minor cleanup Change-Id: I07363d3b3772eac36c7102cfe266f53573c55eaa --- checks/if64.include | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/checks/if64.include b/checks/if64.include index 983a9c7..572ab2f 100644 --- a/checks/if64.include +++ b/checks/if64.include @@ -53,19 +53,22 @@ def if64_scan_function(oid, use_if64adm=False): if if64_disabled(host_name()): return False - ignored_strings = [ + ignored_sys_descr = [ "LANCOM", "ELSA", "T-Systems", "Brocade VDX Switch", + ] + for sys_descr in ignored_sys_descr: + if sys_descr in oid(".1.3.6.1.2.1.1.1.0"): + return False + ignored_sys_obj_ids = [ ".4.1.11863.", - ".1.3.6.1.4.1.12356" + ".1.3.6.1.4.1.12356", ] - - for string in ignored_strings: - if string in oid(".1.3.6.1.2.1.1.1.0") or \ - string in oid(".1.3.6.1.2.1.1.2.0"): + for obj_id in ignored_sys_obj_ids: + if obj_id in oid(".1.3.6.1.2.1.1.2.0"): return False if need_if64adm() != use_if64adm:

6 years

Moved function to right place

by Simon Betz

Module: check_mk Branch: master Commit: 6d68e491418b7c008679029c4eff4bf6864e394d URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=6d68e491418b7c… Author: Simon Betz <si(a)mathias-kettner.de> Date: Fri Jun 15 08:37:25 2018 +0200 Moved function to right place Change-Id: I2a6a14cb4dabd176da956afbd2f0de5c93834d91 --- cmk_base/checking.py | 18 ++---------------- cmk_base/inventory.py | 14 ++++++++++++++ 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/cmk_base/checking.py b/cmk_base/checking.py index 815af7b..3be2336 100644 --- a/cmk_base/checking.py +++ b/cmk_base/checking.py @@ -205,27 +205,13 @@ def _do_all_checks_on_host(sources, hostname, ipaddress, only_check_plugin_names missing_sections.add(cmk_base.check_utils.section_name_of(check_plugin_name)) if checks.do_status_data_inventory_for(hostname): - _do_status_data_inventory(sources, multi_host_sections, hostname, ipaddress) + import cmk_base.inventory as inventory + inventory.do_status_data_inventory(sources, multi_host_sections, hostname, ipaddress) missing_section_list = sorted(list(missing_sections)) return num_success, missing_section_list -def _do_status_data_inventory(sources, multi_host_sections, hostname, ipaddress): - import cmk_base.inventory as inventory - import cmk_base.inventory_plugins as inventory_plugins - # cmk_base/modes/check_mk.py loads check plugins but not inventory plugins - do_inv = False - inventory_plugins.load_plugins(inventory.get_inventory_context) - for plugin in inventory_plugins.inv_info.values(): - if plugin.get("has_status_data"): - do_inv = True - break - if do_inv: - inventory.do_inv_for(sources, multi_host_sections=multi_host_sections, hostname=hostname, - ipaddress=ipaddress, do_status_data_inventory=True) - - def execute_check(multi_host_sections, hostname, ipaddress, check_plugin_name, item, params, description): # Make a bit of context information globally available, so that functions # called by checks now this context diff --git a/cmk_base/inventory.py b/cmk_base/inventory.py index 47997ce..4719444 100644 --- a/cmk_base/inventory.py +++ b/cmk_base/inventory.py @@ -154,6 +154,20 @@ def do_inv_check(hostname, options): return status, infotexts, long_infotexts, perfdata +def do_status_data_inventory(sources, multi_host_sections, hostname, ipaddress): + import cmk_base.inventory_plugins as inventory_plugins + # cmk_base/modes/check_mk.py loads check plugins but not inventory plugins + do_inv = False + inventory_plugins.load_plugins(get_inventory_context) + for plugin in inventory_plugins.inv_info.values(): + if plugin.get("has_status_data"): + do_inv = True + break + if do_inv: + do_inv_for(sources, multi_host_sections=multi_host_sections, hostname=hostname, + ipaddress=ipaddress, do_status_data_inventory=True) + + def do_inv_for(sources, multi_host_sections, hostname, ipaddress, do_status_data_inventory=False): _initialize_inventory_tree() inventory_tree = g_inv_tree

6 years

Fixed if64_scan_function function

by Simon Betz

Module: check_mk Branch: master Commit: 20ae147c09bd9dd078ffbd65c62a34d5167d451c URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=20ae147c09bd9d… Author: Simon Betz <si(a)mathias-kettner.de> Date: Fri Jun 15 07:47:10 2018 +0200 Fixed if64_scan_function function Change-Id: Ib367f55b9957b2692dea942166114caca0b323c9 --- checks/if64.include | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/checks/if64.include b/checks/if64.include index 18e61cf..983a9c7 100644 --- a/checks/if64.include +++ b/checks/if64.include @@ -49,7 +49,7 @@ def need_if64adm(): return "portstates" in settings and '9' in settings["portstates"] -def if64_scan_function(oid, use_if64adm): +def if64_scan_function(oid, use_if64adm=False): if if64_disabled(host_name()): return False

6 years

5995 FIX Status data inventory: Fixed fetching client data once more

by Simon Betz

Module: check_mk Branch: master Commit: 0a486d48cb7196e85243e46c2bf8ea2e1c73bac3 URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=0a486d48cb7196… Author: Simon Betz <si(a)mathias-kettner.de> Date: Tue Jun 12 17:09:04 2018 +0200 5995 FIX Status data inventory: Fixed fetching client data once more Change-Id: I40f50a6e7ebc69da3b39cef0af2c204ba9fe1720 --- .werks/5995 | 10 ++++++++++ cmk_base/checking.py | 34 +++++++++++++++++----------------- cmk_base/data_sources/abstract.py | 7 +++++-- cmk_base/data_sources/snmp.py | 18 ++++++++++++++++++ cmk_base/inventory.py | 38 +++++++++++++++++++++++++------------- 5 files changed, 75 insertions(+), 32 deletions(-) Diff: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commitdiff;h=0a486d48cb…

6 years

updated werk text

by Andreas

Module: check_mk Branch: master Commit: b3dadc60d418d911a87c58228e49b58066f3bc1a URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=b3dadc60d418d9… Author: Andreas <ab(a)mathias-kettner.de> Date: Thu Jun 14 19:21:53 2018 +0200 updated werk text Change-Id: I9e1340116075f5690ee79e39bff30ced1aebc535 --- .werks/5823 | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.werks/5823 b/.werks/5823 index 0976b9a..8e08447 100644 --- a/.werks/5823 +++ b/.werks/5823 @@ -19,7 +19,9 @@ Currently these two SLA requirements are implemented Note: An upcoming SLA requirement will be "Minimum time between outages" + Before the availability data gets forwarded to the computation plugins (which check the actual requirements) it is +<ul> <li>further shortened by applying timeperiods, for example "Only check weekdays"</li> <li>cut into mulitple timeframes (daily/weekly/monthly), specified by period in the SLA definition</li> </ul>

6 years

updated werk text

by Andreas

Module: check_mk Branch: master Commit: ed44f95ce0b8bd9c1f53aee7c415eabe45344428 URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=ed44f95ce0b8bd… Author: Andreas <ab(a)mathias-kettner.de> Date: Thu Jun 14 19:28:27 2018 +0200 updated werk text Change-Id: Icd4b1490f28051fc1bb14d8d6a5b1454ed095cda --- .werks/5823 | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/.werks/5823 b/.werks/5823 index 8e08447..3694bfa 100644 --- a/.werks/5823 +++ b/.werks/5823 @@ -16,6 +16,7 @@ Currently these two SLA requirements are implemented <li>State Percentage: The service state OK/WARN/CRIT/UNKNOWN is lower/higher than x percent</li> <li>Outage count: Maximum number of outages with a length of x minutes</li> </ul> + Note: An upcoming SLA requirement will be "Minimum time between outages" @@ -25,10 +26,12 @@ Before the availability data gets forwarded to the computation plugins (which ch <li>further shortened by applying timeperiods, for example "Only check weekdays"</li> <li>cut into mulitple timeframes (daily/weekly/monthly), specified by period in the SLA definition</li> </ul> + Each timeframe is computed separately, so you will get several SLA results, if the timerange you are interested in spans multiple SLA periods. + Configuration First of all you need to configure a SLA definition. Just like views and reports, SLA definitions are configured per user, @@ -37,7 +40,6 @@ so you can setup a SLA and publish it to other users. SLA definitions are not inherently bound to services. A SLA definition can be assigned to a service, via the WATO rule <tt>Assign SLA to service</tt>. For views, the multisite GUI currently offers two different painters to display SLA information - <ul> <li>SLA - Service specific: This painter renders SLA definitions, which were assigned by WATO rule. Therefore, one table column in a view can display multiple SLA definition types. The timerange, however, is fixed for all SLAs and can be configured in the painter</li>

6 years

5823 New Feature: SLA reporting

by Andreas

Module: check_mk Branch: master Commit: 4ed375335c9ac03cab7d1db3c478408bf1143c33 URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=4ed375335c9ac0… Author: Andreas <ab(a)mathias-kettner.de> Date: Thu Jun 14 19:15:44 2018 +0200 5823 New Feature: SLA reporting SLA reports are a continuation of the already existing availability reports. The data from the availability feature can be additionally modified, before it is evaluated by the SLA requirements. Currently these two SLA requirements are implemented <ul> <li>State Percentage: The service state OK/WARN/CRIT/UNKNOWN is lower/higher than x percent</li> <li>Outage count: Maximum number of outages with a length of x minutes</li> </ul> Note: An upcoming SLA requirement will be "Minimum time between outages" Before the availability data gets forwarded to the computation plugins (which check the actual requirements) it is <li>further shortened by applying timeperiods, for example "Only check weekdays"</li> <li>cut into mulitple timeframes (daily/weekly/monthly), specified by period in the SLA definition</li> </ul> Each timeframe is computed separately, so you will get several SLA results, if the timerange you are interested in spans multiple SLA periods. Configuration First of all you need to configure a SLA definition. Just like views and reports, SLA definitions are configured per user, so you can setup a SLA and publish it to other users. SLA definitions are not inherently bound to services. A SLA definition can be assigned to a service, via the WATO rule <tt>Assign SLA to service</tt>. For views, the multisite GUI currently offers two different painters to display SLA information <ul> <li>SLA - Service specific: This painter renders SLA definitions, which were assigned by WATO rule. Therefore, one table column in a view can display multiple SLA definition types. The timerange, however, is fixed for all SLAs and can be configured in the painter</li> <li>SLA - Column specific: This painter renders the same SLA definition for all services in the table</li> </ul> There are several configuration options for both painters. <ul> <li>SLA timerange: The timerange specifies the start and end date you are interested in. A SLA definition only has a recurring period (e.g. weekly). So if you have a SLA definition with a monthly period and set the timerange from 01.01.2018 to 31.03.2018, you will get three separate SLA results, one for each month</li> <li>Layout options: With these options you can configure the content of the painter. You may also choose only to display the SLA name, which means no actual SLA computation, hereby saving performance</li> <li>Plugin display options</li>Allows you to configure the precision of percentage (float) values and additional layout options</li> </ul> There is also a SLA details page available. This page offers detailed information regarding the computation. <ul> <li>Availability rawdata used in computation</li> <li>Aggregated results (the actual SLA outcome) over all computation plugins</li> <li>Subresults for each used computation plugin</li> <li>SLA specification: Includes all settings which were used to create this report</li> </ul> Please note that this feature is quite new and still under heavy development. The goal in version 1.5 is to get some hands on experience and add some minor improvements and bugfixes over time. Exporting the SLA data into PDF reports is currently only supported within views. Later on, the SLA details page will also receive a "Export to PDF" button. Change-Id: I7da3675818954349811f08d9737ed89e731a34ce --- .werks/5823 | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) diff --git a/.werks/5823 b/.werks/5823 new file mode 100644 index 0000000..0976b9a --- /dev/null +++ b/.werks/5823 @@ -0,0 +1,69 @@ +Title: New Feature: SLA reporting +Level: 3 +Component: multisite +Class: feature +Compatible: compat +Edition: cee +State: unknown +Version: 1.6.0i1 +Date: 1528996067 + +SLA reports are a continuation of the already existing availability reports. +The data from the availability feature can be additionally modified, before it is evaluated by the SLA requirements. + +Currently these two SLA requirements are implemented +<ul> +<li>State Percentage: The service state OK/WARN/CRIT/UNKNOWN is lower/higher than x percent</li> +<li>Outage count: Maximum number of outages with a length of x minutes</li> +</ul> +Note: An upcoming SLA requirement will be "Minimum time between outages" + + +Before the availability data gets forwarded to the computation plugins (which check the actual requirements) it is +<li>further shortened by applying timeperiods, for example "Only check weekdays"</li> +<li>cut into mulitple timeframes (daily/weekly/monthly), specified by period in the SLA definition</li> +</ul> +Each timeframe is computed separately, so you will get several SLA results, if the timerange you are interested in spans multiple SLA periods. + + + +Configuration + +First of all you need to configure a SLA definition. Just like views and reports, SLA definitions are configured per user, +so you can setup a SLA and publish it to other users. + +SLA definitions are not inherently bound to services. +A SLA definition can be assigned to a service, via the WATO rule <tt>Assign SLA to service</tt>. +For views, the multisite GUI currently offers two different painters to display SLA information + +<ul> +<li>SLA - Service specific: This painter renders SLA definitions, which were assigned by WATO rule. Therefore, one table +column in a view can display multiple SLA definition types. The timerange, however, is fixed for all SLAs and can be configured in the painter</li> +<li>SLA - Column specific: This painter renders the same SLA definition for all services in the table</li> +</ul> + +There are several configuration options for both painters. +<ul> +<li>SLA timerange: The timerange specifies the start and end date you are interested in. A SLA definition only has a +recurring period (e.g. weekly). So if you have a SLA definition with a monthly period and set the timerange from +01.01.2018 to 31.03.2018, you will get three separate SLA results, one for each month</li> +<li>Layout options: With these options you can configure the content of the painter. You may also choose only to display +the SLA name, which means no actual SLA computation, hereby saving performance</li> +<li>Plugin display options</li>Allows you to configure the precision of percentage (float) values and additional layout options</li> +</ul> + +There is also a SLA details page available. This page offers detailed information regarding the computation. +<ul> +<li>Availability rawdata used in computation</li> +<li>Aggregated results (the actual SLA outcome) over all computation plugins</li> +<li>Subresults for each used computation plugin</li> +<li>SLA specification: Includes all settings which were used to create this report</li> +</ul> + + +Please note that this feature is quite new and still under heavy development. +The goal in version 1.5 is to get some hands on experience and add some minor improvements and bugfixes over time. +Exporting the SLA data into PDF reports is currently only supported within views. +Later on, the SLA details page will also receive a "Export to PDF" button. + +

6 years

← Newer
1
...
5
6
7
8
9
10
11
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Checkmk git commits June 2018