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.
ID: 4690
Title: Fixed handling of state changes when cmcdump is used
Component: Core & setup
Level: 1
Class: Bug fix
Version: 1.5.0i1
State changes coming in via cmcdump were always considered "hard" state
changes, leading to superfluous logging in the history file and wrong
alerts. This has been fixed.
ID: 4746
Title: Fixed using HW/SW inventory filters in views without inventory painters
Component: Multisite
Level: 1
Class: Bug fix
Version: 1.5.0i1
When adding a HW/SW inventory related filter to a view without adding a sorter
or painter, this resulted in a KeyError exception.
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.
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-:
ID: 8289
Title: wagner_titanus_topsense.smoke: Adapted levels to be more user friendly
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 1.5.0i1
Adapted levels to be more user friendly:
<ul>
<li>ok: <= 3%</li>
<li>warn: > 3% and <= 5%</li>
<li>crit: > 5%</li>
</ul>
ID: 4732
Title: systemd: Don't kill child processes of the agent
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 1.5.0i1
When running the Check_MK agent via systemd the asynchronous executed
agent plugins and real time checks were not working correctly since the
systemd was terminating all child processes after the agent finished.
The systemd configuration has now been changed to let the child processes
be alive after the agent exited.