Check OK with bad HTTP response code

[BBQigniter]

Please, add an option or a corresponding error message if the check actually received a bad response code.

For example if you execute something like

#                                                                                mistyped path
./check_http_json.py --host some-elasticsearch.server.example --request GET --path _cluster/ealth --ssl --insecure --basic-auth username:password --key_not_equals status,yellow --key_not_equals_critical status,red

the output will be

OK: Status OK.

without any indication that it actually didn't work at all unless with --verbose added you'll see

{
  "error": "Incorrect HTTP method for uri [/_cluster/ealth] and method [GET], allowed: [POST]",
  "status": 405
}
OK: Status OK.

If you curl -I you also see a correct 405 code

Or did I miss some setting/argument for this check?

BTW - thank you very much for this check plugin - it's awesome!

[martialblog]

Hi,

the plugin currently does not care about the status code and since the response is still valid JSON it will run your query.

Wouldn't it be possible to invert your query? Meaning, instead of checking for red/yellow cluster states, check if the cluster is green --key_equals status,green?

[BBQigniter]

Hi,

the plugin currently does not care about the status code and since the response is still valid JSON it will run your query.

Yes, and that is, I think a confusing behavior - because unless you execute the check with --verbose there is no indication that it's is not working at all. The check shouldn't be OK in such case, maybe it should be "unknown" or there should be some warning/indicator that the result might be inconclusive.

Wouldn't it be possible to invert your query? Meaning, instead of checking for red/yellow cluster states, check if the cluster is green --key_equals status,green?

I had that previously but then if the state is "red", there is no way to get a critical-alert state if I'm not wrong.

But anyway, I think this issue https://github.com/drewkerrigan/nagios-http-json/issues/75 might have been similar - as long as there is a valid JSON in the response the check-result might be misleading in some cases. The HTTP response-code should be also taken into account by default or switchable to be taken into account via a parameter/argument I think

just my 2 cents 😄