ID: 6240
Title: WATO Web-API: Implemented SLA API interface
Component: WATO
Level: 1
Class: New feature
Version: 1.6.0i1
SLA data for services can now be fetched via the Web API.
The new action is named <tt>get_sla</tt>.
The request object is structured like this:
F+:
{
"query": [ [[{sla_configuration}], [{timerange_spec_1}], [{host/service pair}]] ]
}
F-:
A query entry always consists of 3 fields.
<ul>
<li>The list of sla_definitions</li>
<li>The list of timerange specificiations</li>
<li>The list of host/service pairs</li>
</ul>
The sla_definition is simply the id of the configured SLA definition.
The timerange specification has some special syntax
Some examples:
F+:
# # Field to send in query
# "Today" # "d0"
# "Yesterday" # "d1"
#
# "This week" # "w0"
# "Last week" # "w1"
#
# "This month" # "m0"
# "Last month" # "m1"
#
# "This year" # "y0"
# "Last year" # "y1"
#
# "The last..." # "last:86400"
# "Time range" # "range:1530271236:1530281236"
#
# SLA configurations have no distinct timestamp. The timestamp depends on the SLA period
# The following example says
# - Start at the penultimate sla period (Note: 0 is current period)
# - Look back additional 4 sla periods
# There will be 5 period results
# "Sla period range" # "sla:2:4"
F-:
The of host/service pairs identifies the required services.
A valid request may look like
F+:
{
"query": [ [["sla_configuration_1"], ["w1"], [["HostA", "ServiceB"]]] ]
}
F-:
This queries the sla_configuration_1 with the timerange "Last week" for the service HostA/ServiceB.
This returns 1 result.
As you might have noticed, each field in the query is enclosed by a list.
That's because each query entry may have multiple values specified.
F+:
{
"query": [ [["sla_configuration_1", "sla_configuration_2"], ["w1"], [["HostA", "ServiceB"]]] ]
}
F-:
This queries the sla_configuration_1 and sla_configuration_2 with the timerange "Last week" for the service HostA/ServiceB.
This returns 2 results.
Now add an additional timerange specification
F+:
{
"query": [ [["sla_configuration_1", "sla_configuration_2"], ["w1", "w0"], [["HostA", "ServiceB"]]] ]
}
F-:
This queries the sla_configuration_1 and sla_configuration_2 with the timerange "Last week" and "This week" for the service HostA/ServiceB.
This returns 4 results.
Finally, you can also add additional triples to the query.
F+:
{
"query": [ [["sla_configuration_1"], ["w1"], [["HostA", "ServiceB"]]],
[["sla_configuration_2"], ["w0"], [["HostX", "ServiceY"]]] ]
}
F-:
This queries sla_configuration_1 with the timerange "Last week" for HostA/ServiceB and
sla_configuration_2 with the timerange "This week" for HostX/ServiceY.
The returned result for these queries is a python dictionary with lots of infos
F+:
{'mysite': {'myhost': {'CPU load':
{(('myhost', 'CPU load'), 'sla_configuration_1', ('sla_period_range', (0, 1)), 'weekly'):
{'plugin_results': [{'period_results': [{'duration': 604800.0,
'sla_broken': False,
'statistics': {'duration': {-1: 604800.0},
'percentage': {-1: 100.0}},
'subresults': [{'deviation_info': {'deviation': 0.0,
'deviation_state': 2,
'levels': (0,
0),
'limit': 0.0},
'error_instances': [],
'requirement': (0,
'min',
0.0),
'sla_broken': False}],
'timerange': (1529272800.0,
1529877600.0)},
{'duration': 396134.0,
'sla_broken': False,
'statistics': {'duration': {-1: 385358.0,
0: 10776},
'percentage': {-1: 97.27970838150726,
0: 2.7202916184927326}},
'subresults': [{'deviation_info': {'deviation': 2.7202916184927326,
'deviation_state': 0,
'levels': (0,
0),
'limit': 0.0},
'error_instances': [],
'requirement': (0,
'min',
0.0),
'sla_broken': False}],
'timerange': (1529877600.0,
1530273734)}],
'plugin_id': 'service_state_percentage',
'timerange_sla_duration': 1000934.0}],
'sla_id': 'sla_configuration_1',
'sla_period': 'weekly'}}}}}
F-:
Keep in mind that this API implementation is an initial version, so there might be interface changes within the next months.
ID: 6116
Title: mk_db2.linux: major refactoring of the plugin to solve different issues
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 1.5.0i2
The refactoring solves the following known issues:
1. Here documents are avoided which should resolve wrong output due to quoting problems.
2. Fix the calculation of the number of database connections.
3. Use a more accurate method to calculate the latency for a database connection.
4. The structure of the plugin was improved for better maintainability.
To use the new version of the plugin it has to be deployed to to the affected hosts.
Futhermore, the script is now required to be accessible and executable by the
instance users to work properly.
ID: 5966
Title: Unified mk_oracle and mk_oracle.aix
Component: Checks & agents
Level: 1
Class: New feature
Version: 1.6.0i1
The agent plugin {{mk_oracle.aix}} does not exist anymore.
Instead the {{mk_oracle}} plugin was refactored and now
supports AIX, too.
In order to use the new plugin please install it to the
well-known agent plugin path or use the agent bakery if
you have a enterprise edition.
The new option '--log' logs some steps to the related log file
which can be found in {{$MK_VARDIR/log/mk_oracle.log}} and
helps to find any errors. Please note that the shell command
'flock' has to be installed.
ID: 6146
Title: mk_oracle: New configuration option 'SKIP_SIDS' where SIDs can be stated to be ignored
Component: Checks & agents
Level: 1
Class: New feature
Version: 1.6.0i1
ID: 6239
Title: WATO host diagnostic page: SNMPv3+Credentials hosts no longer report an exception.
Component: WATO
Level: 1
Class: Bug fix
Version: 1.6.0i1
The diagnose page for hosts with SNMPv3+credentials always showed the following error </tt>API Error:sequence item 14: expected string, NoneType found</tt>.
This has been fixed.
ID: 6224
Title: Prevent multiple mkeventd's from being started in some situations
Component: Event Console
Level: 1
Class: Bug fix
Version: 1.6.0i1
In rare circumstances, a non-responsive mkeventd process would stick
around after an OMD restart, and the new one would not be aware of
the other one's existance due to duplicated cleanup of the PID file
in the Event Console's init script and the process itself respectively.
We remove the cleanup in the init script, as it is more coarse.