Checkmk werks level2 May 2017

checkmk-werks-lvl2@lists.checkmk.com

5 participants
15 discussions

Check_MK Werk 4703: Business intelligence: fixed various display and navigation bugs in timelines page

by Andreas Boesl

ID: 4703 Title: Business intelligence: fixed various display and navigation bugs in timelines page Component: BI Level: 2 Class: Bug fix Version: 1.5.0i1 <ul> <li>Fixed from/until computation error</li> <li>No longer hiding timewarped aggregations (BI aggregations at selected timestamps)</li> <li>Fixed missing/redundant navigation arrows in the timeline selection</li> <li>Disabled support for multiple BI aggregations in timeline page. This feature will be redesigned later on</li> </ul>

7 years, 5 months

Check_MK Werk 4701: WATO Web-API: now able to manage sites

by Andreas Boesl

ID: 4701 Title: WATO Web-API: now able to manage sites Component: WATO Level: 2 Class: New feature Version: 1.5.0i1 You can now configure the WATO sites through new API calls <ul> <li>get_site: requires the site_id key in the request object</li> <li>set_site: expects the same data format, than the get_site call provides.</li> <li>delete_site: requires the site_id key in the request object</li> <li>login_site: requires the site_id, the username and the password keys in the request object</li> <li>logout_site: requires the site_id key in the request object</li> </ul> Important: Right now the interface is only able to speak the python language. The existing output_format parameter, as well as the new request parameter <tt>request_format</tt> must both be set to <tt>python</tt>. An additional interface language is planned, maybe XML. Furthermore, these API calls are intended for admin use only, since they might modify the entire site configuration object.

7 years, 5 months

Check_MK Werk 4700: WATO Web-API: Now able to configure host tags

by Andreas Boesl

ID: 4700 Title: WATO Web-API: Now able to configure host tags Component: WATO Level: 2 Class: New feature Version: 1.5.0i1 You can now configure the WATO Hosttags through the new API calls <tt>get_hosttags</tt> and <tt>set_hosttags</tt>. Important: These API calls are intended for admin use only, since they modify the entire hosttags configuration. <tt>get_hosttags</tt> This API call does not require any additional info. It simply returns a dictionary with all tag_group and aux_tags. The response also includes an extra key <tt>configuration_hash</tt>, which can be used in the following call. <tt>set_hosttags</tt> The previous call provided a dict with the hosttags configuration. This call expect the same format in the request object. You can modify the modify the previously queried dict and send it back. If you also sent the configuration_hash parameter, the Web-API will check if the configuration has changed in the meantime. If so, the set_hosttags call will fail. When no configuration_hash parameter is sent, no checking will be done and the configuration is completely overwritten. However, there are some final checks before the configuration is applied. First of all, the syntax and dependencies are checked. Furthermore, the api call checks whether all explicitely configured host tags are still present in the updated configuration. You can not set hosttags when the operation would introduce corrupt host tag settings.

7 years, 5 months

Check_MK Werk 4699: WATO Web-API: now able to configure rulesets

by Andreas Boesl

ID: 4699 Title: WATO Web-API: now able to configure rulesets Component: WATO Level: 2 Class: New feature Version: 1.5.0i1 You can now configure all rules which are available in the Host & Service Parameters Page through the use of two Web-API calls. Important: Right now the interface is only able to speak the python language. The existing output_format parameter, as well as the new request parameter <tt>request_format</tt> must both be set to <tt>python</tt>. An additional interface language is planned, maybe XML. Furthermore, these API calls are intended for admin use only, since they modify the entire ruleset in all folders. <tt>get_rulesets_info</tt> This API call does not require any additional info. It simply returns a list of all available rulesets. Each entry of this list is a dictionary which includes information about the title, the help text, the item help text and the how often the rule is used. <tt>get_ruleset</tt>br> Requires the request key <tt>ruleset_name</tt>, which specifies the ruleset to query. This API call returns exactly one complete ruleset of all folders, so you can't query differnt types. The response itself has an extra key configuration_hash, which can be used in the following call. <tt>set_ruleset</tt>br> The previous call provided a dict with the ruleset configuration. This call expect the same format in the request object. You can modify the modify the previously queried dict and send it back through this f you also sent the configuration_hash parameter, the Web-API will check if the configuration has changed in the meantime. If so, the set_ruleset call will fail. When no configuration_hash parameter is sent, no checking will be done.

7 years, 5 months

Check_MK Werk 4567: inventory of interfaces: prevent showing negative last_state_change value

by Marcel Schulte

ID: 4567 Title: inventory of interfaces: prevent showing negative last_state_change value Component: HW/SW Inventory Level: 2 Class: Bug fix Version: 1.5.0i1 On SNMP devices sysUpTime is a 32-bit counter and will roll over after 496 days. ifLastChange is the timestamp from sysUpTime when the state changed. At inventory time we got a negative value if sysUpTime was smaller then ifLastChange (because it rolled over) using the normal formula. If sysUpTime is smaller than ifLastChange we add 496 days for the rollover now. When the device reboots all last_state_change values are set to 0 by the device so those cases are not affected by the fix.. Beware there's no way to get the count of times the sysUpTime counter rolled over so the last_state_change is not accurate in case it's in real more than 496 days ago. ...but this situation has never been different. This fix just removes another error in shown values.

7 years, 5 months

Check_MK Werk 4568: mk_inventory.vbs: fixed getNetworkAdpater function to prevent errors caused by null arrays

by Marcel Schulte

ID: 4568 Title: mk_inventory.vbs: fixed getNetworkAdpater function to prevent errors caused by null arrays Component: HW/SW Inventory Level: 2 Class: Bug fix Version: 1.5.0i1

7 years, 5 months

Check_MK Werk 4689: Fixed buffer overflow when importing cmcdump data

by Sven Panne

ID: 4689 Title: Fixed buffer overflow when importing cmcdump data Component: Core & setup Level: 2 Class: Bug fix Version: 1.5.0i1 When importing data from cmcdump into the Check_MK Micro Core, a buffer for the long plugin output was too small, leading to a buffer overflow with unpredictable consequences. The affected COMMANDs on the Livestatus interface were UPDATE_SHADOW_HOST_STATE and UPDATE_SHADOW_SERVICE_STATE. This has been fixed.

7 years, 5 months

Check_MK Werk 4733: Check_MK graphs can now be exported as PNG images

by Lars Michelsen

ID: 4733 Title: Check_MK graphs can now be exported as PNG images Component: metrics Level: 2 Class: New feature Version: 1.5.0i1 It is now possible to export the Check_MK graphs as static PNG images. This mechanism can be used to to integrate the graphs in 3rd party tools. For example, you can use it to add graphs to NagVis maps or to the hover menu of NagVis. The new page is named <tt>graph_image.py</tt>. The page is receiving a single request parameter that is structured equal to the JSON/python graph API (See werk #8643). The request object is structured like this: F+: { "specification": [..., ...], "data_range": { "time_range" : [..., ...], } } F-: The specification is using the Check_MK internal graph specification format. The first element is the specification type (<tt>template</tt>, <tt>custom</tt> or <tt>explicit</tt>. The structure of the second element depends on the type. Please take a look at the examples below to get an idea of it. The time range is given in two unix timestamps, the start time and the end time. But the whole <tt>data_range</tt> specification is optional. In case you don't provide it, the 25h graph will be rendered. The answer to this request is a single, dynamically rendered, PNG image. Please note that this request is done in the context of the currently logged in user. So the user that opens a page containing this snippet needs to be authenticated with the Check_MK GUI and able to see the image. Otherwise the user won't be able to see the image. The most common use case will be to add the image generated by this. The following snippets show how it can be embedded: F+: <img src="http://mycmkserver/mysite/check_mk/graph_image.py?request={%22specification…"> F-: This will try to open the image from the Check_MK site <tt>mysite</tt> on the server <tt>mycmkserver</tt>. The graph is specified by the following request object in URL encoded form: F+: { "specification": ["template", { "service_description": "CPU load", "site": "mysite", "host_name": "myhost" }] } F-: It is also possible to adapt the rendering attributes of the graph using the <tt>render_options</tt> data structure. This example hides the legend and the title of the graph and sets a custom image size: F+: <img src="http://mycmkserver/mysite/check_mk/graph_image.py?request={%22specification…"> F-: Again, the human friendly formated request object: F+: { "specification": ["template", { "service_description": "CPU load", "site": "mysite", "host_name": "myhost" }], "render_options": { "show_legend": false, "show_title": false, "size": [ 50, 15 ] } } F-: In case you want to render custom graphs, you can use a specification like this in your request. Replace <tt>custom_graph_1</tt> with the ID of the custom graph you like to see: F+: ["custom", "custom_graph_1"] F-:

7 years, 5 months

Check_MK Werk 4725: Significant improvement of Check_MK check helper memory usage

by Lars Michelsen

ID: 4725 Title: Significant improvement of Check_MK check helper memory usage Component: Core & setup Level: 2 Class: Bug fix Version: 1.5.0i1 The memory usage of the Check_MK check helpers, especially the growth that occures during runtime, has been reduced significantly. One example which has been measured in a single site with 30 Check_MK check helpers configured and a large configuration (a lot of hosts, services, tags and rulesets): Before this change it was executing 1000 service checks per second with a total memory usage of about 15 GB. After this change it is now performing 1100 service checks per second with a total memory usage of 3.5(!) GB. The exact memory reduction highly depends on the Check_MK configuration, but should be measurable in all medium to large environments.

7 years, 5 months

Check_MK Werk 4718: Fixed memory leak in Check_MK check helpers when started in verbose mode

by Lars Michelsen

ID: 4718 Title: Fixed memory leak in Check_MK check helpers when started in verbose mode Component: Core & setup Level: 2 Class: Bug fix Version: 1.5.0i1 When the Check_MK helpers are configured with a higher log level than the default Notice log level the Check_MK helpers were leaking memory. This can be configured by changing the option "Check_MK check helpers" of the global setting "Logging of the core" to e.g. Informational. In this mode the helper gathers information about some changed variables during runtime and the memory usage. It also allows to debug different mechanics of the helpers. If you enabled this, each reload of the core (not restart) was triggering the memory leak in the helpers. In extreme situations this could lead to duplication of the memory usage on each reload.

7 years, 5 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2 May 2017