Unable to set thresholds with lower bounds on local check

General
,
1

Dear CheckMK forum users,

I seem to have a problem with understanding lower and upper thresholds in local checks.

Systeminfo

  • CheckMK 2.0.0p16 CEE
  • Ubuntu 20.04

The problem
I’m writing a check for an APC UPS without SNMP (connected via USB Cable to Debian OS.
There is a little something in the CheckMK Exchange but it is not quite what we wanted to have, so I started to write my own local check.

For the battery_charge metric, I’d need to have lower thresholds instead of upper thresholds because a full battery is not a problem, an empty one is.

I have been following the CheckMK Local Check Docs, which states the following as accepted output for lower-only WARN/CRIT:

P "My 4th dynamic service" count_lower=37;40:;30: A service with lower thresholds only

Here is my local check output + how CheckMK sees this (on the details page of the service)

# local check output
P "USV Charge" battery_capacity=100.0;50:;25:|voltage=231.8 Battery: 100.0 Percent\nBCHARGE: 100.0 Percent\nOUTPUTV: 231.8 Volts
# Service performance data (source code)
battery_capacity=100;;;;

As you can see, CheckMK doesn’t accept the lower-only thresholds.

The same happens if I drop the voltage metric:

# local check output
P "USV Charge" battery_capacity=100.0;50:;25: Battery: 100.0 Percent\nBCHARGE: 100.0 Percent\nOUTPUTV: 231.8 Volts
# Service performance data (source code)
battery_capacity=100;;;;

If I set warn_high and crit_high to some values, the lower thresholds are ignored by CheckMK:

# local check output
P "USV Charge" battery_capacity=100.0;50:110;25:110|voltage=231.8 Battery: 100.0 Percent\nBCHARGE: 100.0 Percent\nOUTPUTV: 231.8 Volts
# Service performance data (source code)
battery_capacity=100;110;110;;

Did I do something wrong and didn’t see it?
Are the docs outdated?
Are upper and lower limits not a thing anymore?
If so, how else would I set limits for battery charges and general lower-bounds limits?

Thank you for taking the time to read and help.

Best regards,
pixelpoint

1 Like
3

Hi kdeutsch,

I could totally write the status logic with WARN and CRIT values, no problem. I just thought, since the docs say the lower limits are a feature, I should take advantage of that.

So I’m more interested in a solution for using state P and automatic WARN or CRIT values with the lower boundaries.

I guess now I see how one could read that as “this is my first check please help me”. Sorry, that was a mistake on my part.

Anyway, thank you for taking the time to answer my question :slight_smile:

Best regards,
pixelpoint

4

The local check plugin will use the lower thresholds to compare them against the value with the state value “P”. Unfortunately the graph system cannot handle this and it does not show in the “raw performance data” on the service details page.

1 Like
5

Hi r.sanders,

Thank you for the clarification!

As far as I can see, there are 2 options here:

  1. Use the state P + lower threshold for the metrics and don’t have WARN / CRIT in graph
  2. Set state yourself and add “normal” WARN / CRIT limits to graph

I opted for 2 because this gives full functionality (in terms of service state) and has (technically meaningless) limits in the graph UI to asses the situation with a single look.

Thank you very much!

Also:
Adding a 1 sentence explanation to the docs on the page mentioned in the first post might be meaningful. Maybe it’s just me but I didn’t think of the possibility of the graphing system not being able to cope with lower thresholds.

Best regards,
pixelpoint

6

:+1: This is a year long discussion. Normally you need lower thresholds in graphs but at the Munich team they think a little bit different. For temperature, voltage, humidity and so on all these measurements need lower thresholds and without these thresholds in graphs it becomes meaningless on dashboards or inside alert messages. I look at the graph see no threshold and think why is there an alarm.
This is a thing for @martin.hirschvogel or some one else from the team and it needs awareness from dev side.

3 Likes
7

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.