None passed as range defaults to "0:"

[mpounsett]

Original report by Gabriel Hege (Bitbucket: datensuppe, ).

---

When passing None as a warning or critical range to the Context or ScalarContext constructor, it uses "0:" for evaluation. This results in a warning or critical status to be written, when the value of the Metric is negative. This is very counterintuitive, because one would expect no warning or critical alert to be generated, especially since the range string does not show in the performance data.

Here is a minimal example:

#!python

import nagiosplugin

class Sensors(nagiosplugin.Resource):
    def probe(self):
        return nagiosplugin.Metric('sens1', -3)

check = nagiosplugin.Check(Sensors(), nagiosplugin.ScalarContext('sens1', warning="-10:10"))
check.main()

which generates the following output: SENSORS CRITICAL - sens1 is -3 (outside range 0:) | sens1=-3;-10:10

[mpounsett]

Original comment by mrvinti (Bitbucket: mrvinti, GitHub: mrvinti).

---

You can get around this by specifying a -inf:inf ("~:") range for your critical threshold. This won't result in a CRITICAL status and will evaluate to OK when within the warning range:

#!python
import nagiosplugin

class Sensors(nagiosplugin.Resource):
    def probe(self):
        return nagiosplugin.Metric('sens1', -3)

check = nagiosplugin.Check(Sensors(), nagiosplugin.ScalarContext('sens1', warning="-10:10", critical="~:"))
check.main()

>>> SENSORS OK - sens1 is -3 | sens1=-3;-10:10;~:

I've created a pull request #6 which addresses this issue replacing the default.

[mpounsett]

Original comment by Christian Kauhaus (Bitbucket: ckauhaus, GitHub: ckauhaus).

---

I think that changing the interpretation of an empty string in Range() should be ok. The specs state that if a Range does not state an explicit value for start, start should be assumed as 0. However, there is no saying in the specs what to do if a range is left completely empty. So the change is agreeable. And it is more intuitive of course. :-)

[mpounsett]

It looks like Christian never got around to dealing with this issue. I've had a look and at first glance what I think he had in mind seems reasonably do-able. The pull request mentioned by @mrvinti didn't survive the migration from BitBucket, but I think I can see what was probably done there. I'm adding this to the work list for the next 1.3.x release.