Page 1 of 2
Monitoring via hitting an API
Posted: Thu Aug 02, 2018 9:43 am
by andrewatmacys
Hello,
I'd like to set up a way to monitor an API for health checks. I've been given the API location, as well as the resource location and some examples of what a response would look like. Is it possible to send a POST to the API, and monitor the response?
Re: Monitoring via hitting an API
Posted: Thu Aug 02, 2018 10:49 am
by mcapra
I've done this with
check_http using the following arguments:
Code: Select all
-P, --post=STRING
URL encoded http POST data
...
-s, --string=STRING
String to expect in the content
...
-r, --regex, --ereg=STRING
Search page for regex STRING
-R, --eregi=STRING
Search page for case-insensitive regex STRING
Here's some older threads where this is done with a SOAP request body:
https://support.nagios.com/forum/viewto ... 0&p=179674
https://support.nagios.com/forum/viewto ... 7&p=150616
Re: Monitoring via hitting an API
Posted: Thu Aug 02, 2018 11:07 am
by andrewatmacys
sorry, I should have specified it's a REST API, though I assume the POST would work still?
Re: Monitoring via hitting an API
Posted: Thu Aug 02, 2018 11:27 am
by mcapra
The architectural style shouldn't really matter, but
passing -P does force the request method to POST. So if you need to send a message body via some other request method (GET, PUT, whatever), you'll additionally need to pass the
-j argument:
Code: Select all
-j, --method=STRING (for example: HEAD, OPTIONS, TRACE, PUT, DELETE, CONNECT)
Set HTTP method.
Re: Monitoring via hitting an API
Posted: Thu Aug 02, 2018 12:32 pm
by andrewatmacys
I see, I'll play around with this some, thanks! I'll post here again if I have any more questions.
Re: Monitoring via hitting an API
Posted: Thu Aug 02, 2018 1:12 pm
by andrewatmacys
I have a cURL command that is supposed to be able to hit this, but I'm having trouble with it. The command looks like this, with sensitive data taken out:
curl -viL --basic --user <username>:<password> \
-H "Accept: application/json" -d "@request.json" \
https://<subscription>.api.retailnext.net/v1/healthalerts
This is how it was given to me, indents and all, and when I run it, with and without indents from the git bash, it returns a malformed query error. Any idea on how to fix or adapt this? Another question is what is the -viL option at the beginning?
Re: Monitoring via hitting an API
Posted: Thu Aug 02, 2018 4:00 pm
by scottwilkerson
andrewatmacys wrote:I have a cURL command that is supposed to be able to hit this, but I'm having trouble with it. The command looks like this, with sensitive data taken out:
curl -viL --basic --user <username>:<password> \
-H "Accept: application/json" -d "@request.json" \
https://<subscription>.api.retailnext.net/v1/healthalerts
This is how it was given to me, indents and all, and when I run it, with and without indents from the git bash, it returns a malformed query error. Any idea on how to fix or adapt this? Another question is what is the -viL option at the beginning?
does a file with the
request.json live in the directory you are executing this from?
You would want to replace this with the full path to the file that contains the json of the request.
the -viL means
Code: Select all
-v/--verbose
Makes the fetching more verbose/talkative. Mostly useful for debugging. A line starting with
’>’ means "header data" sent by curl, ’<’ means "header data" received by curl that is hidden
in normal cases, and a line starting with ’*’ means additional info provided by curl.
Note that if you only want HTTP headers in the output, -i/--include might be the option you’re
looking for.
If you think this option still doesn’t give you enough details, consider using --trace or
--trace-ascii instead.
This option overrides previous uses of --trace-ascii or --trace.
Use -s/--silent to make curl quiet.
-i/--include
(HTTP) Include the HTTP-header in the output. The HTTP-header includes things like server-
name, date of the document, HTTP-version and more...
-L/--location
(HTTP/HTTPS) If the server reports that the requested page has moved to a different location
(indicated with a Location: header and a 3XX response code), this option will make curl redo
the request on the new place. If used together with -i/--include or -I/--head, headers from
all requested pages will be shown. When authentication is used, curl only sends its creden-
tials to the initial host. If a redirect takes curl to a different host, it won’t be able to
intercept the user+password. See also --location-trusted on how to change this. You can limit
the amount of redirects to follow by using the --max-redirs option.
Re: Monitoring via hitting an API
Posted: Fri Aug 03, 2018 10:01 am
by andrewatmacys
I see, and it did not, thank you. And thank you for informing me about -viL, I tried looking it up and got no results yesterday.
Would the check_http command be able to run this request as is, I'd assume not? I've looked at the other threads linked above but haven't been able to glean the information I need. I don't have the IP of the api I'm hitting, but I could try to get it.
Re: Monitoring via hitting an API
Posted: Fri Aug 03, 2018 12:26 pm
by scottwilkerson
I don't believe so, you would likely need to create a custom plugin
Here are the plugin guidelines
https://nagios-plugins.org/doc/guidelines.html
Re: Monitoring via hitting an API
Posted: Fri Aug 03, 2018 1:42 pm
by rexconsulting
Rex Consulting loves writing custom plugins!