drewkerrigan / nagios-http-json

A generic plugin for Nagios which checks json values from a given HTTP endpoint against argument specified rules and determines the status and performance data for that service.
Other
67 stars 60 forks source link

Multiple keys equals not working when passed as string #93

Open Napsty opened 1 month ago

Napsty commented 1 month ago

The plugin works when multiple keys and their equals lookup values are passed as stdin:

$ ./check_http_json.py -H api.example.com -s -p "health.json" -q service1.status,True service2.status,True service3.status,True
OK: Status OK.

The plugin seems to parse each input argument. Which is fine.

But if the keys are defined in a string and given to the plugin, it will fail:

$ ./check_http_json.py -H api.example.com -s -p "health.json" -q "service1.status,True service2.status,True service3.status,True"
Traceback (most recent call last):
  File "/home/ckadm/Git/nagios-http-json/./check_http_json.py", line 672, in <module>
    main(sys.argv[1:])
  File "/home/ckadm/Git/nagios-http-json/./check_http_json.py", line 660, in main
    nagios.append_message(WARNING_CODE, processor.checkWarning())
  File "/home/ckadm/Git/nagios-http-json/./check_http_json.py", line 338, in checkWarning
    failure += self.checkEquality(self.key_value_list)
  File "/home/ckadm/Git/nagios-http-json/./check_http_json.py", line 267, in checkEquality
    k, v = kv.split(',')
ValueError: too many values to unpack (expected 2)

Why is this important? Because it breaks the plugin under Icinga2 (and maybe on different monitoring core software, too), as the input/variable vars.http_json_key_equals is handed over to the plugin as string (see https://github.com/drewkerrigan/nagios-http-json/blob/master/contrib/icinga2_check_command_definition.conf#L81).

martialblog commented 1 month ago

Interesting, I'll have a look at it

martialblog commented 1 month ago

Had a quick look.

First, yeah we should do something about that ugly error. I'll try to have a cleaner solution.

Second,

-q service1.status,True service2.status,True and -q "service1.status,True service2.status,True" are not the same semantically. -q service1.status,True service2.status,True means two values for the -q flag, -q "service1.status,True service2.status,True" means one value for the -q flag.

Similar with other CLI tools:

touch foo bar
touch "foo bar foo"

ls -l
total 0

bar
foo
'foo bar foo'

I'm sure you can tell your monitoring tool to pass multiple string values to flag, like so:

-q "service1.status,True" "service2.status,True" "service3.status,True"

Napsty commented 1 month ago

I'm sure you can tell your monitoring tool to pass multiple string values to flag, like so

will have to look into this, but I don't think the current CheckCommand definition covers this.

martialblog commented 1 month ago

Not an CheckCommand expert myself, but maybe like this? [ "exclude=sppsvc", "exclude=ShellHWDetection" ]

Copied from here: https://icinga.com/docs/icinga-2/latest/doc/03-monitoring-basics/#command-arguments

Napsty commented 1 month ago

I'm aware of the array handling of arguments in Icinga2, but, AFAIK, this requires the repeat_key parameter set to true, which is not the case in the current CheckCommand (that's what I meant with my previous comment).

https://github.com/drewkerrigan/nagios-http-json/blob/master/contrib/icinga2_check_command_definition.conf#L84

martialblog commented 1 month ago

Asked around... someone suggested:

    arguments += {
        "(no key)" = {
            order = 21
            skip_key = true
            value = "$sth_2$"
        }

        "(no key.2)" = {
            order = 22
            skip_key = true
            value = "$sth_3$"
        }
        "-q" = {
            order = 20
            value = "$sth_1$"
        }
    }